以下は、書籍 Java Concurrency in Practice の第 12.2 章パフォーマンスのテストからの抜粋であり、著者はバウンド バッファー実装のスループットについて語っています。
図 12.1 は、1、10、100、および 1000 のバッファー容量を使用した 4 ウェイ マシンでのサンプル結果を示しています。バッファー サイズが 1 の場合、スループットが非常に低下することがすぐにわかります。これは、各スレッドがブロックして別のスレッドを待機する前に、ほんの少ししか進行できないためです。バッファー サイズを 10 に増やすと劇的に効果がありますが、10 を超えると、収益が減少します。
最初は、スレッドを追加してもパフォーマンスがわずかに低下するだけであることに戸惑うかもしれません。その理由をデータから確認するのは困難ですが、テストの実行中に perfbar などの CPU パフォーマンス メーターで確認するのは簡単です。多くのスレッドがあっても、計算はあまり行われず、そのほとんどがスレッドのブロックとブロック解除に費やされます。 . そのため、パフォーマンスをあまり損なうことなく、より多くのスレッドが同じことを行うための十分な CPU スラックがあります。
ただし、このデータから、バウンド バッファーを使用するプロデューサー/コンシューマー プログラムにいつでもスレッドを追加できると結論付けないように注意してください。このテストは、アプリケーションをシミュレートする方法がかなり人為的です。プロデューサーは、キューに配置されたアイテムを生成するためにほとんど作業を行わず、コンシューマーは、取得されたアイテムに対してほとんど作業を行いません。実際のプロデューサー/コンシューマー アプリケーションのワーカー スレッドがアイテムを生成および消費するために重要な作業を行う場合 (一般的にそうです)、このスラックはなくなり、スレッドが多すぎることによる影響が非常に顕著になる可能性があります。このテストの主な目的は、バウンド バッファーを介したプロデューサーとコンシューマーのハンドオフが全体のスループットに課す制約を測定することです。
ここでのcpu slackとはどういう意味ですか? より多くのスレッドを追加してもスループットが低下しないのはなぜですか? 私は、バッファ サイズの制限が一定に保たれていると仮定して、スレッドを追加するとパフォーマンスがわずかに低下するという著者の説明には従いません。
編集：私は1つの理由を考えることができます：この場合、スレッドによって実際の作業が行われていないため、共有メモリバス上のトラフィックの増加という古典的な問題、スレッドのコンテキスト切り替えによるキャッシュミスの数は大きな役割を果たしていませんますます多くのスレッドが追加されています。スレッドがもう少し作業を開始すると、状況が変わります。それが、この第 3 パラグラフで著者が伝えようとしていることですか?