独立して読み書きする予定のJavaのブロッキングソケットを利用していますが、2つのオプションは、操作ごとに個別のスレッドを割り当てたり、setSoTimeout()を使用してタイムアウトをポーリングすることです。ブロッキングソケットの使用を検討する際には、どのようなオプションがありますか？
2つの実装の間で選択することは、メモリー（スレッド）とCPU時間（ポーリング）とのトレードオフのようです。
スケジューラやコンテキスト切り替えに関連するスケーラビリティーの問題は、ポーリングに費やされたCPU時間を上回る可能性がある多数のスレッドのほか、パケットのサイズに応じて単一のスレッドから読み書きするときに発生する遅延受け取った。あるいは、適切に調整されていれば、いくつかのソケットのポーリングと組み合わせて、小さなスレッドのプールをスケールに使用できます。
この問題の対象外となるJavaのNIOを除いて、ブロッキングソケットを使用するためのオプションを正しく理解していますか？
まず、スケールする唯一のオプションを除外したと思います。すなわちNIOを使用する。
ソケット単位のスレッドもポーリングもスケーリングされません。
スレッドケースでは、ソケットあたり2つのスレッドが必要です。 （スレッドプールは機能しません）。これは、スレッドスタックとスレッドオブジェクトのためのスペース、ネイティブスレッド記述子のためのカーネルリソースを消費します。その後、コンテキスト切り替え、余分なGCトレースなどの副次的な影響があります。
ポーリングの場合、ソケットごとに通常のシステムコールを作成する必要があります。 1つのスレッドでも小さなスレッドでも、システムコールの数は同じです。より頻繁にポーリングすると、システム全体の速度が向上します。ポーリング頻度が低い場合は、システムのレスポンスが低下します。
AFAIKには、設定した制限がありますが、その他のオプションはありません。
ここで、スレッドとポーリングのどちらが良いかを判断しようとしている場合、答えは「依存します」です。多くの変数があります：
これらはすべて、数学的に解析するのが難しく、経験的に（正確に）シミュレートするのが難しく、経験的に測定するのが難しい複雑なシナリオになります。
問題は、スケールされるものではなく、ノンブロッキングI/Oが利用できない場合に使用できるオプションです。私は、最初に作業し、非ブロッキングの代替案を見る前に提供されている制限を明確に理解することによって、ソケットプログラミングをゆっくりと試しています。だから私はこの質問からNIOを除外しているのですが、私は現時点でそれを研究していません。 – Zhro
私はそれに答えました。あなたが好きな方は、** bold **の特定の文章を強調表示して、簡単に見つけることができます。 （そして、私はそれぞれの制限についても説明しました...） –
タイムアウト付きでの読み取りは、1つではなく読み取りよりも高価ではありません。どちらの場合でも、スレッドは、OSにデータがある場合にそれを目覚めさせるように指示した後、スリープ状態になります。タイムアウトがある場合は、指定された遅延の後にOSに復帰するように指示します。待っているCPUサイクルは無駄です。
もう1つは、数千マイクロ秒のオーダーのコンテキスト切り替えオーバヘッドです。ネットワーク通信の遅延は> 1msです。このオーバーヘッドがサーバーを無意味にするまでは、おそらく数千もの同時接続に対応できます。
しかし、タイムアウトがゼロでポーリングした場合、OSは別のスレッドをスケジュールする必要はありません。スケジューリングのCPUサイクルを節約します。しかし、あなたは定期的にポーリングしているため、より多くのサイクルを使用し、ほとんどの場合、読まれた投票は何も返しません。結論：分析は本当に複雑で、多くの変数があります。 –
少なくともJavaソケットと 'setSoTimeout（）'では、タイムアウト0は無限タイムアウトとして解釈されます。私はあなたが何を意味するかは、利用可能な最短のタイムアウトであると確信しています。 – Zhro
同時接続数はいくつですか？ – meriton