挑衅性的博客文章 “避免NIO，获得更好的吞吐量”。保罗·泰玛）2008）的博客声称〜5000个线程没有任何麻烦；我听说人们要求更多：
- 启用NPTL后，Sun和Blackwidow JVM
1.4.2可以轻松扩展到5000+线程。阻塞模型始终比使用NIO选择器快25-35％。采用了EmberIO人士建议的许多技术-
使用多个选择器，如果第一次读取返回Java中等效的EAGAIN，则执行多个（2）读取。但是，我们无法使用Linux NPTL击败每个连接模型的普通线程。
我认为这里的关键是 衡量开销和性能 ，并仅在您知道需要并且可以证明有改善时才转向非阻塞I /
O。编写和维护非阻塞代码的额外工作应纳入您的决定。我的看法是， 如果可以使用同步/阻塞I / O清晰地表达您的应用程序 ， 请执行该操作
。如果您的应用程序适合非阻塞I / O，而您不会只是在应用程序空间中严重地重新发明了阻塞I / O，请根据测得的性能需求 考虑使用nio 。
当我在google结果中四处搜寻时，我感到非常惊讶，实际上很少有资源引用任何（最新）数字 ！
另外，请参阅PaulTyma的演示幻灯片：旧方法又是新方法。根据他在Google的工作，具体数字表明，同步线程I/ O在Linux上具有相当的可扩展性，并且认为“
NIO更快”是一个神话，这种说法已经存在了一段时间了，但是不再是。在“彗星日报”上还有一些不错的评论。他引用了NPTL上的以下结果（传闻，仍然没有到基准的牢固链接，等等…）：
在测试中，NPTL在两秒钟内成功启动了IA-32上的100,000个线程。相比之下，在没有NPTL的内核下进行的测试大约需要15分钟
如果你真的遇到了可扩展性问题，可能需要调整线程堆栈大小使用
XX:ThreadStackSize。由于您提到Tomcat，请参见此处。
最后，如果您被束缚并决心使用非阻塞I /
O，则由知道自己在做什么的人尽一切努力在现有框架上进行构建。我浪费了太多时间来尝试获得正确的非阻塞I
/ O解决方案（由于错误的原因）。
