Java 1.6 x64で多くのスレッドを待機状態にするのは、どれほどの費用がかかるのでしょうか。
具体的には、多くのコンピューターで実行され、データを相互に送受信するアプリケーションを作成しています。1）データの送信、2）データの受信、3）データが切断されたときに接続を再確立するなど、接続されたマシンとタスクごとに個別のスレッドを使用する方が快適です。したがって、クラスター内にN個のノードがあるとすると、各マシンには、N-1個のネイバーごとに3つのスレッドがあります。通常、12台のマシンがあり、33の通信スレッドになります。
これらのスレッドのほとんどはほとんどの時間スリープしているので、最適化の目的で、スレッドの数を減らし、各スレッドにより多くのジョブを与えることができます。たとえばのように。接続の再確立は、スレッドを受信する責任があります。または、接続されているすべてのマシンへの送信は、シングルスレッドで行われます。
それで、多くのスリープスレッドを持つことに重大なパフォーマンスの影響はありますか？
ほとんどの場合、スリープ状態のスレッドによって消費されるリソースは、そのスタック スペースになります。あなたが説明しているものと似ていると思う接続ごとに2スレッドのモデルを使用すると、接続数が大きくなると、まさにこの理由で大きなスケーラビリティの問題が発生することが知られています。
私自身もこの状況に陥りましたが、接続数が 500 接続 (約 1000 スレッド) を超えると、スレッドのスタック スペースの使用量が単一プロセスのメモリ。少なくとも私たちの場合、これは 32 ビット Windows の世界の Java でした。調整してもう少し先に進むことはできると思いますが、最終的には、多くのメモリを浪費するため、あまりスケーラブルではありません。
多数の接続が必要な場合は、Java NIO (新しい IO など) を使用すると、同じスレッドで多数の接続を処理できるようになります。
そうは言っても、おそらくリソースの浪費であるとしても、かなり最新のサーバーで 100 スレッド未満で多くの問題に遭遇することはありません。
NIOに切り替える前は、まったく同じ問題が発生していたので、Liedmansの2番目の推奨事項としてそのフレームワークを使用します。チュートリアルを見つけることができるはずですが、詳細が必要な場合は、RonHitchensによるJavaNIOをお勧めします。
NIOに切り替えると、処理できる接続数が大幅に増加しました。これは、私たちにとって非常に重要でした。
多くのスレッドは多くのスタックスペースに相当し、メモリを消費します。-Xss設定を確認してから、計算を行ってください。
また、何らかの理由でnotifyAll（）を実行する必要がある場合は、もちろん、提案されたアーキテクチャでは実行する必要がない場合でも、余分なスレッドの負荷を目覚めさせます。
このモデルでは、リスニングソケットごとに1つのスレッドを簡単に回避できるかどうかはわかりませんが（NIOについてはほとんど知らないので、その問題も修正される可能性があります）、java.util.concurrent.Executorインターフェイスとあまりにも多くの追加スレッドがぶら下がるのを避けるための適切な方法のための実装クラス。確かに、ThreadPoolExecutorこれはリスニングスレッドを管理するための良い方法かもしれないので、不必要にスレッドを作成および破棄することに多くの時間を費やすことはありません。
これはあまりうまくスケーリングしません。スレッドの数が多いということは、VM がコンテキストの切り替えにより多くの時間を費やす必要があることを意味し、各スレッドが独自のスタック スペースを必要とするため、メモリの使用量が高くなります。パイプライン方式で処理するスレッドの数を少なくするか、非同期技術でスレッド プールを使用する方がよいでしょう。
C、Lua、および Python で行ったテストから、ごくわずかなコード行で独自のスリープまたは待機関数を作成して、単純で軽量なループを作成できます。到達したい将来の時間でローカル変数を使用し、while ループで現在のタイムスタンプをテストします。fps を使用するスコープにいる場合は、待機関数をフレームごとに 1 回実行して、リソースを節約します。タイムスタンプは秒単位に制限されているため、必要な精度が高いほど、タイムスタンプの代わりに時計を使用することを検討してください。待機関数に追加するコード行が増えるほど、精度が低下し、より多くのリソースを消費しますが、10 行未満であれば十分に高速なはずです。