私の Java Web アプリケーションは NFS ファイル システムを使用します。FileOutputStream を使用して、ファイルを開き、複数のチャンクを書き込んでから閉じます。
プロファイラーの統計から、stream.write(byte[] payload,int begin, int length) と stream.flush() でさえ 0 ミリ秒かかることがわかりました。メソッド呼び出し stream.close() のみがゼロ以外のミリ秒かかります。
java FileOutputStream の write() または flush() は、実際には NFS クライアントが NFS サーバーにデータを送信する原因にはならないようです。NFSクライアントにリアルタイムでデータをフラッシュさせる他のJavaクラスはありますか? または、NFS クライアントのチューニングを行う必要がありますか?
おそらく、Unix のクライアント側のキャッシュが実行されています。詳細については、O'Reilly NFS bookを参照してください。
しかし、要するに：
バッファー キャッシュを使用し、非同期スレッドが複数のバッファーをクラスター化できるようにすると、複数のマシンが同じファイルを読み書きしているときに問題が発生します。同じファイルの複数のリーダーおよびライターによるファイルの不整合を防ぐために、NFS はフラッシュ オン クローズ ポリシーを設定します。ファイルが閉じられると、ファイルの部分的に満たされたすべての NFS データ バッファーが NFS サーバーに書き込まれます。
NFS バージョン 3 クライアントの場合、stable フラグをオフに設定して行われた書き込みは、コミット操作によってサーバーの安定したストレージに強制的に書き込まれます。
NFS キャッシュの一貫性は、close-to-open キャッシュの一貫性と呼ばれるアプローチを使用します。つまり、サーバー (および他のクライアント) がファイルの一貫した最新のビューを取得する前に、ファイルを閉じる必要があります。サーバーへのヒットを最小限に抑えることを目的としたこのアプローチの欠点が見えてきました。
キャッシュを回避することは、Java では困難です。open() O_DIRECTLinux を使用している場合は、ファイル フラグを設定する必要があります。https://stackoverflow.com/a/16259319/5851520の詳細については、この回答を参照してください。ただし、基本的には、サーバーではなく、そのファイルのクライアントの OS キャッシュを無効にします。
残念ながら、標準の JDK は公開していませんO_DIRECT。ここで説明されているように：ページキャッシュなしですべてのIOを行うようにJVMに強制します（例：O_DIRECT） -基本的に、JNIを自分で使用するか、適切なサードパーティのライブラリを使用します。JNA について良いことを聞きました: https://github.com/java-native-access/jna ...
または、クライアントのマウント ポイントを制御できる場合は、NFS マニュアルsyncに従ってマウント オプションを使用できます。それは言います：
マウント ポイントで sync オプションが指定されている場合、そのマウント ポイント上のファイルにデータを書き込むシステム コールは、システム コールがユーザー空間に制御を返す前に、そのデータをサーバーにフラッシュします。これにより、クライアント間のデータ キャッシュの一貫性が向上しますが、パフォーマンスが大幅に低下します。
これはあなたが探しているものかもしれません。
flush一般に、Java のストリームは、関連する Java クラスのバッファのフラッシュを除いて、影響について保証しません。
この制限を克服するには、Java NIO のチャネルを使用できます。たとえば、https://docs.oracle.com/javase/7/docs/api/java/nio/channels/FileChannel.html#force(boolean)を参照してください。ただし、「ファイルがローカル デバイスに存在しない場合、そのような保証はありません」。また、Java はそのような保証を行うことはできません。基盤となるリモート ファイル システムまたはプロトコルがその機能をまったく提供できない可能性があるためです。ただし、 @ SusanW が言及force()したネイティブ アクセスから得られるものと (ほぼ) 同じレベルの同期を達成できるはずです。O_DIRECT