私はbittorrentクライアントに取り組んでいます。ピアと通信している間、私が彼らと通信する最も簡単な方法は、ピアごとに新しいスレッドを生成することです。しかし、ユーザーが多数のピアとの接続を維持したい場合は、多くのスレッドを生成する必要があります。
私が考えた別の解決策は、1 つのスレッドを使用してピア オブジェクトを反復処理し、それらを一定期間実行することです。
私は主にルビーで他のライブラリをチェックしました（私のものは Java です）、それらは新しいピアごとに1つのスレッドを生成します。ユーザーが接続数を 100 や 200 などの高い数に設定した場合、1 つのスレッドを生成するとパフォーマンスが低下すると思いますか?
プールされたスレッドの数を維持するために Executor を使用することをお勧めします。
Executors.newFixedThreadPool(numberOfThreads);
これにより、基本的に「タスク」をプールに追加でき、スレッドが使用可能になるとすぐに完了します。こうすることで、エンドユーザーのコンピューターのスレッドをすべて使い果たしてしまうことなく、同時に多くの処理を行うことができます。16 のように設定すると、かなり安全になりますが、ユーザーが必要に応じてこの番号をいつでも変更できるようにすることができます。
何千ものスレッドを実行していない限り、問題にはなりません。スレッドプールを使用して、妥協点を検討します。実行時に CPU の数を検出し、それに基づいてスピンアップするスレッドの数を決定し、スレッドプールに作業を渡すことができます。
Non-blocking IO (java.nio.*)を使用すると、この問題を完全に回避できます。
いいえ.....
これとまったく同じ疑問を抱いて、400スレッドの.netアプリ（4年前）を作成したことがあります....
彼らが多くの仕事をしなければ、まともなマシンがあれば大丈夫です...
数百のスレッドは、ほとんどのワークステーション クラスのマシンでは問題にならず、コーディングも簡単です。
ただし、アイデアを追求することに興味がある場合は、Java の NIO パッケージが提供するノンブロッキング IO 機能を使用できます。Jean-Francois Arcand のブログには、Glassfish 用の Grizzly コネクタの作成から学んだ多くのヒントが含まれています。
スレッド プールを使用すると、かなり大きなプール サイズ (100 程度) で安全になるはずです。このタイプのアプリケーションでは IO バウンドであるため、CPU は問題になりません。
すべてのスレッドでメモリ関連の問題を防ぐためだけに、プールのサイズを簡単に構成可能にして妥当な最大値を設定できます。もちろん、これはすべてのスレッドが実際に使用されている場合にのみ発生します。
たとえば 32 ビット Windows では、実際には、作成できるネイティブ スレッドの最大数 (2 ギグ / (スレッド数 * ThreadStackSize (デフォルトは 2MB)) など) があります。したがって、接続が多すぎると、仮想メモリのアドレス空間が不足する可能性があります。妥協案が機能する可能性があると思います。たとえば、10個のスレッド（マシンによって異なります）が実行されているスレッドプールを使用し、接続を均等に分散します。スレッド内では、このスレッドに割り当てられたピアをループします。また、接続の最大数を制限します。