指定された長さと少なくとも同じ大きさを取得でき、使用中のオブジェクトをロックして、コードで使用されている間は使用できないようにするByteBufferリサイクルクラスをどのようにコーディングするのだろうかと思っています。これにより、既存のものを使用する代わりに、などを何度も再構築することができなくなります。これを非常に効果的に実行できる既存の Java ライブラリはありますか? Javolution がオブジェクトのリサイクルに対応できることは知っていますが、要件が設定されているこのコンテキストのクラスにそれが適用されるのでしょうか?ByteBufferByteBufferDirectByteBuffersByteBuffer
2353 次
3 に答える
4
そもそも、使用パターンをより保守的にすることが重要です。たとえば、OP_READ ごとに新しい ByteBuffer の割り当てを示す多くのコードがあります。これは非常識です。接続ごとに最大 2 つの ByteBuffers が必要です。1 つは入力用、もう 1 つは出力用です。何をしているかによっては、正確に 1 つを使用することができます。エコー サーバーのような非常に単純なケースでは、アプリケーション全体に対して 1 つの BB で済ますことができます。
ソフトウェアのさらに別のレイヤーで亀裂を埋めるのではなく、それを調べます。
于 2010-02-26T07:23:47.890 に答える
3
これは単なるアドバイスであり、答えではありません。DirectByteBuffer のキャッシュを実装する場合は、GC の影響について必ず読んでください。DirectByteBuffer によって消費されるメモリはガベージ コレクターによって追跡されないためです。
参考文献:
于 2010-02-26T04:05:19.150 に答える
1
通常、ThreadLocal と SoftReference ラッパーを組み合わせて使用します。同期を簡素化するための前者（本質的にその必要性を排除します）。後者は、十分なメモリがない場合にバッファをリサイクル可能にするためです（ダイレクトバッファに関するGCの問題に関する他のコメントに留意してください）。実際には非常に簡単です。SoftReference に十分なサイズのバッファがあるかどうかを確認します。そうでない場合は、割り当てます。はいの場合は、参照をクリアしてください。作業が完了したら、バッファを指すように参照を再設定します。
別の質問は、通常の byte[] と比較して、ByteBuffer が必要かどうかです。多くの開発者は、ByteBuffers の方がパフォーマンス的に優れていると想定していますが、その想定は通常、実際のデータによって裏付けられているわけではありません (つまり、パフォーマンスに違いがあるかどうか、およびどのような方向性があるかを確認するためのテスト)。byte[] がしばしば高速になる理由は、それにアクセスするコードがより単純になり、HotSpot が効率的に JIT を実行しやすくなるためです。
于 2010-05-23T03:02:54.343 に答える