私は単純なクライアント/サーバーアプリケーションを書いています.DataInputStreamを使用してデータを読み取ると、読み取るものを選択できるため(バイトから自分で変換する必要はありません)、非常に便利であることがわかりましたが、そうなるかどうか疑問に思っていますBufferedInputStream にもラップするのが最善ですか、それとも不要なオーバーヘッドが追加されるだけですか?
私が質問している理由は、ソケット ストリームから直接読み取るのにどれだけコストがかかるかわからないためです (BufferedInputStream を使用する場合、ソケット ストリームから 1 回だけ読み取ってから、DataInputStream を使用して BufferedInputStream から時間を掛けます)。
通常、受信するデータは非常に小さく、約 20 ～ 25 バイトです。
ご回答ありがとうございます。:D
DataInputStream はバッファリングされないため、DataInputStreamオブジェクトに対する各読み取り操作は、基盤となるソケット ストリームで 1つ以上の読み取りを実行し、複数のシステム コール (または同等の呼び出し) が発生する可能性があります。
通常、システム コールは、通常のメソッド コールよりも 2 ～ 3 桁高くなります。バッファリングされたストリームは、通常のメソッド呼び出しのレイヤーを追加することを犠牲にして、システム呼び出しの数を (理想的には 1 に) 減らすことによって機能します。通常、バッファリングされたストリームを使用すると、N 個の syscall が 1 個の syscall と N 個の追加のメソッド呼び出しに置き換えられます。N が 1 より大きい場合、あなたの勝ちです。
したがって、ソケット ストリームと DataInputStream の間に BufferedInputStream を配置してもうまくいかない唯一のケースは次のとおりです。
read...()、それが 1 つのシステムコールで満たされる場合、read(byte[] ...)呼び出しのみを行う場合、またはこれらはあなたの場合には当てはまらないようです。
さらに、それらが適用されたとしても、必要のないときに BufferedInputStream を使用するオーバーヘッドは比較的小さいです。必要なときに BufferedInputStream を使用しない場合のオーバーヘッドは、非常に大きくなる可能性があります。
最後のポイントとして、読み取られるデータの実際の量 (つまり、メッセージのサイズ) は、バッファありとバッファなしの難問とはほとんど関係がありません。本当に重要なのは、データを読み取る方法です。つまり、アプリケーションが行う一連のread...()呼び出しです。
一般的な知恵として、基になるストリームの個々の読み取りは非常に遅いため、ほとんどの場合、バッファリングの方が高速です。ただし、このような小さな数 (20 ～ 25 バイト) の場合、バッファーを割り当てるコストは、個々の読み取りを行うコストと同様になる可能性があります (メモリ割り当てとガベージ コレクションを考慮すると)。残念ながら、確認する唯一の方法は、テストして確認することです。
受信するデータは通常小さいとのことですが、より大きなメッセージはどれくらいの頻度で予想されますか? バッファリングされていないストリームで時折大きなメッセージを受信する場合、これは重大なボトルネックになります。
いくつかのタイミング テストを実行して、バッファリングがケースに違いをもたらすかどうかを確認することをお勧めします。または、タイミング テストを気にせずに、バッファを使用します。将来、メッセージ サイズが変更された場合、これにより、後でメンテナンスが軽減されます。