ここで説明されているように、16kバッファを使用してFileChannel.writeを短時間連続して呼び出すことと、追加サイズが16kの複数のByteBufferをマッピングすることの違いを理解しようとしています：https ：//stackoverflow.com/a/7367952/962872
マップされたバイトバッファアプローチでは、追加するたびにMappedByteBufferを破棄するため、多くのガベージが生成されると思います。そして、私もそれが速いかどうかはわかりません。そして、あなたはまだたくさんのマッピング操作をしなければなりません...（追加ごとに1つ）。
または、巨大なByteBuffer（可能な限り大きい）をマップして、このMappedByteBufferに書き込み続ける必要がありますか？
私はファイルを書くための「速い」方法としてJava側の16kbバッファでFileChannel.writeアプローチを使用していますが、より速く/より良いものを見逃していないことを確認したいと思います。
誰かが光を当てることができますか？
マップされたバイトバッファアプローチでは、追加するたびにMappedByteBufferを破棄するため、多くのガベージが生成されると思います。
16KBのバッファを作成した場合になります。1 GBのバッファーを作成した場合、それほど多くのバッファーは必要なく、作成してもペナルティはほとんどありません（64ビットJVMを使用していると仮定）。
私はファイルを書くための「速い」方法としてJava側の16kbバッファでFileChannel.writeアプローチを使用していますが、より速く/より良いものを見逃していないことを確認したいと思います。
私はあなたがとにかくあなたが運転することができるより速くまたは速く書いているのではないことを確認します。メモリマップトファイルがもたらす主な利点は、通常のレイテンシがはるかに低いことです。書き込むことができるスループットは、ドライブの速度によって制限されます。一般的なSSDを使用している場合でも、CPUは消費できるよりも速くデータを書き出すことができます。また、HDDを使用している場合は、ドライブが非常に遅いため、何をしても問題ありません。
の典型的な書き込みスループット
多くの場合、CPUがボトルネックではない場合、ソフトウェアで行うことは、アプリケーションのパフォーマンスにほとんど影響を与えません。
レイテンシーに関しては、
それが存在するのであれば、それが重要であるとは思えません。MappedByteBuffersを介して入力を測定しましたが、20％しか高速ではなく、コードの変更を保証するには不十分でした。MappedByteBuffersを介した出力のコード変更は、ファイルを拡張するために特別な調整を行う必要があるため、かなり広範囲になります。これにより、メモリが不足するリスクが発生します。
IOは通常、ボトルネック、またはメモリの問題です（キャッシュ障害ですが、とにかく再割り当てする必要がある場合は問題ありません）。
可能な限り単純にコーディングします。次に、パフォーマンスが本当に問題になる場合は、とにかく別の方法を試してください（メモリパフォーマンスに関するifと例外が多すぎます）。あなたはおそらくすでにそれをやっています。