挑発的なブログ投稿、「NIO を回避し、スループットを向上させます。」 Paul Tyma (2008) のブログでは、問題なく 5000 スレッドまであると主張しています。私は人々がもっと主張するのを聞いた：
- NPTL をオンにすると、Sun と Blackwidow の JVM 1.4.2 は 5000 以上のスレッドに簡単に拡張できます。ブロッキング モデルは、NIO セレクターを使用するよりも一貫して 25 ～ 35% 高速でした。EmberIO 関係者によって提案された多くの手法が採用されました。複数のセレクターを使用し、最初の読み取りが Java で同等の EAGAIN を返した場合に複数 (2) の読み取りを行います。それでも、Linux NPTL を使用した接続モデルごとのプレーン スレッドを打ち負かすことはできませんでした。
ここで重要なのは、オーバーヘッドとパフォーマンスを測定し、必要性があり、改善を示すことができる場合にのみ、ノンブロッキング I/O に移行することだと思います。ノンブロッキング コードを作成して維持するための追加の作業は、決定の際に考慮する必要があります。私の見解は、同期/ブロッキング I/O を使用してアプリケーションをきれいに表現できる場合は、 DO THATです。アプリケーションがノンブロッキング I/O に適していて、アプリケーション空間でブロッキング I/O をひどく再発明するだけではない場合は、測定されたパフォーマンスのニーズに基づいて nio に移行することを検討してください。これについてGoogleの結果を調べてみると、実際に（最近の）数字を引用しているリソースはほとんどないことに驚いています。
また、Paul Tyma のプレゼンテーション スライドも参照してください。古い方法が再び新しくなりました。Google での彼の研究に基づいて、具体的な数字は同期スレッド I/O が Linux で非常にスケーラブルであることを示唆しており、「NIO の方が速い」という神話はしばらくの間真実でしたが、もはやそうではないと考えています。コメット デイリーにいくつかの良い追加解説があります。彼は、NPTL に関する次の結果を引用しています (事例、ベンチマークへの確実なリンクなどはまだありません...)。
テストでは、NPTL は IA-32 で 2 秒で 100,000 スレッドを開始することに成功しました。比較すると、NPTL を使用しないカーネルでのこのテストには、約 15 分かかります。
スケーラビリティの問題が実際に発生している場合は、 を使用してスレッド スタック サイズを調整するXX:ThreadStackSizeことをお勧めします。あなたがTomcatに言及しているので、ここを参照してください。
最後に、どうしてもノンブロッキング I/O を使用することに決めた場合は、自分が何をしているかを知っている人が既存のフレームワークを基に構築するようあらゆる努力をしてください。私は複雑なノンブロッキング I/O ソリューションを正しく作ろうとして (間違った理由で) あまりにも多くの時間を無駄にしてきました。
関連する SOも参照してください。