Servlet API 和 NIO: 最终组合在一起

核心提示：NIO 是带有 JDK 1.4 的 Java 平台的最有名（如果不是最出色的）的添加部分之一，下面的许多文章阐述了 NIO 的基本知识及如何利用非阻塞通道的好处，Servlet API 和 NIO: 最终组合在一起，但它们所遗漏的一件事正是，没有充分地展示 NIO 如何可以提高 J2EE Web 层的可伸缩性，标准 I

NIO 是带有 JDK 1.4 的 Java 平台的最有名（如果不是最出色的）的添加部分之一。下面的许多文章阐述了 NIO 的基本知识及如何利用非阻塞通道的好处。但它们所遗漏的一件事正是，没有充分地展示 NIO 如何可以提高 J2EE Web 层的可伸缩性。对于企业开发人员来说，这些信息特别密切相关，因为实现 NIO 不像把少数几个 import 语句改变成一个新的 I/O 包那样简单。首先，Servlet API 采用阻塞 I/O 语义，因此默认情况下，它不能利用非阻塞 I/O。其次，不像 JDK 1.0 中那样，线程不再是“资源独占”（resource hog），因此使用较少的线程不一定表明服务器可以处理更多的客户机。

在本文中，为了创建基于 Servlet 并实现了 NIO 的 Web 服务器，您将学习如何解决 Servlet API 与非阻塞 I/O 的不配合问题。我们将会看到在多元的 Web 服务器环境中，这个服务器是如何针对标准 I/O 服务器（Tomcat 5.0）进行伸缩的。为符合企业中生存期的事实，我们将重点放在当保持 socket 连接的客户机数量以指数级增长时，NIO 与标准 I/O 相比较的情况如何。

注意，本文针对某些 Java 开发人员，他们已经熟悉了 Java 平台上 I/O 编程的基础知识。

线程不再昂贵

大家都知道，线程是比较昂贵的。在 Java 平台的早期（JDK 1.0），线程的开销是一个很大负担，因此强制开发人员自定义生成解决方案。一个常见的解决方案是使用 VM 启动时创建的线程池，而不是按需创建每个新线程。尽管最近在 VM 层上提高了线程的性能，但标准 I/O 仍然要求分配惟一的线程来处理每个新打开的 socket。就短期而言，这工作得相当不错，但当线程的数量增加超过了 1K，标准 I/O 的不足就表现出来了。由于要在线程间进行上下文切换，因此 CPU 简直变成了超载。