在Java中锁定文件的存在 [英] Lock on existence of file in Java

查看:202
本文介绍了在Java中锁定文件的存在的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

简短版本:为什么 File.createNewFile() 不能用于文件锁定?或者更具体地说:如果它用于锁定应用程序数据目录会有问题吗?

Short version: Why should File.createNewFile() not be used for file locking? Or more specifically: Are there issues if it is used to lock an applications data directory?

详细信息:

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

I would like to protect my applications data directory using a lock file: If the file lock exists, the directory is locked and the application exits with an error message. If it does not exist it will be created and the application continues. On exit the file will be deleted.

不会经常创建锁(即性能不是问题),我手动删除锁文件没有问题如果出现一些错误(即无法删除文件不成问题)。

The lock will not be created that often (i.e. performance is not an issue) and I have no problem with manually deleting the lock file in case of some error (i.e. failing to delete the file is not an issue).

代码如下所示:

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
}

现在我对 Javadoc createNewFile()


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

注意:此方法应该用于文件锁定,因为无法使生成的协议可靠地工作。应该使用 FileLock 工具。

Note: this method should not be used for file-locking, as the resulting protocol cannot be made to work reliably. The FileLock facility should be used instead.

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

What are the potential problems mentioned in the note, considering the existence check and file creation are atomic?

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

This forum post from December 2007 indicates there are "significant platform differences" according to the Javadoc of File.delete() (although I cannot find such a statement since at least Java SE 1.4.2). But even if there would be such differences: Could they really cause the locking to fail (i.e. two processes think the data directory is usable at the same time)?

注意:需要以下任何内容:

Note: I do not want any of the following:


  • 锁定文件,以便其他进程无法访问和/或修改它(我发现的大多数信息似乎都在讨论此问题)。

  • 确保没有其他进程可以删除锁。

  • 同步同一个JVM的多个线程(虽然我认为我的解决方案也应该能够处理它)。

推荐答案

Files.createFile(...) java.nio.file ,重复了原子性的承诺,但没有提到任何关于基于文件的锁定。

The Javadoc of Files.createFile(…), part of java.nio.file available since Java 7, repeats the promise of atomicity but does not mention anything about file based locking.

我的理由:


  • 新的方法(来自 java.nio.file.Files )受到与旧版本相同(或类似)问题的影响(来自 java.io。文件)和Javadoc只是缺少这些信息...

  • ...或者新方法实际上表现得更加可预测和正确。

  • Either the newer method (from java.nio.file.Files) is affected by the same (or similar) problems as the older one (from java.io.File) and the Javadoc is simply missing this information…
  • … or the newer method actually behaves more predictably and correct.

鉴于中的错误处理和规范,java.nio.file 与<$ c $相比通常得到改善c>文件类(自JDK 1.2以来一直存在),我假设第二种选择是正确的。

Given the error handling and specification in java.nio.file has generally been improved compared to the File class (existing ever since JDK 1.2), I assume the second alternative is correct.

我的结论:使用 Files.createFile(...)适用于此用例。

My conclusion: Using Files.createFile(…) is fine for this use case.

这篇关于在Java中锁定文件的存在的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