Java 涉及同一文件的两个FileChannel实例上的FileChannel.force（）

（

fsync

通过将目录作为常规文件打开来对其进行加密）中的发现似乎意味着

FileChannel#force（）

适用于对文件所做的所有更改，而不管使用了哪个文件描述符

在这个提示下，我尝试优化我的文件编写过程，这样我就可以启动一个后台线程，打开同一个文件并在循环中对其调用

force（false）

。当我的主写线程到达末尾并调用

force（false）

本身时，它应该会经历更少的阻塞，因为脏缓存页中剩下的数据会更少。这是我写的代码：

private static class Fsyncer implements Runnable {
    volatile File requested;
    File actual;
    FileChannel fc;

    @Override public void run() {
        try {
            while (!interrupted()) {
                if (requested != actual) {
                    if (fc != null) {
                        fc.close();
                        actual = requested;
                        fc = new FileInputStream(actual).getChannel();
                    }
                }
                if (fc != null) {
                    fc.force(false);
                }
            }
        } catch (InterruptedException e) {
            // thread done
        } catch (IOException e) {
            throw new RuntimeException(e);
        }
    }
}

用法：

Thread fsyncerThread = new Thread(fsyncer);
fsyncerThread.start();
writeFiles();
fsyncerThread.interrupt();

最后，

writeFiles（）

fsyncer.requested = file;

每次打开另一个文件时

然而，我没有测量任何有背景强制线程和没有背景强制线程的差异

上的文档并不完全清楚：它说它将保证“通过此类中定义的方法”强制执行所有更改，但没有确切说明它是否仅适用于相同的
FileChannel
实例

上面的两个事实似乎是矛盾的：如果强制目录的黑客攻击是可靠的（Lucene团队已经通过实际关闭机器进行了测试），那么我的后台强制技术也应该起作用

由于应用于
fsync
ing目录的某些特殊行为（这不适用于我的情况），目录强制技术是否可靠？或者可能是来自另一个FD的更改仅在FD关闭后传播？我正在寻找一个解释来解释这两个发现。
A
FileInputStream
为您提供了一个只读的
FileChanne
l，对于它，
force（）
操作毫无意义。尝试通过
RandomAccessFile获取的
FileChannel
。
但我不明白为什么您首先有两个实例。你对UB很感兴趣。用一个通道试试。但目录fsync hack的唯一工作方式是以只读模式打开文件。事实证明它是有效的。甚至
force（）
上的文档也指出强制只读通道可能导致文件写入操作。然而，在我的例子中，我也可以使用相同的通道实例。