Java IO模型&NIO

Java IO模型&NIO

楔子

本文大部分内容翻译自Doug Lea 先生的幻灯片[http://gee.cs.oswego.edu/dl/cpjslides/nio.pdf]. 在此基础上，融入了一些自己的文字。欢迎浏览Doug Lea的个人主页[http://gee.cs.oswego.edu/dl/], 相关内容请尊重原作者。

概述

本文从主要讨论一下几个方面的内容：
- 可扩展的网络服务
- 事件驱动处理
- Reactor（反应堆）模式
基础版
多线程版
其他变体版
- Java NIO API 参考

网络服务

网络服务一般都涉及到Web服务，分布式对象等，但大多数服务端都有相同的基础步骤，如解析读请求（Read Request），请求解码，请求处理，响应编码，发送响应数据。但实际上，在具体的每个步骤上面所带来的性能消耗却每每不同，例如XML解析，文件传输，Web页面生成及渲染，或者其他计数服务这些不同的处理往往会有不同的性能消耗。

经典的服务设计

每个Handler都可以在各自的线程里执行所有的操作。

经典的SocketServer循环阻塞

public class Server implements Runnable {
   

    public void run() {
        try {
            ServerSocket ss = new ServerSocket(PORT);
            while (!Thread.interrupted())
                new Thread(new Handler(ss.accept())).start();
                // 或单线程，或线程池
        } catch (IOException ex) { /* ... */ }
    }
    static class Handler implements Runnable {
   
        final Socket socket;
        Handler(Socket s) { socket = s; }
        public void run() {
            try {
                byte[] input = new byte[MAX_INPUT];
                socket.getInputStream().read(input);
                byte[] output = process(input);
                socket.getOutputStream().write(output);
            } catch (IOException ex) { /* ... */ }
        }
        private byte[] process(byte[] cmd) { /* ... */ }
    }

}
注：示例代码中，大多数异常处理都已省略

如你可见，这样的模式虽简单清晰，但却缺乏弹性伸缩的能力，当客户端并发量增加后，服务端的线程数量会不断增加，最终会耗尽系统资源。即使是中间采用线程池，仍然不能承受大量的并发请求。所以，我们需要新的方案，需要新的模式。但，当务之急是先明确一个目标。

可伸缩目标

• 在面临持续增长的负载（客户请求）压力时，可优雅的降级
• 可通过增加物理资源（CPU,内存，磁盘，带宽）来持续改进
• 仍需满足可用性和性能目标：潜在的短期内目标，高峰期需求指标，服务质量可调

面对上述的目标，分而治之通常是实现可伸缩，可扩展目标的最好的方式。

分而治之

分而治之就是把处理过程折分成明确，职责单一的任务，每个任务采用非阻塞的方式来执行一个操作。 当任务状态是启用时，才开始执行。例如，一个IO事件通常是作为一种触发条件，感知到该事件才开始作相应的read -> decode -> compute -> encode -> send.

这种思想是Java NIO 提供的一种基础的机制。NIO 支持一种非阻塞的读写方式，还有通过感知到的IO事件来分发给相关的任务。

事件驱动设计

这种模式通常比其他的方式更有效，因为它用到的资源会偏少，不用为每个Client分配单独的线程。除此之外，所需开销会减少，因为减少了线程上下文切换，也减少了锁竞争的场景。但调度相应的请求会偏慢，因为需要手动的为事件绑定具体的执行操作。

好事多磨砺。这种模式虽然好处多多，但对于编写程序却不是一件容易的事。因为需要处处考虑把代码写成非阻塞的行为，还需记录并跟踪服务的状态

背景知识：AWT 事件

IO事件驱动模式采用了类似的思想，但使用了不同的设计来实现。

Reactor 模式

Reactor对IO事件的相应是转发到适配的处理器（Handler）上，这类似于AWT的线程。由Handler来执行一些非阻塞的行为。Reactor模式需要绑定Handler到具体的事件上，关于这种模式的详解可以去看这本书：《面向模式的软件架构：卷2》- Pattern-Oriented Software Architecture, Volume 2 (POSA2)。

Reactor基础模式

此外单线程版本，由acceptor接收请求并转发到线程中，由该线程来完成请求的处理