java - 网络文件系统中的 java.io.File.createNewFile() 是原子的吗？

Question

编辑:好吧，几个月后我回来了，我尝试编码的锁定机制不起作用，因为 createNewFile 在 NFS 上不可靠。检查下面的答案。

---

这是我的情况:我只有 1 个应用程序可以访问这些文件，所以我对其他应用程序可以做什么没有任何限制，但是该应用程序在生产环境中的多个服务器上同时运行以实现冗余和性能目的(几台机器分别托管几个 JVM 和我们的应用程序)。

基本上，我需要的是在文件夹中放置某种标志，告诉其他实例不要管这个文件夹，因为另一个实例已经在处理它。

---

许多搜索结果都告诉我们要使用 FileLock 来实现这一点，但我检查了 Javadoc，据我所知，它不会有太大帮助，因为它使用了托管操作系统的锁定可能性。所以我怀疑它会有多大帮助，因为有不同的主机。

这个问题涵盖了一个类似的主题:Java file locking on a network ，并且接受的答案是建议实现您自己的合作锁定过程(使用 OP 要求的 File.createNewFile())。

---

File.createNewFile() 的 Javadoc 说如果文件不存在，进程将自动创建文件。这在网络文件系统中可靠地工作吗？

我的意思是，由于潜在的网络延迟，怎么可能同时进行存在性检查和创建？ :

The check for the existence of the file and the creation of the file if it does not exist are a single operation that is atomic with respect to all other filesystem activities that might affect the file.

Answer 1

不，createNewFile 在网络文件系统上无法正常工作。

即使系统调用是原子的，它也只是操作系统的原子，而不是网络上的。随着时间的推移，我遇到了几次冲突，比如每 2-3 个月一次(大约每 60 万个文件一次)。

发生的事情是我的程序在 2 个独立服务器上的 6 个独立实例中运行，所以我们称它们为 A1、A2、A3 和 B1、B2、B3。
当 A1、A2 和 A3 尝试创建相同的文件时，操作系统可以正确地确保只创建一个文件，因为它正在与自己一起工作。
当 A1 和 B1 试图在同一时刻创建相同的文件时，会发生某种形式的网络缓存和/或网络延迟，并且它们都从 File 返回一个 true。 createNewFile().
然后我的代码通过重命名父文件夹来阻止程序的其他实例不必要地尝试处理该文件夹，这就是它失败的地方:

• 在A1上，文件夹重命名操作成功，但无法删除锁定文件，所以A1就这样，继续处理新传入的文件夹。
• 在 B1 上，文件夹重命名操作(File.renameTo()，无法修复它)陷入无限循环，因为文件夹已经重命名(也导致巨大的根据我的系统管理员的 I/O 流量)，B1 在程序重新启动之前无法处理任何新文件。