我的网络服务器使用通常的 Java I/O 和每个连接机制的线程。如今，随着用户的增加（长轮询连接），他们开始屈服。但是，连接大多是空闲的。虽然这可以通过添加更多网络服务器来解决，但我一直在尝试对 NIO 实现进行一些研究。
我对它的印象好坏参半。我已经阅读了有关基准测试，其中使用 Linux 中新的 NPTL 库的常规 I/O 优于 NIO。
配置和使用最新的 NPTL for Linux with Java I/O 的真实体验是什么？有没有提高性能？
关于更大范围的问题：
我们期望的标准服务器类机器（戴尔四核处理器）中的最大 I/O 和阻塞线程数（我们在 Tomcat 线程池中配置）是多少正常执行（使用 Linux NPTL 库？）。如果线程池变得非常大，比如超过 1000 个线程，会有什么影响？
非常感谢任何参考和指针。
【问题讨论】：
标签： java linux multithreading nio nptl
您可能会发现有用的链接：
您还可以查看http://nodejs.org/，它不是 JVM 技术，但可以完美处理数千个连接（如果我没记错的话，它在幕后使用 NPTL）
JVM 下一些经过验证的良好 NIO Web 框架：
【讨论】：
发帖，"Avoid NIO, get better throughput."Paul Tyma's(2008) blog 声称有大约 5000 个线程没有任何麻烦；我听说人们声称更多：
- 启用 NPTL 后，Sun 和 Blackwidow JVM 1.4.2 轻松扩展到 5000+ 线程。阻塞模型是 始终比使用快 25-35% NIO 选择器。很多技巧 EmberIO 的建议是 雇用 - 使用多个选择器， 如果第一次读取，则进行多次 (2) 读取 读取返回的 EAGAIN 等效项 爪哇。然而我们无法击败平原 Linux 下每个连接模型的线程数 NPTL。
我认为这里的关键是measure the overhead and performance，只有当你知道你需要并且可以证明改进时才转向非阻塞 I/O。编写和维护非阻塞代码的额外努力应该考虑到您的决定中。我的看法是，如果您的应用程序可以使用同步/阻塞 I/O 清晰地表达，那么就这样做。如果您的应用程序适合非阻塞 I/O，并且您不会只是在应用程序空间中严重地重新发明阻塞 I/O，那么根据测量的性能需求考虑迁移到 nio。 当我浏览 google 的结果时，我很惊讶，实际上很少有资源引用任何（最近的）数字！
另外，请参阅Paul Tyma's presentation slides：旧方法又是新方法。根据他在 Google 的工作，具体数据表明同步线程 I/O 在 Linux 上具有相当大的可扩展性，并且认为“NIO 更快”是一个神话，这在一段时间内是正确的，但不再是。一些很好的附加评论here on Comet Daily。他在 NPTL 上引用了以下结果（轶事，仍然没有与基准测试的可靠链接等）：
在测试中，NPTL 成功启动 IA-32 上的 100,000 个线程分为两个 秒。相比之下，本次测试 在没有 NPTL 的内核下会有 大约需要 15 分钟
如果您确实遇到了可伸缩性问题，您可能希望使用XX:ThreadStackSize tune the thread stack size。既然你提到了Tomcat see here。
最后，如果您已被约束并决心使用非阻塞 I/O，请尽一切努力在 existing framework by people who know what they're doing 的基础上进行构建。我已经浪费了太多自己的时间试图正确地获得一个错综复杂的非阻塞 I/O 解决方案（出于错误的原因）。
【讨论】：
Sajid，我看到你在做 Comet（长轮询）。
几乎没有人谈论在 NIO 中执行 Comet 事件的用户代码的问题。调度 Comet 事件的 NIO 线程调用您的代码，如果您的代码不够好，您将阻塞这个关键线程，其他 Comet 连接必须等待，因为 NIO 线程正在执行与 SO 的线程调度程序类似的工作。这不是Comet 中的 IO 问题，因为该线程仅适用于您的 Comet 事件/任务，并且调度程序可以在需要时放弃您的线程（使用 NIO 方法并不容易）。
我看到的“同步 Comet”（基于 IO）的唯一问题是线程堆栈的内存消耗。
【讨论】：