简短版：为什么不应该使用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的多个线程（尽管我认为我的解决方案应该能够处理这种情况）。