从历史倒退角度看，一个新办法的呈现，必然是先呈现一种不太高效的办法，人们再加以改进。只有先了解了不太高效的办法，才可能了解新技术的实质。所以咱们须要先理解一下什么是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的事件类型，依据事件进行解决。