Java EE：迎合Web 2.0 - 编程入门网

现在假设我们对应用程序和数据库服务器进行了升级，它们的性能提升了两倍。表 2 展示了用时结果（使用与表 1 相关的单位）：

表 2. 升级后的 Servlet 操作时限

可以看到，单个请求处理时间一般为 24 个时间单位，大概是原来的请求持续时间的 3/4。

图 4 展示了业务逻辑、数据库和 Web 服务之间的新的分布：

图 4. 升级后的步骤时间分布

图 5 展示了同步处理后的结果。可以看到，总体持续时间减少了 25%。但是，步骤的分布模式没有发生很大变化，并且 servlet 线程处于等待状态的时间更长了。

图 5. 升级后的同步用例

图 6 展示了异步 API 的处理结果：

图 6. 升级后的异步用例

Java EE：迎合Web 2.0(7)

使用异步 API 得到的结果非常有趣。数据库和应用服务器的性能提高时，处理可以很好地进行相应扩展。结论已经得到证明，并且最差和最佳请求处理时间相差只有 57%。总的处理时间（截至最后一个请求完成）是升级之间所使用时间的 57%。与同步用例的 75% 相比，这是一个很显著的改进。最后一个请求（两种情况中的第 9 个请求）要比同步用例中早完成 40%，而第一个请求仅仅比同步用例晚 14%。此外，在异步用例中，可以执行更多数量的并行 Web 服务操作。而使用同步则无法达到这种并行程度，因为 servlet 线程池中的线程数是有限制的。即使 Web 服务能够处理更多的请求，servlet 也不会发送请求，因为它不处于活动状态。

实际的测试结果表明，异步应用程序具有更好的可伸缩性并且可以更从容地应对超载情况。延迟问题非常棘手，并且 Moore 定律也帮不了什么忙。大多数现代计算改进增加了所需的带宽。多数情况下，延迟可能维持不变，甚至进一步恶化。正因为如此，开发人员才尝试将异步接口引入到应用服务器中。

目前，可以使用很多方法实现异步系统，但是还未将其中任何一种方法确立为事实标准。每种方法都各有优缺点，并且它们在不同的情形中扮演不同的角色。本文后面的内容将对这些机制进行大致介绍，包括各种机制的优缺点，使您能够使用 Java 平台构建事件驱动的异步应用程序。

一般解决方案

Ad-hoc 并发性和 NIO

自 Java 1.4 起，Java 语言提供了一个非阻塞网络 I/O API（java.nio.*）。而从 Java SE 5 开始，Java 提供了更加标准的并发性工具（java.util.concurrent.*）。开发人员利用非阻塞 I/O 和并发性实现的应用程序能够通过可用的 API 和框架支持大量同步连接。

然而，这些 API 仍然处于较低的级别，并且通常只有在无法使用其他方式解决性能问题时才得到使用。NIO 选择器机制是一种非常低级的 API。使用它很难编写任何比复制流更复杂的操作。编写使用相同 NIO 选择器的独立模块也很困难。需要开发一个框架来封装 NIO 并简化这种类型的开发。

鉴于这些原因，很少直接使用 NIO API。应用程序通常使用一个更可用的接口将 NIO API 封装起来。和众多 API 相比，NIO API 有其独特的作用，但是不应该强制应用程序编程

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!