Netty是基于NIO的异步通信框架（曾经引入过AIO，后来放弃），故要说Netty原理我们要先从NIO开始。

image.png

NIO 是JAVA在JDK4中引入的同步非阻塞通信模型，在NIO出现之前（JDK4之前）市场上只有一个BIO模型顾名思义BLOCKING IO （同步阻塞通信模型）
BIO（BLOCKING I/O）：
BIO 为一个连接 一个线程的模式，当有连接时服务器会开启一个线程来处理请求

image.png

若此请求啥都不想干此时线程会怎么样？
此线程会进入阻塞模式（BLOCKING）！---啥也不干，干等着zzZZ~

image.png

这种一连接，一线程的模式会造成服务器资源不必要的开销并且在大量连接访问时 服务器会发生什么？车道（线程）不足，车太多--我堵车了

image.png

由此就出现了NIO
↓
NIO（new/NONBLOCKING I/O）:
NIO为同步非阻塞通信模型，Select（多路复用器）为此模型的核心，实现了多个连接一个线程

image.png

当有客户端连接请求时 此连接请求会被注册至select上，当select检测到此连接有I/O请求时才会打开一个线程去对此I/O请求进行处理-----单线程模型

image.png

这个时候有人问了：这么多操作都在一个线程里，线程忙不过来怎么办？

image.png

此时 由于网络请求、I/O读写、业务操作都在一个线程下，会导致在高并发的情况下存在性能瓶颈 于是乎有人就提出来 将业务操作丢到另一个线程怎么样？

image.png

于是出现了第三种reactor模型-使用线程池进行操作网络请求、IO在一个线程，业务操作在另个一个线程 的业务分离----线程池模型

image.png

从此图中可以看出此时 模型中使用一个线程池来进行网络请求、IO读取
当读取完成后将业务操作绑定在线程池中另外的线程上-------网络IO与业务操作可以同步进行了！一切都完美了起来！

image.png

但是！事情还没完！！这个时候又有人提出问题：在高并发的时候咋办？会不会有性能瓶颈

image.png

因为网络IO是非常消耗CPU的，当网络请求与网络IO在同个线程中时，造C10K的情况下单个线程并不足以支撑起所有的IO操作！因此也形成了在高并发状态下的性能瓶颈

image.png

于是大佬们就想着，如果把IO拆出来让单个线程池去接收网络请求，用另一个线程池来进行IO与业务操作会不会更好

image.png

于是第四种Reactor模型应运而生--主从Reactor多线程模型

image.png

此模型中 mainReactor只用于接收网络请求，而subReactor中为一个线程池，线程池中每个线程上绑定一个select
当mainReactor接收到请求时（一个描述符） 系统会生成一个新的描述符代表此连接生效，此时mainReactor会将新的描述符通过一个算法在线程池中选定一个线程 将此描述符绑定至此线程池上的select上，由此线程来对请求进行I/O 与业务操作
从此百万连接高并发不是问题

image.png

写到这 我们是不是想起了Netty的启动过程
1、声明两个EventLoopGroup一个为boss（mainReactor）一个为worker（subReactor）
EventLoopGroup（线程池）初始化的时候会生成（懒加载）指定数量的EventLoop（线程）若无指定 则会生成CPU数X2的线程
2、声明一个启动辅助类Bootstrap并将EventLoopGroup注册到启动辅助类BootStrap上(bootStrap.group)
接着再给bootstrap指定channel模型等属性，再添加上业务流水线（channelpipeline）并且在pipeline中添加上业务操作handler，（通过channelpipeline可以对传入数据为所欲为）
3、绑定端口
Netty启动完成

这时候可能有人会问了：这和你上面说的reactor？NIO有啥关系？

image.png

这个时候我们要这么看
↓
若我们将boss与worker线程池设置为相同的一个线程池，那么会发生什么事？
此时关注一下第三个Reactor模型时就会发现 当BOSS=WORKER时候 netty实现的就是第三种Reactor模型 使用线程池模型
而当boss不等于worker的时候使用的就是第四种 主从多线程模型
Netty就是基于Reactor模型来对NIO进行了易用化封装，从Netty源码中就可以看出来其实底层还都是NIO的接口

image.png

此次处为自己读源码之后的理解 如有误请指正
感恩
反手拿下第一个赞

image.png