我的网络服务器使用通常的 Java I/O 和每个连接机制的线程。如今，随着用户的增加（长轮询连接），他们开始屈服。但是，连接大多是空闲的。虽然这可以通过添加更多网络服务器来解决，但我一直在尝试对NIO实现进行一些研究。
我对它的印象好坏参半。我已经阅读了有关基准测试，其中使用 Linux 中的新NPTL库的常规 I/O优于 NIO。
配置和使用最新的 NPTL for Linux with Java I/O 的真实体验是什么？有没有提高性能？
在更大范围的问题上：
在我们期望正常执行的标准服务器类机器（具有四核处理器的戴尔）中（使用 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 的演示幻灯片：旧方法又是新方法。根据他在 Google 的工作，具体数据表明同步线程 I/O 在 Linux 上具有相当大的可扩展性，并且认为“NIO 更快”是一个神话，这在一段时间内是正确的，但不再是。彗星日报上有一些很好的补充评论。他在 NPTL 上引用了以下结果（轶事，仍然没有与基准的可靠链接等）：
在测试中，NPTL 在两秒钟内成功地在 IA-32 上启动了 100,000 个线程。相比之下，在没有 NPTL 的内核下进行此测试大约需要 15 分钟
如果您确实遇到了可伸缩性问题，您可能需要使用XX:ThreadStackSize. 由于您提到Tomcat，请参见此处。
最后，如果您有决心使用非阻塞 I/O，请尽一切努力在知道自己在做什么的人的现有框架上进行构建。我已经浪费了太多自己的时间试图正确地获得一个错综复杂的非阻塞 I/O 解决方案（出于错误的原因）。
另见SO 相关。
您可能会发现有用的链接：
您还可以查看http://nodejs.org/，它不是 JVM 技术，但可以完美处理数千个连接（如果我没记错的话，在幕后使用 NPTL）
JVM 下一些经过验证的良好 NIO Web 框架：
Sajid，我看到你在做 Comet（长轮询）。
几乎没有人谈论在 NIO 中执行 Comet 事件的用户代码的问题。调度 Comet 事件的 NIO 线程调用您的代码，如果您的代码不够好，您将阻塞这个关键线程，并且其他 Comet 连接必须等待，因为 NIO 线程正在执行与 SO 的线程调度程序类似的工作。这在 Comet with IO 中不是问题，因为线程仅用于您的 Comet 事件/任务，并且调度程序可以在需要时放弃您的线程（使用 NIO 方法并不容易）。
我看到的“同步 Comet”（基于 IO）的唯一问题是线程堆栈的内存消耗。