异步I/O-Java

我一直在寻找Java中异步I/O优势的详细信息，特别是从应用程序堆栈设计方面

我遇到了许多事件驱动服务器的例子，如Node.js、Tornedo等

我未能理解的是，为什么在JavaEE中使用JBoss或Weblogic应用程序服务器的整个应用程序堆栈会迁移到事件驱动的体系结构

即使这些服务器也支持非阻塞I/O。是的，它们为每个请求分配了一个线程，但是如果有一个线程池，那么这些资源不是在良好的性能参数范围内吗

请按照以下内容向我提供一些信息

为什么使用ApacheTomcat/JBoss/Weblogic的传统JavaEE体系结构会考虑迁移到事件驱动体系结构

事件驱动架构是否有助于提供设备无关的网站/应用程序

在云上设计应用程序时，我们会选择异步I/O吗

事件驱动的体系结构的性能是否比传统的JavaEE体系结构好，还是一个神话

---

性能将主要取决于应用程序。正如您所说，对于很多请求，需要运行多个线程，线程需要消耗多少主内存

---

先服务请求，再服务其他请求。我不愿意这么说，但这是一个开始：-）

您提到的一个关键概念是：

是的，他们正在为每个请求分配一个线程

一次又一次地表明，当您的目标是支持大量并发用户时，使用IO绑定的应用程序对每个请求拥有一个线程最终会耗尽您的线程池。事实证明，您正在谈论的Node.js、Tornado等框架擅长处理大量并发用户，而您的应用程序很可能只是等待某些事情发生，根本不执行任何CPU限制的任务。换句话说，这些工具非常适合构建实时应用程序，如在线游戏、聊天室、日志记录系统和通知系统，其主要目标是尽可能快地与许多用户协调小消息传递

事实上，这些工具非常适合编写基于websocket的应用程序，因为它实际上是为用户提供实时或接近实时的体验

虽然许多公司从一开始就在利用这些平台，但我认为对于拥有传统堆栈的公司来说，使用事件驱动工具作为其系统的补充更为常见。当您使用node.js或Tornado之类的工具时，您可能会发现自己放弃了许多依赖的内置软件，而不得不使用自己的api和驱动程序。现在node.js已经存在了一段时间，实际上有很多很好的支持连接到数据库、nosql平台和构建系统，但它需要一段时间才能实现

作为一个实验，尝试编写一个简单的tcp聊天应用程序，每个请求使用一个线程，看看您可以支持多少用户。最终，您将达到一个极限，即您可以启动多少操作系统线程，这确实非常昂贵

然后看看使用node.js仅使用一个线程（默认线程）就可以走多远。您将发现，您能够支持每秒极大量的并发请求。众所周知，它可以扩展到数百万，因为它不受线程的限制，它只受内存、文件描述符的数量和cpu的限制

为了尽我所能回答您的问题：

我不认为仅仅因为你听说node.js和事件驱动架构是多么优秀就抛弃整个平台是可行的。如果您需要构建一个IO绑定的高并发应用程序，您真的需要问问自己。如果是这样，为什么不直接使用它来补充现有的堆栈呢

我不确定你的第二个问题，你说的设备是什么意思

您可以基于传统工具在云中构建一个伟大的应用程序，就像使用事件驱动架构一样。事实上，它可能是一个“云”应用程序，这与选择平台无关

我想说的是规模比性能更重要。您可能会发现node.js应用程序比运行相同代码的java应用程序运行得慢或快。但是node.js能够做到的是允许更高的吞吐量，因为它不会达到我提到的线程限制。这也意味着您已经构建了一个适当的事件驱动应用程序，在这里您不会阻塞。如果你封锁了，你就摧毁了整个系统

---

我认为它更多的是关于底层的实现，以及它产生的间接费用的讨价还价：

旋转全新的专用线以处理请求。每个线程都会阻塞I/O。但是，在线程级别管理这样的并发是一个混乱

对

使用一个线程，它保持响应，并承诺在将来某个时候处理这些东西。执行I/O时不阻塞，线程级别不需要并发管理。让操作系统来处理这个问题

为什么传统的Apache Tomcat／JBase/WebLogic的java EE架构考虑移动到事件驱动 建筑

也许他们已经厌倦了过于通用的、重量级的解决方案，并想看看新的轻量级替代方案。这些替代方案的开发和部署非常简单，而且可以很好地扩展

事件驱动体系结构是否有助于提供 设备不可知的网站/应用程序

我不认为这些有太多的关联。同一JVM上可以运行多种语言。JVM能够在多台主机上运行，并公开一个标准api，从而带来设备无关的功能。另一个例子是web浏览器

在云上设计应用程序时，我们会选择 异步I/O