12MB のキャッシュを備えた 6 コアのマシンがあるとします。数ギガバイトのヒープを持つサーバー アプリケーションに使用します (その多くは第 2 レベルの Hibernate キャッシュです)。
ほとんどの場合、少数のスレッドがアクティブにクライアント リクエストを処理している (CPU を焼き尽くして DB と通信している) だけでなく、クライアントとの古い同期ネットワーク IO のみを実行している約 30 ～ 50 のスレッドがあることに気付きました。
Java メモリ モデルについて学習しているので、これがパフォーマンスに影響を与える可能性があるかどうか疑問に思っています。多くのネットワーク IO スレッドの 1 つのコンテキスト切り替えは、「アクティブな」スレッドのスレッド/CPU キャッシュを台無しにしますか? このレベルの同時実行性自体は有害ですか (メモリ キャッシュは別として)?
アプリケーションメモリ全体に対してCPUキャッシュがどれほど小さいかを考えると、それは本当に重要ですか? 境界がどこにあるかをどのように判断できますか?
多くのネットワーク IO スレッドの 1 つのコンテキスト切り替えは、「アクティブな」スレッドのスレッド/CPU キャッシュを台無しにしますか?
確固たる保証はありませんが、私の直感では、実際には、CPU キャッシュは、スケジューラがスレッドを切り替えるよりも桁違いに頻繁に更新されます。この場合、スレッド コンテキストの切り替えに必要なキャッシュの更新は、既に行われているキャッシュの更新に比べてオーバーヘッドが非常に小さくなります。
境界がどこにあるかをどのように判断できますか?
ほとんどのパフォーマンス関連の質問と同様に、実験と測定 (プロファイリング) によって行います。現代の PC で実際に起こっていることの現実は、合理的な近似よりも複雑であるため、単純な理論的近似は機能しません。
CPU よりも多くのアクティブなスレッドがある場合、影響があり、ジッターが発生する可能性があります。ただし、ジッターは通常、10 ～ 100 マイクロ秒と比較的小さいと考えられています。
キャッシュ リソースを求めてスレッドを競合させることはできますが、各スレッドが使用するアクティブ データの量を減らす以外にできることはあまりありません。これにより、CPU 負荷を 2 倍以上減らすことができますが、多くの作業が必要であり、完全な書き直し (一部の JDK およびサード パーティ ライブラリを含む) が必要になる可能性があり、メリットがほとんどない可能性があります。たとえば、CPU 負荷をどれだけ低くする必要がありますか。