問題タブ [filechannel]

ByteBuffersおよびを使用しFileChannelsて、バイナリ データをファイルに書き込みます。大きなファイルに対して、または複数のファイルに対して連続してそれを行うと、OutOfMemoryError例外が発生します。BytebuffersNIO での使用は壊れており、避けるべきであることを他の場所で読みました。すでにこの種の問題に直面していて、大量のバイナリ データを Java のファイルに効率的に保存するための解決策を見つけた人はいますか?

jvm オプションを使用-XX:MaxDirectMemorySizeする方法はありますか?

次のコードがあります。

しかし、文字は ? で表示されます。これは、Unicode 文字を使用する Java と関係がありますか? これを修正するにはどうすればよいですか?

RandomAccessFile を使用して、トランザクションの一部としてファイルへの書き込みを実行しています。トランザクションをコミットする前に、データがディスクに書き込まれていることを完全に確認したいと考えています。force(boolean)RAFを呼び出すとFileChannelこの保証が得られるように見えますが、ファイルを閉じるときに暗黙的に呼び出されるのでしょうか、それとも手動で呼び出す必要がありますか?

force()また、実際に何をしているのか、そしてそれがどこまで信頼できるのかについての洞察を誰かが持っていますか? OS がデータがディスクに書き込まれたことを報告する可能性はありますか?実際にはまだどこかのキャッシュに残っていますか? OS/HDD/ファイルシステムにどの程度依存していますか?

使用しているライブラリにいくつかの変更を加えているところです。メモリ使用量を減らすために、ライブラリは一時データをメモリに保持する代わりにディスクに書き込みます。ただし、私の使用シナリオでは、メモリに保持する方が効率的です。また、一時ファイルの名前が一定であり、異なるスレッドで同時に実行できないため、並行性の問題もあります (スレッドが互いのデータを破損するため)。

したがって、代わりにすべてのデータをメモリに保持するようにライブラリを変更する必要があります。私は最初にライブラリを作成したことがないため、コードを大幅に変更することにあまり慣れていません。したがって、できるだけ少ないリファクタリングでこれを行いたいと思います。ディスクに書き込むコードは非常に単純です。以下は (やや簡略化された) 例です。

ブロックの読み取りは非常に似ています (つまり、RandomAccessFile から取得する FileChannel を使用します)。

ファイルではなくメモリ内の場所にマップする FileChannel の実装を使用できる場合、最も簡単な解決策のように感じます。FileChannel の map-method を使用して、ファイルをメモリ内の場所にマップできることを知っています。しかし、それは逆です。これにより、ファイルへの「メモリ API」が得られます。一部のメモリに対して FileChannel インターフェイスが必要です。これの利用可能な実装はありますか?

データをクラスタリングするために作成した反復アルゴリズム中に (多かれ少なかれ) ランダムにアクセスする double の大きな (3Gb) バイナリ ファイルがあります。各反復では、ファイルから約 50 万回の読み取りと、新しい値の約 10 万回の書き込みが行われます。

このように FileChannel を作成します...

次に、double のサイズのプライベート ByteBuffer を使用して、そこから読み取ります

私の読み取りコードは次のようになります

そして私はそれにこのように書いています...

コードの繰り返しにかかる時間は、読み取り回数にほぼ比例して増加します。読み取り回数を最小限に抑えるために、周囲のコードに多くの最適化を追加しましたが、現時点では回避したいアルゴリズムの動作を根本的に変更することなく、必要と思われるコア セットにいます。

私の質問は、読み取り/書き込みコードまたは JVM 構成に、読み取りを高速化するためにできることがあるかどうかです。ハードウェアを変更できることはわかっていますが、その前に、問題からソフトウェア ジュースを最後の一滴まで絞り出したことを確認したいと考えています。

前もって感謝します

FileChannel を指定して .gz ファイルを読み取り/解凍する必要があります。

GZIPInputStream を使用して GZIP アーカイブを抽出してみましたが、これは FileChannel を使用しません。FileChannel が取得された元の FileInputStream にアクセスできません。

誰かが FileChannel から GZIP を読み取る良い方法 (または少なくとも任意の方法) を教えてくれたら、大いに感謝します。

Sun Oracle フォーラムでの質問から引用。

java.util ロギング クラスを使用して、ローリング ファイル アペンダーを作成しています。データが書き込まれるときにこれらのログから読み取るログ リーダーを作成したいと考えています。

