Java中无法靠单次重命名实现高并发原子文件替换，必须用临时文件+Files.move(..., ATOMIC_MOVE)；因File.renameTo()不抛异常、跨系统退化复制、结果不可预测，且Windows下被占用时静默失败。
Java 中无法靠单次重命名实现高并发下的原子性文件替换，必须结合临时文件 + 原子 move 才能真正保障。核心在于：重命名本身不是万能锁，而是一个依赖文件系统行为的底层操作，不能直接用于并发安全的“写入即生效”场景。
为什么 File.renameTo() 不适合高并发原子替换
它不抛异常、只返回 boolean，失败原因难以定位；跨文件系统时自动退化为复制+删除，完全不原子；多个线程同时 rename 同一目标文件，结果不可预测——可能覆盖、丢失或静默失败。Windows 下若文件正被其他进程打开（如日志被 tail -f），renameTo 会直接返回 false，且无提示。
推荐方案：临时文件 + Files.move(…, ATOMIC_MOVE)
这是目前最可靠、被生产系统广泛采用的方式：
- 先用 Files.createTempFile() 在同一文件系统内生成唯一临时路径（如
config-abc123.tmp） - 将新内容写入该临时文件（可用 Files.copy(InputStream, temp, REPLACE_EXISTING)）
- 调用 Files.move(temp, target, ATOMIC_MOVE, REPLACE_EXISTING) —— 此操作在同设备下由 OS 的 rename(2) 完成，是真正的原子切换
- move 成功后，旧文件立即不可见，新文件瞬间生效；失败则临时文件可安全清理，原文件不受影响
高并发下还需额外防护
仅靠原子 move 还不够，需配合以下措施：
立即学习“Java免费学习笔记（深入）”；
- 加文件锁（可选但推荐）：用 FileChannel.lock() 对目标文件加独占锁，防止多个 JVM 实例或进程同时写同一配置文件
- 校验写入完整性：move 前检查临时文件大小是否与预期一致（Files.size(temp) == expectedSize），避免写入中断导致截断
- 避免路径竞争：不要让多个线程共用同一个 temp 模板名，应基于线程 ID 或纳秒时间戳生成临时名，确保唯一性
- 失败后清理要健壮：move 抛异常时，必须尝试 Files.deleteIfExists(temp)，并忽略其异常（因可能已被其他线程删过）
跨文件系统怎么办
ATOMIC_MOVE 必然失败，此时无法做到真正原子，只能追求“失败可恢复”：
- 先 copy 到目标位置，校验 md5 或 size
- 再 rename 原文件为
config.json.bak_20260728_1643（带时间戳，不覆盖） - 最后 delete 原文件 —— 若这步失败，保留 .bak 文件供人工回滚
- 整个流程加 try-with-resources 和 finally 清理，确保任何分支都不遗漏临时资源
