共计 1695 个字符，预计需要花费 5 分钟才能阅读完成。
从历史倒退角度看，一个新办法的呈现，必然是先呈现一种不太高效的办法，人们再加以改进。只有先了解了不太高效的办法，才可能了解新技术的实质。所以咱们须要先理解一下什么是 BIO？
传统的 BIO 采纳流的形式进行传输，会造成一个问题：当客户端发送音讯过于迟缓耗时太长，那么接管一方就会继续阻塞上来。也就是说如果发送方须要 60s 能力将数据传输结束，那么接受方将会阻塞 60s。为不便了解咱们先看看一惯的 BIO 伪代码写法：
服务端
- 创立 ServerSocket 对象
- 死循环不断调用 ServerSocket.accept，期待拿到 Socket 对象
- 开启线程 通过 Socket 对象读取输出流
- 读取并解决数据
- 写出响应数据
客户端
- 创立 Socket 对象
- 通过 Socket 对象获取输入流，写入数据
通过伪代码能够晓得，当新接入一个客户端后服务端会新建一个线程来解决客户端申请（所谓的伪异步 I /O），当有成千上万客户端并发申请，BIO 必然支撑不了。因为 BIO 底层最终是调用 linux 内核函数 recvfrom 实现的，它返回数据的节点是在数据包达到且被复制到利用过程缓冲区中或者产生谬误，所以在此期间它会始终阻塞期待着。
此 I / O 模型为 UNIX 中定义的 5 种 I / O 模型的阻塞 I / O 模型
NIO
因而基于 epoll 的多路复用技术实现的 NIO 横空出世解决了 BIO 这一大病垢，NIO 并不是建设 scoket 连贯拿到文件描述符（fd）后就间接调用 recvfrom 函数进行数据读取，它则是将 fd 给到 epoll 函数，由 epoll 函数基于本身的事件驱动机制，当检测到 socket 对应的 fd 的数据可读时，触发回调函数通知用户过程进行数据读取。
题外，select/poll 也属于 I / O 复用模型（当然 epoll 也是），但为什么 Java NIO 底层不必它们进行实现呢？java 培训起因是 select 它们是基于轮询的机制检测所有 fd，发现有可读 fd 才返回，如果没有则阻塞于 select，它的工夫复杂度 O(n)，且 select 基于效率和性能的思考，是有最大限度，默认为 1024。而 epoll 的最大限度是受限于零碎最大文件句柄数。poll 的实现机制和 select 相似。
以上是对 NIO 底层原理的一个浅析，Java NIO 是基于这样的一种机制封装出一套类库来，供开发人员应用。不过原生的 JavaNIO 类库还是过于繁琐不利于应用，因而才有了前面 Netty 的入世。如果要理解 Netty，那必须要对原生 Java NIO 类库的一些概念有肯定相熟。
JAVA 原生 NIO API 编写服务端和客户端大抵步骤如下：
服务端：
- 创立 ServerSocketChannel 对象，同时将它的接管事件，注册到多路复用器 (Selector) 上
- 开启线程（Reactor）一直轮询就绪 Channel
- 当存在就绪 Channel 汇合时，多路复用器会返回 SelectionKey 汇合
- 轮询 SelectionKey 汇合判断对应的事件类型
4.1 如果为接管事件，则通过 ServerSocketChannel.accept() 创立 SocketChannel（相当于了实现 TCP 三次握手，建设物理链路），并将该 SocketChannel 的读事件注册到多路复用器上
4.2 如果为读事件，则对该 Channel 进行数据读取
4.3 如果为写事件，则进行写数据，写结束将该 Channel 写事件从多路复用器上移除。若写半包后 TCP 缓冲区已满，无奈再写时，会持续将该 Channel 的写事件持续注册到多路复用器上，期待下次轮询。
客户端
- 创立 SocketChannel 对象同时它接管事件，注册到多路复用器上
- 开启 Reactor 线程，一直轮询就绪 Channel
- 当存在就绪 Channel 汇合时，多路复用器会返回 SelectionKey 汇合
- 轮询 SelectionKey 汇合判断对应的事件类型
如果为接管事件（示意已建设 TCP），则将 Channel 的读事件注册到多路复用器上。
- 写数据
简略的总结就是 Java NIO 中将通道的接管事件、读、写事件全副注册到多路复用器之上，而后通过一直的轮询多路复用器上是否曾经有就绪 Channel，而后判断对应就绪 Channel 的事件类型，依据事件进行解决。
