简短版:为什么不应该使用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
}
现在我对createNewFile()
的 Javadoc 有点困惑:
原子地创建由该抽象路径名命名的新空文件,仅当尚不存在具有此名称的文件时。检查文件是否存在以及如果不存在则创建文件是一项单个操作,该操作在与可能影响文件的所有其他文件系统活动相对于原子引用。
注意:该方法不应用于文件锁定,因为无法使结果协议可靠工作。应改为使用FileLock设施。
考虑到存在检查和文件创建是原子的,笔记中提到了哪些潜在问题?
来自2007年12月的这篇论坛帖子指出根据 File.delete()
的 Javadoc,存在“显着的平台差异”(尽管我至少在 Java SE 1.4.2之后没有找到这样的说明)。但即使存在这样的差异:它们真的能导致锁定失败(即两个进程同时认为数据目录可用)吗?
注意:我不想要以下任何内容:
- 锁定文件,以便其他进程无法访问和/或修改它(大多数信息似乎都在讨论此问题)。
- 确保没有其他进程可以删除锁定。
- 同步同一JVM的多个线程(尽管我认为我的解决方案应该能够处理这种情况)。