我一直在寻找有关 Java 中异步 I/O 优势的详细信息，尤其是从应用程序堆栈设计中。
我遇到了许多事件驱动服务器的例子，比如 Node.js、Tornedo 等。
我不明白的是，为什么有人在 Java EE 中使用 JBoss 或 Weblogic 应用服务器拥有整个应用程序堆栈，但会迁移到事件驱动架构。
甚至这些服务器也支持非阻塞 I/O。是的，他们为每个请求分配了一个线程，但是有了一个线程池，资源不是很好地处于良好的性能参数范围内吗？
请按照以下几行向我提供一些输入。
您提到的关键概念之一是：
是的，他们为每个请求分配一个线程
一次又一次地表明，当您的目标是支持大量并发用户时，IO 绑定应用程序的每个请求都有一个线程最终会耗尽您的线程池。事实证明，您所谈论的框架（如 Node.js、Tornado 等）在处理大量并发用户方面表现出色，您的应用程序很可能只是在等待某些事情发生并且不占用任何 CPU完全绑定任务。换句话说，这些工具非常适合构建实时应用程序，如在线游戏、聊天室、日志系统、通知系统，其主要目标是尽可能快地与许多用户快速协调小消息传递。
事实上，这些工具非常适合编写基于 websocket 的应用程序，因为它实际上是为用户提供实时或接近实时的体验。
虽然许多公司确实从一开始就使用这些平台，但我认为对于拥有传统堆栈的公司来说，使用事件驱动工具作为其系统的补充更为常见。当你使用 node.js 或 Tornado 之类的东西时，你可能会发现自己放弃了很多依赖的内置软件，而不得不推出自己的 api 和驱动程序。node.js 已经存在了一段时间，实际上有很多很好的支持连接到数据库、nosql 平台和构建系统，但它需要一段时间才能到达那里。
作为一个实验，尝试编写一个简单的 tcp 聊天应用程序，每个请求使用一个线程，看看你可以支持多少用户。最终，您将遇到可以启动多少操作系统线程的限制，这确实很昂贵。
然后看看只使用一个线程，它的默认线程，你可以使用 node.js 多远。你会发现每秒能够支持极大数量的并发请求。众所周知，它可以扩展到数百万，因为它不受线程的限制，它仅受内存、文件描述符数量和 CPU 的限制。
尽我所能回答您的问题：
我认为它更多地是关于底层实现，以及它产生的间接费用的讨价还价：
旋转一个全新的专用线程来处理请求。每个线程都会阻塞 I/O。但是，在线程级别管理这种并发性是一团糟。
相对
使用一个线程，它保持响应并承诺在未来某个时间处理这些东西。在执行 I/O 时不会阻塞，线程级别不需要并发管理。让操作系统来处理。
为什么使用 Apache-Tomcat/JBoss/Weblogic 的传统 Java EE 架构考虑转向事件驱动架构。
也许他们厌倦了过于通用、重量级的解决方案，并想看看新的轻量级替代方案。这些替代方案的开发和部署非常简单，并且可以很好地扩展。
事件驱动架构是否有助于提供与设备无关的网站/应用程序。
我不认为这些有太大关系。不止一种语言可以在同一个 JVM 上运行。这是 JVM 在多个主机上运行的能力，并公开了一个标准 api，它带来了与设备无关的能力。另一个例子是网络浏览器。
在云上设计应用程序时，我们会选择异步 I/O。
更多地取决于要求。异步 I/O 并不能解决所有问题。但如果您想要轻松创建、快速扩展的解决方案，它可能会有所帮助。对于限制严格的新创业公司来说，这是一个不错的选择。
事件驱动的架构性能是优于传统的 Java EE 架构还是神话。
使用一些良好的基准测试更好地测试性能，调整到您的业务需求。
性能将主要取决于应用程序。正如您所说，有很多请求，需要运行多个线程，这会消耗主内存，因为线程需要在服务其他请求之前先处理请求。我不愿意说就是这样，但它是一个开始:-)