本文作者：杨龙，叩丁狼高级讲师。原创文章，转载请注明出处。
IO 操作问题
在 Java 的早期，JVM 在解释字节码时往往很少或没有运行时优化。这就意味着，Java 程序运行速率大大低于本地编译代码，因而对操作系统 I/O 子系统的要求并不太高。在运行时优化方面，JVM 已然前进了一大步。现在 JVM 运行字节码的速率已经接近本地编译代码，借助动态运行时优化，其表现甚至还有所超越。这就意味着，多数 Java 应用程序已不再受 CPU 的束缚（把大量时间用在执行代码上），而更多时候是受 I/O 的束缚（等待数据传输）。
在大多数情况下，Java 应用程序并非真的受着 I/O 的束缚。操作系统并非不能快速传送数据，让 Java 有事可做；相反，是 JVM 自身在 I/O 方面效率欠佳。操作系统与 Java 基于流的 I/O 模型有些不匹配。操作系统要移动的是大块数据（缓冲区），这往往是在硬件直接存储器存取（DMA）的协助下完成的。而 JVM 的 I/O 类喜欢操作小块数据——单个字节、几行文本。结果，操作系统送来整缓冲区的数据，java.io 的流数据类再花大量时间把它们拆成小块，往往拷贝一个小块就要往返于几层对象。操作系统喜欢整卡车地运来数据，java.io 类则喜欢一铲子一铲子地加工数据。有了 NIO，就可以轻松地把一卡车数据备份到您能直接使用的地方（ByteBuffer 对象）。
NIO
为了解决这一问题，java.nio 软件包提供了新的抽象。具体地说，就是 Channel 和 Selector 类。它们提供了使用 I/O 服务的通用 API，JDK 1.4 以前的版本是无法使用这些服务的。天下还是没有免费的午餐：您无法使用每一种操作系统的每一种特性，但是这些新类还是提供了强大的新框架，涵盖了当今商业操作系统普遍提供的高效 I/O 特性。不仅如此，java.nio.channels.spi 还提供了新的服务提供接口（SPI），允许接入新型通道和选择器，同时又不违反规范的一致性。随着 NIO 的面世，Java 已经为严肃的商业、娱乐、科研和学术应用做好了准备。在这些领域，高性能 I/O 是必不可少的。
