一、先理解问题：重命名为什么会出事
很多人觉得重命名不就是改个名字吗，能出什么问题？
问题出在"改名字"这个动作本身并不是原子的。所谓原子性，就是一个操作要么完全成功，要么完全失败，中间不存在任何中间状态。
在操作系统层面，重命名一个文件，实际上包含了几个步骤：首先在文件系统中找到原文件的目录项，然后修改目录项中的文件名，最后更新文件系统的元数据。如果在这个过程中，另一个线程或者进程也在对同一个文件做重命名，两个操作就会产生冲突。
最典型的场景是这样的：线程 A 想把 file.txt 改名为 file_v1.txt，线程 B 想把 file.txt 改名为 file_v2.txt。两个线程几乎同时执行，结果可能是 file_v1.txt 和 file_v2.txt 都不存在，原来的 file.txt 也被弄丢了。或者更糟糕的情况，其中一个重命名成功了，但另一个操作覆盖了它，导致你以为自己改了名字，实际上文件内容已经被替换。
这种问题在日志轮转、文件上传、配置热更新等场景中尤其容易出现。
二、操作系统给了我们什么保障
好消息是，大多数现代操作系统在文件系统层面已经提供了原子性重命名的能力。
在 POSIX 标准中，rename 这个系统调用是原子性的。也就是说，如果你在同一个文件系统内，把一个文件从路径 A 移动到路径 B，这个操作是原子的。要么成功，要么失败，不会出现中间状态。
但这里有一个关键前提：必须在同一个文件系统内。如果你要把文件从一个磁盘移动到另一个磁盘，那就不是原子操作了，因为底层涉及到数据的物理拷贝。
另外，Windows 系统也提供了类似的保障。MoveFileEx 这个函数在不指定特殊标志的情况下，在同一个卷内的移动也是原子性的。
所以，操作系统其实已经帮我们做了一部分工作。问题在于，Java 的标准库在早期并没有很好地利用这个特性，而且即使利用了，如果使用不当，依然会出现并发问题。
三、Java 中的原子性重命名：Files.move
从 Java 7 开始，NIO.2 提供了一个非常好用的方法，可以直接调用操作系统底层的原子性重命名。
这个方法在 java.nio.file.Files 类中，名字就叫 move。它在同一个文件系统内执行重命名时，会直接调用操作系统的原子性 rename 操作。如果目标文件已经存在，它会抛出异常，而不是默默覆盖。
这一点非常关键。默认情况下，这个方法不会覆盖已存在的文件。这就从根本上避免了"一个线程的重命名覆盖另一个线程的结果"这种情况。
但这里有个细节需要注意：这个方法要求源文件和目标文件在同一个文件系统内。如果跨文件系统，它会尝试先复制再删除原文件，这就不是原子操作了。所以在使用之前，最好先判断一下源和目标是否在同一个文件系统上。
另外，这个方法在目标文件已存在时会直接报错，而不是覆盖。这是一种"失败即安全"的策略。相比于 silently overwriting，这种做法在并发场景下要可靠得多。
四、基于文件锁的并发控制
知道了原子性重命名的方法，但如果多个线程都要对同一个文件做重命名，即使每次重命名本身是原子的，多个原子操作之间依然会有冲突。
比如线程 A 和线程 B 都要重命名 file.txt，即使各自的重命名操作是原子的，但谁先谁后，结果是不确定的。而且如果其中一个失败了（因为目标文件已存在），整个业务逻辑就会出错。
这时候就需要引入文件锁。
Java NIO 提供了 FileChannel 和 FileLock，可以对文件加锁。在执行重命名之前，先获取文件的独占锁，执行完重命名后再释放锁。这样就能保证同一时间只有一个线程能操作这个文件。
具体的做法是：打开文件对应的 FileChannel，调用 lock 方法获取独占锁。获取锁之后，再执行重命名操作。操作完成后，在 finally 块中释放锁。
这种方式的好处是简单直接，不依赖任何外部工具。但也有局限性：文件锁在不同操作系统上的行为可能不一致。在某些系统上，文件锁只是建议性的，并不是强制性的。也就是说，另一个进程如果不遵守锁协议，依然可以操作这个文件。
所以，文件锁更适合单机多线程的场景，对于多进程或者分布式场景，就需要考虑其他方案了。
五、临时文件加原子提交：最稳妥的方案
如果你想要一个在各种场景下都足够稳妥的方案，我推荐使用"临时文件加原子提交"的模式。
这个模式的核心思路是：不直接对原文件做重命名，而是先把新内容写入一个临时文件，写入完成后，再用原子性重命名把临时文件替换掉原文件。
具体步骤如下：
第一步，生成一个带有随机后缀或者时间戳的临时文件名，确保这个名字在当前目录下是唯一的，不会和任何已有文件冲突。
第二步，把新内容写入这个临时文件。写入过程中，即使有其他线程或者进程在操作，也不会影响到原文件，因为操作的是一个全新的文件。
第三步，写入完成后，调用原子性重命名方法，把临时文件的名字改成目标文件名。由于重命名是原子操作，而且目标文件已存在时会报错而不是覆盖，所以这个替换动作要么完全成功，要么完全失败，不会出现中间状态。
第四步，如果重命名成功，再把原来的旧文件删除。注意，删除操作不需要是原子的，因为旧文件已经被替换了，删不删除都不影响数据的正确性。删除只是为了清理磁盘空间。
这个方案的优势在于：整个过程中，原文件始终是安全的。即使在写入临时文件的过程中程序崩溃了，原文件也不会受到任何影响。而最终的替换动作是原子的，不会出现覆盖丢失的问题。
很多成熟的系统都在使用这个模式，比如各种数据库的 WAL 日志写入、配置文件的热更新、日志文件的轮转等。
六、跨平台的注意事项
在实际项目中，你的代码可能需要在不同操作系统上运行。Windows、Linux、macOS，它们的文件系统行为有一些差异，需要特别注意。
第一个差异是路径分隔符。Windows 用反斜杠，Unix 系统用正斜杠。在构造文件路径时，建议始终使用 File.separator 或者 Paths.get 来拼接，不要手动拼字符串。
第二个差异是文件锁的行为。前面提到过，某些系统上的文件锁是建议性的。如果你的应用需要在这种系统上运行，就不能完全依赖文件锁来保证并发安全，需要结合其他手段，比如上面说的临时文件方案。
第三个差异是重命名的目标文件已存在时的行为。在大多数 Unix 系统上，rename 会直接覆盖目标文件。但 Java 的 Files.move 方法在这种情况下会抛出异常。如果你需要覆盖行为，需要显式指定 StandardCopyOption.REPLACE_EXISTING。但在并发场景下，我不建议使用覆盖选项，因为这会重新引入覆盖丢失的风险。
七、实际应用场景分析
说了这么多理论，来看几个实际场景。
场景一：日志文件轮转
定时任务需要把当前的日志文件按日期重命名。如果有多个定时任务实例同时运行，或者日志写入和轮转同时发生，就可能出问题。
解决方案：使用临时文件方案。先把日志写入带时间戳的临时文件，写入完成后原子性重命名为目标日志文件。如果重命名失败（说明目标已存在），就丢弃临时文件，等待下一次轮转。
场景二：文件上传
用户上传文件后，需要把临时文件改名为正式文件名。如果多个用户同时上传同名文件，或者上传过程中有其他操作，就可能出现覆盖。
解决方案：上传时直接使用带唯一标识的文件名（比如 UUID），上传完成后再原子性重命名为用户指定的文件名。这样即使并发上传，也不会互相干扰。
场景三：配置文件热更新
应用运行时需要更新配置文件。如果更新过程中有其他线程在读取配置，就可能读到不完整的数据。
解决方案：把新配置写入临时文件，原子性重命名覆盖旧配置文件，然后通知各个模块重新加载。由于重命名是原子的，读取方要么读到旧配置，要么读到新配置，不会读到一半旧一半新的内容。
八、一些容易踩的坑
最后总结几个实际开发中容易踩的坑。
第一个坑：使用 File.renameTo 而不是 Files.move。File 类的 renameTo 方法在不同 JDK 版本和不同操作系统上的行为不一致。有些情况下它会静默失败，有些情况下它会覆盖目标文件。在并发场景下，这种不确定性是致命的。务必使用 Files.move。
第二个坑：重命名后不检查返回值。Files.move 在成功时返回目标路径，失败时抛出异常。但有些开发者会忽略返回值，导致重命名是否成功无法确认。在关键场景下，一定要检查返回值或者捕获异常。
第三个坑：在重命名之前没有确保写入完成。如果你先写文件，然后立刻重命名，但写入操作还在缓冲区里没有刷到磁盘，重命名之后另一个进程可能读到一个空文件或者不完整的文件。解决办法是在重命名之前，先调用 FileChannel 的 force 方法把数据刷到磁盘，或者使用 StandardOpenOption.SYNC 选项打开文件。
第四个坑：忽略了同一个文件系统的前提。如果你的临时文件和目标文件不在同一个磁盘分区上，Files.move 就不是原子操作了。在使用之前，可以通过 FileStore 类来判断两个路径是否在同一个文件系统上。
写在最后
文件重命名看起来是个简单操作，但在并发场景下，它暗藏的风险不容小觑。
核心要点就三条：第一，优先使用 Java NIO 的 Files.move 方法，它在同一个文件系统内提供原子性保障；第二，在多线程或者多进程场景下，引入文件锁或者使用临时文件加原子提交的模式；第三，始终假设重命名可能失败，做好异常处理和回退逻辑。
把这三条做到位，文件重命名就不再是一个隐患，而是一个可靠的操作。
