Java FileChannel.force() 和 StandardOpenOption.Sync 之间有什么区别？
我不确定新的 Java 7 nio.file.StandardOpenOption 与旧的 FileChannel.force() 方法。
有没有办法也做 O_DIRECT ？
I'm not sure if the new Java 7 nio.file.StandardOpenOption is different from the old FileChannel.force() method.
Is there a way to do O_DIRECT also?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为两者之间的区别在于，StandardOpenOption 会自动执行此操作，而您必须调用 FileChannel.force() 才能将数据发送到底层存储设备。我不确定 O_DIRECT。
I think the difference between the two is that
StandardOpenOptiondoes it automatically while you have to callFileChannel.force()to send the data to the underlying storage device. I'm not sure about O_DIRECT.使用 JVM 不可能执行 O_DIRECT IO。 （我认为）原因之一是，文件内容所在的内存需要与 512 字节边界对齐。使用 ByteBuffers 分配的内存不满足此属性。
与512字节对齐类似的另一个问题是只能执行512字节倍数的IO操作。所以如果你想读取一个700字节的文件，你就会遇到麻烦。
这是一个提出这些问题的类似线程。
我描述了一种方法 在我的博客中如何实现直接IO到JVM中。它还包含如何向
StandardOpenOption类添加 O_DIRECT 选项的提示（您必须将该常量添加到文件/src/solaris/native/sun/nio/fs/genUnixConstants .c在 JDK 源代码中）it is not possible to do O_DIRECT IO using the JVM. One of the reasons (I think) is, that the memory where the file contents go need to be aligned to some 512 bytes boundaries. Memory allocated with
ByteBuffersdon't fulfill this property.Another problem which is similar to this 512 bytes alignment is that you can only perform IO operations that are multiples of 512 bytes. So if you want to read a file that has 700 bytes, you'll have troubles.
Here is a similar thread that presents these issues.
I described a way in my blog how to implement direct IO into the JVM. It also contains a hint how you could add a O_DIRECT option to the
StandardOpenOptionclass (you have to add the constant to the file/src/solaris/native/sun/nio/fs/genUnixConstants.cin the JDK sources)