java - java.io.FileDescriptor#sync() 是否特定于单个 FileDescriptor

Question

我希望在我的应用程序中的某些点写入文件后强制同步到磁盘。由于它在 Linux 上运行，我可以运行

Runtime.getRuntime().exec("sync");

但是，我宁愿不介绍 Linux 特定的系统调用，而宁愿使用

java.io.FileDescriptor#sync();

但是，我使用 Apache VFS 在本地文件系统上执行操作，据我所知，它不提供对底层文件描述符的访问。但是我是否需要访问刚刚写入的实际文件描述符以强制同步？例如，我可以不使用任何 FileDescriptor 来调用同步以获得相同的效果吗

FileDescriptor.in.sync();

这是否是一种有效的方法，结果是否与在 Linux 中调用 sync 的结果相匹配？

以防万一有人知道是否/如何可以访问 VFS 中的底层 FileDescriptor，了解它也会很有用。

编辑:看来

FileDescriptor.in.sync();

不想在 Linux 上工作(尽管从 Eclipse 运行时它在我的 Windows 机器上工作)，但是

new FileOutputStream(new File("anyfile")).getFD().sync();

绝对有效，调用它的结果与直接调用 Linux sync 命令的结果相匹配。但是，它涉及到打开和关闭冗余文件输出流，所以它并不十分理想。这可能是个坏主意的任何其他原因，因为它似乎确实有效？是否有其他方法获取可用于同步的 FileDescriptor？

Answer 1

我前段时间调查过这样的问题:Question 1 , Question 2 .

在 Linux 中，一个 java.io.FileDescriptor#sync调用确保与描述符关联的文件的修改数据被发送到磁盘。 (那个便宜的磁盘往往会跳过写入，只将数据放在不可靠的(也就是没有 NVRAM)写入缓存中，这是一个不同的/额外的问题。)它不保证其他文件的修改数据也被写回。这只是不在同步契约(Contract)或基础契约(Contract)中 fsync POSIX function .

但是，在某些情况下(例如 data=ordered 模式下的 ext3)，an fsync on a file writes back up modified data of the file system .这真的很有趣，因为这可能会产生显着的延迟，因为其他一些应用程序已经创建了大量的脏 block 。