最初始的IO模型由于IO在阻塞时会一直等待，因此在用户负载增加时，性能下降的非常快。
server导致阻塞的原因：
1、serversocket的accept方法，阻塞等待client连接，直到client连接成功。
2、线程从socket inputstream读入数据，会进入阻塞状态，直到全部数据读完。
3、线程向socket outputstream写入数据，会阻塞直到全部数据写完。
改进：采用基于事件驱动的设计，当有事件触发时，才会调用处理器进行数据处理。
Reactor：负责响应IO事件，当检测到一个新的事件，将其发送给相应的Handler去处理。
Handler：负责处理非阻塞的行为，标识系统管理的资源；同时将handler与事件绑定。
Reactor为单个线程，需要处理accept连接，同时发送请求到处理器中。
由于只有单个线程，所以处理器中的业务需要能够快速处理完。
改进：使用多线程处理业务逻辑。
将处理器的执行放入线程池，多线程进行业务处理。但Reactor仍为单个线程。
继续改进：对于多个CPU的机器，为充分利用系统资源，将Reactor拆分为两部分。
Using Multiple Reactors
mainReactor负责监听连接，accept连接给subReactor处理，为什么要单独分一个Reactor来处理监听呢？因为像TCP这样需要经过3次握手才能建立连接，这个建立连接的过程也是要耗时间和资源的，单独分一个Reactor来处理，可以提高性能。
Reactor模式解释
Reactor模式首先是事件驱动的，有一个或多个并发输入源，有一个Service Handler，有多个Request Handlers；这个Service Handler会同步的将输入的请求（Event）多路复用的分发给相应的Request Handler。如果用图来表达：
Reactor模式详解
优点
1）响应快，不必为单个同步时间所阻塞，虽然Reactor本身依然是同步的；
2）编程相对简单，可以最大程度的避免复杂的多线程及同步问题，并且避免了多线程/进程的切换开销；
3）可扩展性，可以方便的通过增加Reactor实例个数来充分利用CPU资源；
4）可复用性，reactor框架本身与具体事件处理逻辑无关，具有很高的复用性；
缺点
1）相比传统的简单模型，Reactor增加了一定的复杂性，因而有一定的门槛，并且不易于调试。
2）Reactor模式需要底层的Synchronous Event Demultiplexer支持，比如Java中的Selector支持，操作系统的select系统调用支持，如果要自己实现Synchronous Event Demultiplexer可能不会有那么高效。
3） Reactor模式在IO读写数据时还是在同一个线程中实现的，即使使用多个Reactor机制的情况下，那些共享一个Reactor的Channel如果出现一个长时间的数据读写，会影响这个Reactor中其他Channel的相应时间，比如在大文件传输时，IO操作就会影响其他Client的相应时间，因而对这种操作，使用传统的Thread-Per-Connection或许是一个更好的选择，或则此时使用Proactor模式。