我的Web服务器使用常规的Java I/O和每个连接一个线程的机制。现在，由于用户增加（长轮询），它们正处于困境中。但是，这些连接大多数情况下是空闲的。尽管可以通过添加更多Web服务器来解决此问题，但我一直在研究NIO实现。
我对此有着复杂的印象。我已经阅读了一些基准测试报告，在这些报告中，带有新NPTL库的常规I/O要优于NIO。
配置和使用最新的Linux NPTL与Java I/O的真实体验如何？是否有性能提升？
并且就更广泛的问题而言：
在标准服务器类机器（Dell四核心处理器）上，我们期望在（使用Linux NPTL库？）正常情况下执行的I/O和阻塞线程的最大数量是多少（我们在Tomcat线程池中进行配置）？如果线程池变得非常大，比如超过1000个线程，会有什么影响？
非常感谢提供任何参考和指针。
挑衅性的博客文章，"避免使用NIO，获得更好的吞吐量。" Paul Tyma在(2008)博客中声称可以轻松处理5000个线程而没有任何问题；我听说有人声称可以处理更多：
我认为关键在于测量开销和性能，只有当您知道需要并且可以证明改进时，才转向非阻塞I/O。编写和维护非阻塞代码所需的额外工作应纳入您的决策考虑范围内。我的看法是，如果您的应用程序可以使用同步/阻塞I/O清晰地表达，请这样做。如果您的应用程序适合使用非阻塞I/O，并且不会在应用空间中重新发明阻塞I/O，则考虑根据测量的性能需求移动到nio。我惊讶地发现，在Google搜索结果中，很少有资源引用任何（最近的）数字！
- 启用NPTL后，Sun和Blackwidow JVM 1.4.2很容易扩展到5000+个线程。阻塞模型始终比使用NIO选择器快25-35％。采用了EmberIO团队建议的许多技术——使用多个选择器，在第一个读取返回Java中的EAGAIN等效时进行多个（2个）读取。但是我们无法击败使用Linux NPTL的普通每个连接模型。
此外，请参见Paul Tyma的演示幻灯片：旧方法再次流行。基于他在Google的工作，具体数字表明，在Linux上，同步线程I/O非常可扩展，并且认为“NIO更快”是一个曾经正确但现在不再正确的神话。有一些关于Comet Daily的良好附加评论here on Comet Daily。他引用了以下（轶事性的，仍然没有实际基准测试链接等...）NPTL结果：
在测试中，NPTL成功地在两秒钟内启动了100,000个线程，在IA-32上进行。相比之下，在没有NPTL的内核下，这个测试需要大约15分钟。
XX:ThreadStackSize来调整线程堆栈大小。因为您提到了Tomcat，请看这里。以下是您可能会发现有用的链接：
您还可以查看http://nodejs.org/，它不是JVM技术，但完美地处理了数千个连接（如果我没有弄错的话，它在幕后使用了NPTL）
JVM下一些经过验证的NIO Web框架：
Sajid，我看到你正在进行Comet（长轮询）。
几乎没有人谈论在NIO中执行Comet事件的用户代码的问题。调度Comet事件的NIO线程调用您的代码，如果您的代码不够好，您将阻塞此关键线程，其他Comet连接必须等待，因为NIO线程正在执行类似于S.O.的线程调度程序的工作。这不是使用IO的Comet中的问题，因为线程仅用于您的Comet事件/任务，调度程序可以在想要时放弃您的线程（使用NIO方法不是那么容易）。
“同步Comet”（基于IO）唯一的问题是线程堆栈的内存消耗。