最近、サーバーを作成するために Java ソケットと NIO をいじっていました。なぜ Java NIO が標準ソケットよりも優れているのかは、まだよくわかりません。これらのテクノロジーのいずれかを使用してサーバーを作成する場合、ほとんどの場合、接続を受け入れてさらにそれらを作業スレッドに渡すディスパッチャー スレッドを持つことになります。
スレッドモデルでは接続ごとに専用のスレッドが必要ですが、固定サイズのスレッドプールを作成し、それらを再利用してさまざまな接続を処理できることを読みました (スレッドの作成と破棄のコストが削減されるように) .
しかし、Java NIO の場合は似ています。リクエストを受け入れる 1 つのスレッドと、受信時にデータを処理するいくつかのワーカー スレッドがあります。
私が見つけた Java NIO の方が優れている例は、チャット クライアントや http サーバーのように、多くの非ビジー接続を維持するサーバーです。しかし、その理由がまったく理解できません。
NIO は Dispatcher モデルをサポートしていますが、NIO ソケットはデフォルトでブロックされており、それらをそのまま使用すると、小さい (< 100) 接続ではプレーン IO または非ブロック NIO よりも高速になる可能性があります。また、ブロッキング NIO は、ノンブロッキング NIO よりも操作が簡単だと思います。
ビジーウェイトを使いたい時はノンブロッキングNIOを使っています。これにより、CPU を決して放棄しないスレッドを持つことができますが、これはまれなケース、つまりレイテンシが重大な場合にのみ役立ちます。
私のベンチマークから、真の強み (スレッド モデル以外) は、メモリ帯域幅 (カーネル<=>Java) の消費が少ないことです。たとえば、いくつかの UDP NIO マルチキャスト チャネルを開き、トラフィックが多い場合、新しいプロセスごとに特定の数のプロセスで、実行中のすべての UDP レシーバーのスループットが低下することに気付くでしょう。従来のソケット API を使用して、フル スループットで 3 つの受信プロセスを開始します。4番目を開始すると、制限に達し、実行中のすべてのプロセスで1秒あたりの受信データが低下します。nio を使用すると、この効果が発生するまでに約 6 つのプロセスを開始できます。
これは主に、NIO がネイティブまたはカーネル メモリに直接ブリッジしているのに対し、古いソケットはバッファを VM プロセス空間にコピーしているためだと思います。
GRID コンピューティングおよび高負荷サーバー アプリ (10GBit ネットワークまたはインフィニバンド) で重要です。