我的Web服务器使用通常的Java I / O和每个连接机制的线程。如今，随着用户的增加（长轮询连接），他们正跪在地上。但是，连接大多处于空闲状态。虽然这可以通过添加更多Web服务器来解决，但我一直在尝试对NIO实现进行一些研究。
我对此有一种好坏参半的印象。我读过一些关于基准测试，其中Linux中新的NPTL库的常规I / O优于NIO。
通过 Java I/O 配置和使用最新的 NPTL for Linux 的实际体验是什么？性能是否有所提高？
关于一个范围更大的问题：
在标准服务器级计算机（具有四核处理器的戴尔）中，我们期望正常执行（使用Linux NPTL库？）中I / O和阻塞线程（我们在Tomcat线程池中配置）的最大数量是多少？如果线程池变得非常大，比如说超过1000个线程，会有什么影响？
任何参考和指针将不胜感激。
挑衅性的博客文章，“避免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 干净利落地表达出来，那就去做吧。如果您的应用程序适合非阻塞 I/O，并且您不会在应用程序空间中严重重发明阻塞 I/O，请考虑根据测量的性能需求迁移到 nio。当我浏览谷歌结果时，我感到惊讶的是，很少有资源真正引用任何（最近的）数字！
另外，请参阅Paul Tyma的演示幻灯片：旧的方式又是新的。根据他在谷歌的工作，具体数字表明同步线程I / O在Linux上具有相当的可扩展性，并认为“NIO更快”是一个神话，曾经存在过一段时间，但现在已经不再存在。彗星日报上有一些很好的附加评论。他在NPTL上引用了以下结果（轶事，仍然没有与基准等的可靠联系等）：
在测试中，NPTL在两秒钟内成功地在IA-32上启动了100，000个线程。相比之下，在没有NPTL的内核下进行测试大约需要15分钟。
如果您确实遇到可伸缩性问题，则可能需要使用 XX：ThreadStackSize 调整线程堆栈大小。既然你提到雄猫，请看这里。
最后，如果您被束缚并决心使用非阻塞 I/O，请尽一切努力在知道自己在做什么的人的现有框架上进行构建。我浪费了太多的时间试图获得一个错综复杂的非阻塞I / O解决方案（出于错误的原因）。
另请参阅 SO 的相关内容。
您可能会发现有用的链接：
您还可以查看 http://nodejs.org/ 它不是JVM技术，但可以完美地处理数千个连接（如果我没有记错的话，在幕后使用NPTL）
JVM下一些经过验证的NIO Web框架：
