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

Question

我希望在我的应用程序中的某些点写入文件后强制同步到磁盘.因为它在Linux上运行,所以我可以逃避运行

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

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

java.io.FileDescriptor#sync();

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

FileDescriptor.in.sync();

这是一种有效的方法,结果是否与Linux中调用同步的结果相匹配？

万一有人知道是否可以如何访问VFS中的底层FileDescriptor,那么知道也是有用的.

编辑:看起来

FileDescriptor.in.sync();

不想在Linux上运行(虽然它在从Eclipse运行时可以在我的Windows机器上运行),但是

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

肯定是有效的,调用它的结果与直接调用Linux sync命令的结果相匹配.但是,它涉及打开和关闭冗余文件输出流,因此它并不完全理想.任何其他原因这可能是一个坏主意,因为它似乎有效吗？是否有其他方法可以获得可用于同步的FileDescriptor？

Answer 1

我前段时间调查过这样的问题：问题1，问题2。

在 Linux 中，java.io.FileDescriptor#sync调用可确保将与描述符关联的文件的修改数据发送到磁盘。（便宜的磁盘往往会跳过写入，只将数据放入不可靠（也称为非 NVRAM）写入缓存中，这是一个不同/额外的问题。）它不保证其他文件的修改数据也会被写回。这不属于sync 或底层fsync POSIX 函数的约定。

然而，在某些情况下（例如 data=ordered 模式下的 ext3），文件上的 fsync 会写回文件系统的修改数据。这真的很有趣，因为这可能会产生显着的延迟，因为其他一些应用程序创建了大量的脏块。