在Java中锁定文件的存在

Question

简短版本:为什么File.createNewFile()不应该用于文件锁定？或者更具体地说:如果用于锁定应用程序数据目录,是否存在问题？

---

细节:

我想使用锁定文件保护我的应用程序数据目录:如果该文件lock存在,则该目录被锁定,并且应用程序退出并显示错误消息.如果它不存在,将创建它并继续应用程序.退出时,文件将被删除.

锁定将不会经常创建(即性能不是问题),并且在出现某些错误时手动删除锁定文件没有问题(即无法删除文件不是问题).

代码看起来像这样:

File lockFile = new File("lock");
boolean lockCreated = lockFile.createNewFile();
if (lockCreated)
{
    // do stuff
    lockFile.delete();
}
else
{
    System.err.println("Lockfile exists => please retry later");
    // alternative: Wait and retry e.g. 5 times
}

现在我对JavadoccreateNewFile()有点困惑:

当且仅当具有此名称的文件尚不存在时,以原子方式创建由此抽象路径名命名的新空文件.检查文件是否存在以及文件的创建(如果不存在)是针对可能影响文件的所有其他文件系统活动的原子操作.

注意:此方法不应用于文件锁定,因为无法使生成的协议可靠地工作.的的FileLock设施应改为使用.

考虑到存在检查和文件创建是原子的,注释中提到的潜在问题是什么？

2007年12月的这篇论坛帖子表明,根据File.delete()的Javadoc,存在"显着的平台差异" (尽管至少从Java SE 1.4.2开始我找不到这样的声明).但即使存在这样的差异:它们真的会导致锁定失败(即两个进程认为数据目录同时可用)？

---

注意:我不想要以下任何内容:

• 锁定文件,以便其他进程无法访问和/或修改它(我发现的大多数信息似乎都在讨论这个问题).
• 确保没有其他进程可以删除锁定.
• 同步同一JVM的多个线程(虽然我认为我的解决方案也应该能够处理它).

Answer 1

简短的回答：Java 中可靠的基于文件的锁定并不实用。

长答案：在任何操作系统中，基于文件的锁定问题始终取决于文件来自哪种存储系统。几乎所有网络访问的文件系统（NFS、SAMBA 等）在文件创建或删除方面都具有非常不可靠（或至少不可预测）的同步，这使得一般的 Java 风格的方法变得不可取。在某些操作系统中，使用本地文件系统，有时您可以获得您想要的东西。但您需要了解底层文件系统及其特性并谨慎操作。