写在前面

Netty，基于NIO的框架

异步的（非阻塞的），基于事件驱动的网络应用框架

适用于针对TCP协议，面向客户端的客户端的高并发应用，Peer-to-Peer（点对点）场景的大量数据持续传输

TCP/IP < 原生JDK < NIO < Netty框架

RPC框架（Remote Procedure Call 远程过程调用），一个节点请求另一台服务器上的节点的服务，Netty作为基础组件

游戏、大数据（AVRO，数据文件共享）

阻塞IO，传统线程池的处理方式

在进行同步I/O操作时，如果读取数据，代码会阻塞直至有可读取的数据；写数据时，阻塞直至数据能够写入

服务器会为每个客户端请求建立一个线程，该线程单独负责处理客户请求

会导致线程数量急剧增加，增大服务器开销

面向流

非阻塞IO，NIO

基于Reactor的工作方式，I/O不会被阻塞，注册感兴趣的特定I/O事件，发生特定时间时，系统通知我们进行对应的执行

通过selector进行选择，注册各种I/O事件，当感兴趣的事件发生，选取进行执行

本质是延迟I/O操作，当有I/O操作请求时，才打开IO流，进行操作

面向缓冲区

IO模型，用什么通道进行数据的发送和接收，决定通信的性能

BIO 同步阻塞，一个连接一个线程，客户端有请求，服务端启动一个线程进行处理，如果连接不做任何事，造成线程开销；适用于连接数目比较小且固定的架构，对服务器资源要求高

NIO 同步非阻塞，一个线程处理多个请求，一个服务器可以维护多个选择器，客户端发送的连接请求注册到多路复用器（selector）上，轮询IO请求；连接数目多且连接比较短，聊天服务器，弹幕，服务器间通讯

AIO，异步非阻塞，Proactor模式，在异步操作完成后触发服务请求的分配和分发，有效的请求才启动线程，通知型；先由操作系统完成后，才通知服务端器启动线程处理；连接数目多且连接比较长，重操作，相册服务器，依赖操作系统

BIO与NIO

BIO以流的方式处理，NIO以块的方式处理，块效率高

BIO阻塞，NIO非阻塞

BIO基于流和字符串，NIO基于通道和缓冲区，利用selector，单个线程可以监听多个客户端通道

BIO

NIO

NIO采用Reactor模式，事件驱动，当有事件触发时，才会进行相应处理
NIO，non-blocking IO，同步非阻塞，1.4之后，有三个核心部分，面向缓冲区，变向块的编程

Channels，通道，双向，可读可写

Buffers，缓冲区

Selectors，选择器，单线程处理多个通道

数据读取到稍后处理的缓冲区，需要时在缓冲区处理，提供非阻塞式的高伸缩性网络

http2.0 使用了多路复用技术，做到一个连接并发处理多个请求
三大组件的关系

每一个Channel都会对应一个Buffer

selector对应一个线程，一个线程（服务端）对应多个channel，channel对于selector为注册动作

程序切换到哪个channel，是由事件决定的

selector根据不同的事件，在各个通道上切换

Buffer是一个内存块，底层是一个数组

数据的读写是通过Buffer的，而BIO是直接往连接里写，BIO要么是输入流，要么是输出流，不能双向；NIO通过调整指针位置，进行读写切换

channel是双向的，可以返回底层操作系统的情况；Linux底层的操作系统的通道就是双向的