java - 多くのネストされた BufferedInputStream の影響は?

Question

ストリームからのデータを処理するアプリケーションの各レイヤーが、それを BufferedInputStream にラップする傾向がある場合、一般的なパターンがあります。そのため、全体として、多くのバッファー、バッファーからの入力、バッファーからの入力などがあります。

これは悪い習慣だと思います。質問したいのですが、パフォーマンスにどのような影響がありますか? これはバグを引き起こす可能性がありますか?

Answer 1

これは非常に一般的な質問ですが、(言語を問わず) バッファリングされた入力ストリームのレイヤーが多数ある場合、多くの問題があると思います。

• 各バッファは、いっぱいになっていない場合でもメモリを消費します。そのため、データがすぐに一番上の「レイヤー」まで吸い込まれたとしても、メモリは依然として不必要に使用されています。(注: Java はバッファーのサイズを自動的に変更したり、何かをしたりしないと想定しています。私は Java の専門家ではありません。)
• トップレベルのバッファから読み取るときはいつでも、メソッド呼び出しの大きなチェーンを開始することになります。メソッド呼び出しには、間接化 (つまり、ポインターの追跡)、データの受け渡し (キャッシング パフォーマンスの低下につながる可能性があります) などが含まれます。
• バッファリングされたストリームは、通常、ディスクやネットワークなど、実際にバッファリングが必要なソースから読み取るためのものであるため、おそらく設計が十分に考えられていないことを意味します。

問題についてのほんの少しの考え。Java の知識が豊富な人が、より詳細な分析に貢献できると確信しています。

Answer 2

余分なバッファのためにメモリフットプリントが増加しますが、特定のプログラムに実際に大きな影響を与える可能性があるサイズを考えると、それはまれだと思います. 必要になる前に最適化を試みないという標準的なルールがあります。

わずかなプロセッサ オーバーヘッドもあるはずですが、これはそれほど重要ではありません。

どれだけ使うかにもよりますが、大きなチェーンが多いと問題になる可能性がありますが、問題になる可能性は低いと思います。

デビッドが言ったように、それは設計が不十分であることを示している可能性があります。コンポーネントがより複雑なオブジェクトを直接共有できる方がおそらく効率的ですが、それはすべて特定の用途にかかっています(そして、あなたがそうする理由を考えるのに苦労していますそのような方法で複数のバッファリングされたストリームを使用します)。

Answer 3

これは非常に悪い習慣であり、実際にバグを引き起こす可能性があります。メソッド A が何らかの読み取りを行ってから、そのストリームをメソッド B に渡し、メソッド B が BufferedInputStream をアタッチしてさらに読み取りを行う場合、BufferedInputStream はそのバッファーを満たし、メソッド B が戻ったときにメソッド A がまだそこにあると想定しているデータを消費する可能性があります。メソッド B の BufferedInputStream の先読みによって、データが失われる可能性があります。

オーバーヘッドに関しては、実際には、読み取り/書き込みが十分に大きい場合、中間バッファーはとにかくバイパスされるため、余分なコピーはほとんどありません。パフォーマンスへの影響は、主に余分なメモリ領域と余分なメソッド呼び出し。