ローリング ログ アペンダー コードは、単独で正常に動作します。しかし、一度リーダー スレッドを開始すると、新しいファイルは作成されません。つまり、ローリング ログ アペンダーが 5 つのファイルを使用するように設定されている場合、1og.0、log.1、log.2 などが作成されますが、リーダー スレッドが開始された場合は、 create log.0 他のファイルは作成されません。これは、Java ロギングと log4j の両方でわかります。

ログリーダーで読み取るためにnioを使用しています。私の疑問は、同じファイルに別の FileChannel を作成すると問題が発生することですか? または、ここで問題を引き起こしている基本的な nio のいくつかを見逃していますか。

ここにコードがあります..

今、それを明確にして、FileOutputStreamとFileChannelの間にいくつかの類似点を描きたいと思います。

したがって、まず第一に、標準のJava ioでファイルを書き込む最も効率的な方法は、BufferedOutputStreamでラップされたFileOutputStreamを使用することであるように思われます。自動的にフラッシュするため、内部バッファがオーバーフローした場合。配列の書き込みだけでなく、シングル書き込み（シングルバイト、フロートなど）も実行でき、速度を気にしないと便利です。決して忘れてはならない唯一のことは、それを閉じることです（最後のフラッシュを実行するため）。BufferedOutputStreamラッパーを使用する利点は明らかであり、すべての人にとって必要です（私は願っています）。

次にFileChannelについて。FileChannelには、FileOutputStreamのflushと同等のforceメソッドがありますね。そしてjavadocsは、ターゲットファイルに変更が加えられたことを確認するためにそれを使用する必要があることを明確に述べています。しかし、「BufferedFileChannel」ラッパーがない場合、いつ、なぜそれを使用する必要があるのか​​わかりません。言い換えれば、FileChannelのバッファリングはどこにありますか？それは自動で、BufferedOutputStreamのようにFileChannel自体に隠されていますか？そうでない場合は、強制するものがないため（writeメソッドを使用した後、すべての変更がファイルにすでに適用されているため）、なぜforceメソッドが必要になるのでしょうか。また、自分でバッファリングを実装する必要がありますか？

オンライン ストリームをローカルに保存し、ローカル ノードからストリームを配信しようとしています。

プログラムの流れ:

最初の URL 要求 url-test は、ファイル名 url-file でファイル システムへの書き込みを開始する単一のライター スレッドを作成します。その URL url-test に対する後続のすべての要求は、ローカル ファイル システムから処理されます。

ライタースレッド

次のリクエストでは、ローカルに保存されたファイル url-file を読み取り、最後に保存された位置に移動する必要があります。cv オブジェクトの totalBytes 属性を使用しています。これにより、ライター スレッドによって保存された合計バイト数が得られます。

出力が表示されません。別のスレッドによって更新されているファイルを検索する最良の方法は何ですか。

EDIT：ライタースレッドがファイルへの書き込みを継続し、リクエストに対する応答がその時点から開始されることを期待しています。一言で言えば、ファイル チャネルで位置を設定するときに、ライター スレッドはまだファイルに書き込みを行っています。ファイル チャネルの位置を 25% 少なく設定しても、inc.position(totalBytes - (long) 0.25 * totalBytes)まだ出力が表示されません。

Javaでテキストファイルを連結するために思いついた2つの方法のうち、どちらが優れているかを知りたいと思います。FileChannelへのこれらの書き込み方法の違いを説明するカーネルレベルで何が起こっているかについて誰かが共有できる洞察を持っているなら、私はそれを大いに感謝します。

ドキュメントやその他のStackOverflowの会話から私が理解していることから、allocateDirectはドライブにスペースを割り当て、ほとんどの場合RAMの使用を回避します。ファイルのファイルが大きい場合、たとえば1GBの場合、allocateDirectで作成されたByteBufferがオーバーフローしたり、割り当てられなかったりする可能性があるのではないかと心配しています。ソフトウェア開発のこの時点で、ファイルは2GB以下であることが保証されています。ただし、将来的には10GBまたは20GBになる可能性があります。

transferFromループがループを2回以上通過することはないことを確認しました...したがって、infile全体を一度に書き込むことに成功したようです。しかし、60MBを超えるファイルではテストしていません。ただし、ドキュメントには一度に書き込まれる量の保証がないと指定されているため、ループしました。transferFromは、私のシステムでは、カウントパラメータとしてint32しか受け入れることができないため、一度に2GBを超える転送を指定することはできません...繰り返しになりますが、カーネルの専門知識が理解に役立ちます。

よろしくお願いします!!

ByteBufferの使用：

trasferTo（またはtransferFrom）の使用：