同步与异步
同步和异步关注的是消息通信机制，主要是线程间的协作方式
阻塞和非阻塞关注的是程序在等待调用结果（消息，返回值）时的状态，主要是线程本身等待结果的处理方式
IO模型
- BIO（1:1）:由一个独立的Acceptor线程监听连接，接收到客户连接后为客户创建新线程来处理请求，处理后应答并销毁线程。
- 伪异步（M:N）：Acceptor将请求封装成Task，投递到线程池中。池中维护了消息队列和N个活跃线程。
- NIO(M:1): 一个多路复用器Selector可以同时轮询多个注册在它上面的Channel，服务端只需要一个线程负责Selector的轮询，就可以接入成千上万的客户端连接。主要有 NIO+单线程Reactor模式、NIO+多线程Reactor模式、NIO+主从多线程Reactor模式这三种模式
1）分而治之
一个connection里完整的网络处理过程一般分为6步:accept、read、decode、process、encode、send。
Reactor模式将每个步骤映射为一个Task，服务端线程执行的最小逻辑单元不再是一次完整的网络请求，而是Task，且采用非阻塞方式执行。
2）事件驱动
每个Task对应一个特定事件，当Task准备就绪时，对应的事件通知就会发出。
Reactor收到事件通知后，分发给绑定了对应事件的Handler执行Task。 -
AIO(M:0):等读写过程完成后再去调用回调函数
IO模型对比
IO模型图
以下内容转自 http://blog.51cto.com/xingej/1971598
传统IO模型
1:1形式的同步阻塞IO通信模型
在基于传统同步阻塞模型中：
-
ServerSocket的主要作用？
1、负责绑定IP地址
2、启动监听端口；
-
Socket的主要作用？
负责发起连接操作。
连接成功后，双方通过输入输出流进(InputStream/OutputStream)行同步阻塞式通信
-
通信过程：
1）服务端通常由一个独立的Acceptor线程负责监听客户端的连接；
2）Acceptor监听到客户端的连接请求后，为每个客户端创建一个新的线程进行链路处理；
3）链路处理线程完成客户端请求的处理后，通过输出流返回应答给客户端，然后线程销毁。
-
模型缺点：
1）服务端线程个数与客户端并发访问连接数是1：1的关系；
2）随着客户端并发访问量增大，服务端线程个数线性膨胀，系统性能急剧下降。
-
M:N形式的同步阻塞IO通信模型
服务端通过线程池来处理多个客户端的接入请求，通过线程池约束及调配服务端线程资源。
形成客户端个数M：服务端线程池最大线程数N的比例关系
通信过程：
1）当有新的客户端接入时，将客户端Socket封装成一个Task投递到服务端任务队列；
2）服务端任务线程池中的多个线程对任务队列中的Task进行并行处理；
3）任务线程处理完当前Task后，继续从任务队列中取新的Task进行处理。
模型缺点：
1）BIO的读和写操作都是同步阻塞的，阻塞时间取决于对端IO线程的处理速度和网络IO的传输速度，可靠性差；
2）当线程池中所有线程都因对端IO线程处理速度慢导致阻塞时，所有后续接入的客户端连接请求都将在任务队列中排队阻塞堆积；
3）任务队列堆积满后，新的客户端连接请求将被服务端单线程Acceptor阻塞或拒绝，客户端会发生大量连接失败和连接超时。
-
非阻塞式IO模型(NIO)
基础知识
-
NIO模型
多路复用器Selector是NIO模型的基础，一个多路复用器Selector可以同时轮询多个注册在它上面的Channel，服务端只需要一个线程负责Selector的轮询，就可以接入成千上万的客户端连接。
模型优点：
1）NIO中Channel是全双工(是说可以通过Channel 即可完成读操作，也可以完成写操作)的，Channel比流(InputStream/OutputStream)可以更好地映射底层操作系统的API（UNIX网络[编程](https://m.2cto.com/kf)模型中，底层操作系统的通道都是全双工的，同时支持读写操作）；
2）客户端发起的连接操作是异步的，不需要像之前的客户端那样被同步阻塞；(此时，客户端不依赖于服务器端，也就是说客户端发完请求可以做其他其他事情)
3）一个Selector线程可以同时处理成千上万个client的请求，而且性能不会随着客户端链接的增加而线性下降；原因：JDK的Selector在[Linux](https://m.2cto.com/os/linux/)等主流操作系统上通过epoll实现，它没有连接句柄数的限制，适合做高性能高负载的网络服务器方案
-
Reactor模式思想：
分而治之****+****事件驱动
1）分而治之
一个connection里完整的网络处理过程一般分为6步:accept、read、decode、process、encode、send。
Reactor模式将每个步骤映射为一个Task，服务端线程执行的最小逻辑单元不再是一次完整的网络请求，而是Task，且采用非阻塞方式执行。
2）事件驱动
每个Task对应一个特定事件，当Task准备就绪时，对应的事件通知就会发出。
Reactor收到事件通知后，分发给绑定了对应事件的Handler执行Task。
-
NIO+单线程Reactor模式
说明:
Reactor：负责响应事件，将事件分发给绑定了该事件的Handler处理；
Handler：事件处理器，绑定了某类事件，负责执行对应事件的Task对事件进行处理；
Acceptor：就是处理客户端链接connect事件的； Handler的一种，绑定了connect事件。当客户端发起connect请求时，Reactor会将accept事件分发给Acceptor处理。
模型优缺点
a、单线程版本Reactor模型优点是不需要做并发控制，代码实现简单清晰；
b、缺点是不能利用多核CPU，一个线程需要执行处理所有的accept、read、decode、process、encode、send事件，如果其中decode、process、encode事件的处理很耗时，则服务端无法及时响应其他客户端的请求事件。
-
NIO+多线程Reactor模式
a、使用线程池执行数据的具体处理过程decode、process、encode，提高数据处理过程的响应速度；
b、Reactor所在单线程只需要专心监听处理客户端请求事件accept、read、write；
此模型缺点：
a、因为Reactor仍是单线程，无法并行响应多个客户端的请求事件（比如同一时刻只能read一个客户端的请求数据）。
-
NIO+主从多线程Reactor模式
a、采用多个Reactor，每个Reactor在自己单独线程中执行，可以并行响应多个客户端的请求事件；mainReactor 不再是一个单独的NIO线程，而是一个独立的NIO线程池, 处理链接请求，认证，登陆等操作
Acceptor处理完成后，将事件注册到subReactor线程池中的某个IO线程上去，此IO线程继续完成后面的IO操作
b、Netty采用类似这种模式，boss线程池就是多个mainReactor，worker线程池就是多个subReactor。
Linux中的五种IO模型
https://songlee24.github.io/2016/07/19/explanation-of-5-IO-models/
本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。
