我的Web服务器使用通常的Java I/O和每个连接机制的线程。如今，随着用户的增加（长时间的轮询连接），他们开始屈服。但是，连接大部分处于空闲状态。尽管可以通过添加更多的Web服务器来解决此问题，但我一直在尝试对NIO实现进行一些研究。
我对此有好感。我已经阅读了基准测试，其中使用Linux中新的NPTL库的常规I / O 优于NIO。
通过Java I / O配置和使用最新的NPTL for Linux的真实生活体验是什么？有提高的表现吗？
在更大范围的问题上：
在我们期望正常运行（使用LinuxNPTL库）的标准服务器类计算机（具有四核处理器的Dell）中，最大I/O和阻塞线程（我们在Tomcat线程池中配置）的最大数量是多少？如果线程池真的很大，比如说有1000多个线程，会产生什么影响？
任何引用和指针将不胜感激。
挑衅性的博客文章 “避免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，请参见此处。
XX:ThreadStackSize
最后，如果您被束缚并决心使用非阻塞I / O，则由知道自己在做什么的人尽一切努力在现有框架上进行构建。我浪费了太多时间来尝试获得正确的非阻塞I / O解决方案（由于错误的原因）。
