比較的シンプルな Java TCP/IP サーバーを作成する必要がありますが、Netty のようなものを使用するべきか、それともシンプルな ServerSocket と InputStream/OutputStream に固執するべきか判断するのに少し苦労しています。
実際に必要なのは、リクエストをリッスンし、新しいクライアント ソケットを新しいスレッド内の処理コードに渡すことだけです。処理が完了して応答が送信されると、そのスレッドは終了します。
Netty のパイプラインやデコーダーなどのアイデアは気に入っていますが、このような単純なシナリオでは、追加の先行開発時間をかける価値はないようです。当初の要件に対しては少しやり過ぎのように思えますが、考慮していないことがたくさんあるのではないかと少し不安です。このような単純な要件に対して Netty の利点があるとすれば、それは何でしょうか。何を考慮していないのでしょうか。
ベストアンサー1
Nettyがストリームを使ってソケットから読み書きするだけよりも優れている点は、Nettyがサポートしている点です。非ブロッキング、非同期I/O(Java の NIO API を使用)。ストリームを使用してソケットから読み書きする場合 (および、 から受け入れられた接続ごとに新しいスレッドを開始する場合ServerSocket)、ブロッキングされた同期 I/O を使用しています。
Netty のアプローチはスケーラビリティがはるかに優れているため、システムで同時に多数 (数千) の接続を処理できる必要がある場合に重要です。システムで多数の同時接続に対応する必要がない場合は、Netty のようなフレームワークを使用する手間はかからないかもしれません。
背景情報をもう少し説明します。スレッドは、オペレーティング システムでは比較的高価なリソースです。各スレッドにはスタック用のメモリが必要です (サイズは、たとえば 2 MB です)。何千ものスレッドを作成すると、大量のメモリが必要になります。また、オペレーティング システムには作成できるスレッドの数に制限があります。したがって、受け入れられる接続ごとに新しいスレッドを開始するのは望ましくありません。非同期 I/O の考え方は、スレッドを接続から切り離すことです (1 対 1 の関係ではありません)。スレッドよりも多くの接続が存在する可能性があり、接続の 1 つで何らかのイベントが発生すると (たとえば、データの受信)、スレッド プールのスレッドが一時的に使用され、イベントが処理されます。