Java Files.move 使用 ATOMIC_MOVE 失败时如何降级处理

把临时文件切换成正式文件时，很多 Java 程序会直接写成 Files.move(source, target, StandardCopyOption.ATOMIC_MOVE)。这段代码在同一文件系统、provider 支持原子移动时很可靠；换到网络盘、不同文件系统或能力受限的 provider 后，可能抛出 AtomicMoveNotSupportedException。

正确的降级方式不是吞掉异常后无条件重试，而是只捕获“原子移动不支持”，确认业务能接受普通移动，再用不带 ATOMIC_MOVE 的 Files.move 完成兼容路径；权限、目标冲突和磁盘故障仍应继续失败。

ATOMIC_MOVE 失败的根因：能力不支持，不等于普通 I/O 失败

StandardCopyOption.ATOMIC_MOVE 要求移动作为一个原子文件系统操作完成。Files.move 最终交给关联的 FileSystemProvider，provider 如果无法提供这个保证，就可以抛出 AtomicMoveNotSupportedException。这与目标已存在、没有权限、源文件不存在不是同一类问题。

先尝试原子移动，再单独捕获不支持异常

生产代码可以把最强语义放在第一条路径。捕获时使用具体异常类型，并保留原始异常作为日志上下文；如果源文件和目标文件不在同一文件系统，原子移动通常没有可行基础，应该在生成临时文件时就尽量让它们位于目标目录。

import java.io.IOException;
import java.nio.file.AtomicMoveNotSupportedException;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.StandardCopyOption;

static void publish(Path temp, Path target) throws IOException {
    try {
        // 第一选择：要求 provider 以原子操作替换目标文件。
        Files.move(temp, target, StandardCopyOption.ATOMIC_MOVE,
                StandardCopyOption.REPLACE_EXISTING);
    } catch (AtomicMoveNotSupportedException unsupported) {
        // 这里只表示能力不足；权限和磁盘错误不能走这条兼容分支。
        fallbackMove(temp, target, unsupported);
    }
}

把 REPLACE_EXISTING 与 ATOMIC_MOVE 一起传入时，具体替换语义仍由 provider 决定，不能靠参数组合推导出所有平台都具备完全相同的行为。若产品不能接受短暂的中间状态，就不应自动降级。

正确的降级写法：只在确认业务允许时退回普通移动

降级分支的关键是把“能力不支持”和“业务不能接受”分开。配置文件、缓存快照等允许短暂不一致的场景，可以退回普通移动；配置热切换、清单索引或对外可见的发布文件，则应记录告警并让上层选择重试、人工处理或更换存储位置。

private static void fallbackMove(Path temp, Path target,
                                  AtomicMoveNotSupportedException cause)
        throws IOException {
    // 业务已明确允许非原子替换；记录原因，便于定位存储环境差异。
    System.getLogger("publisher").log(System.Logger.Level.WARNING,
            "ATOMIC_MOVE 不可用，改用普通移动：" + cause.getMessage());

    // 普通移动没有原子切换保证；覆盖策略必须显式写出。
    Files.move(temp, target, StandardCopyOption.REPLACE_EXISTING);
}

不要写成 catch (IOException e) { Files.move(temp, target); }：这样会把目标冲突、权限不足、路径失效都误判成“原子能力不足”，还可能在目标文件已部分变化时造成难以追溯的结果。

用同文件系统临时文件和恢复策略收口

如果目标是 /data/app/config.json，临时文件也应优先创建在 /data/app 下，而不是系统临时目录。这样既减少跨文件系统移动失败，也让原子重命名更有机会成立。写入完成后先关闭流，再移动；降级时保留临时文件清理和目标存在性检查，避免把半写入文件当作成功版本。

Path dir = target.toAbsolutePath().getParent();
Path temp = Files.createTempFile(dir, ".config-", ".tmp");
try {
    // 先完整写入并关闭 temp，再尝试切换，避免移动打开中的文件。
    Files.writeString(temp, json);
    publish(temp, target);
    temp = null; // 移动成功后，finally 不再删除新目标。
} finally {
    // 失败恢复：只清理仍然存在的临时文件，不碰正式目标。
    if (temp != null) {
        Files.deleteIfExists(temp);
    }
}

真正需要强一致切换时，优先修正部署目录、挂载方式或存储 provider，让原子路径成立；普通移动只能作为明确接受风险的兼容方案。

相关问题

为什么同一段代码在本机成功，换到网络盘就失败？

因为 Files.move 的能力由实际路径对应的文件系统 provider 决定，本机目录和网络盘不一定提供相同的原子移动语义。

捕获 AtomicMoveNotSupportedException 后一定要重试吗？

不一定。若业务要求读者始终看不到中间状态，应报告不支持并停止；只有明确允许普通移动时才进入降级分支。

REPLACE_EXISTING 能保证覆盖过程原子吗？

不能。它只表达目标存在时的替换意图，是否原子仍取决于是否使用了受支持的原子移动能力。