一

由于本人的码云太多太乱了，于是决定一个一个的整合到一个springboot项目里面。

附上自己的github项目地址 https://github.com/247292980/spring-boot

附上汇总博文地址 https://www.cnblogs.com/ydymz/p/9391653.html

以整合功能

spring-boot，FusionChart，thymeleaf，vue，ShardingJdbc，mybatis-generator，微信分享授权，drools，spring-security，spring-jpa，webjars，Aspect，drools-drt，rabbitmq，zookeeper，mongodb，mysql存储过程，前端的延迟加载，netty，postgresql，树的遍历

这次再次说下netty，为什么在学netty呢？因为面试一家大公司的时候，被问倒了，，，所以只好耐下心来看原理了。

目前看了两本netty的书（市面上就两本 orz）第一感觉就是netty的书怎么说呢，就是demo集合，某程度还是挺好看懂的，但是过时啊。

不过参考之前写drools的痛苦经验，国内大部分环境应该也是用过时的netty，不信你去技术群里问下新版netty的特性，大家一定会劝你去踩坑...

而这篇文章也不介绍新特性，只是对netty的原理研究。说实话就是丢图，，，

二 模型

说到netty一定要知道他的基本模型。

1.先说下之前的bio-同步阻塞io

显然有点网络基础的人都写过类似的代码。优缺点很明显

缺点：性能瓶颈。每个链接一个线程，怎么保证线程的即时回收和可靠回收是一大技术问题。而该模型在遇到大量线程的时候（超过某个阈值，例如java默认的线程上限或者linux的默认线程上限之类的）性能指数性下降啊。

优点：简单。所以我才说有点网络基础的人都写过类似的代码，，，除非直接起手springboot的

2.后面就是nio-同步非阻塞io

acceptor收到所有的连接请求

acceptor上注册了selector，

服务器构建对应的Channel，并在其上注册Selector

selector分配请求到不同的channel，进行相应的读写处理。

ps.写完发现可能有点难理解，具体代码项目里面有。

其实就是selector分配请求，channel处理请求并能通过selector得到client，等处理完成后直接返回client，不走selector。

优点：一个线程处理全部连接，不阻塞后面的连接。性能大提升！

缺点：模型复杂，代码复杂（至少我觉得不看一下代码，很难说清）；处理半包问题

ps.半包问题

我们知道TCP/IP在发送消息的时候，可能会拆包。这就导致接收端无法知道什么时候收到的数据是一个完整的数据。

例如:发送端分别发送了ABC,DEF,GHI三条信息，发送时被拆成了AB,CDRFG,H,I这四个包进行发送，接受端如何将其进行还原呢？在BIO模型中，当读不到数据后会阻塞，而NIO中不会!所以需要自行进行处理!说到底就是自定义网络协议，额其实这个有点基础的都写过，我也不细说了。

3.所以为了解决这问题，netty就使用了Reactor模型-bio的变种

具体来说这是reactor的单线程模型，可以看出和bio基本没什么差别，就是把channel的数据处理提到handler，并且统一在reactor注册了，而不用去acceptor，channel分别注册在两个地方，统一处理了。

但是这玩意有个问题就是，一个client多次请求，handler中的处理特别慢，那么后续的请求就会被积压。

4.Reactor多线程模型

reactor将接受发送分离，client发送的请求丢到线程池中，所以后续请求不会被阻塞。

但是当用户进一步增加的时候，Reactor会出现瓶颈！因为Reactor既要处理IO操作请求，又要响应连接请求！为了分担Reactor的负担，所以引入了主从Reactor模型!

上面的这一句话是书上原话，其实我是不太赞成的，因为说到底就是一个线程的事，所以没可能是性能瓶颈，而在我看来netty使用主从reactor的主要原因是代码可读性和易于理解。

5.Reactor主从模型

简单明了

client发送请求

acceptor就是个死循环监听

mainreactor分配acceptor监听到的请求到channel

channel通过subreactor将请求发到handler处理，然后直接返回给client

ps.注意的是mainreactor一定是单线程，多线程可能导致为client分配channel的时候，一个线程分配了一个，浪费资源；也存在一个client的请求去了两线程，而其中一个处理很久，另一个则早早完成，而此时client的等待时间是取最大等待时间的，那么早早完成的还不如一起在另一个处理很久的线程里面；

三 术语

bootstrap： Netty 通过设置 bootstrap（引导）类的开始，该类提供了一个应用程序网络层配置的容器

Channel： 是一个客户端用来进行连接的 Channel，记录了client信息，用于io操作的交互

ChannelHandler： 数据处理的容器

ChannelPipeline：提供了一个容器给 ChannelHandler 链并提供了一个API 用于管理沿着链入站和出站事件的流动

EventLoop： EventLoop 用于处理 Channel 的 I/O 操作。一个单一的 EventLoop通常会处理多个 Channel 事件

EventLoopGroup：可以含有多于一个的 EventLoop 和 提供了一种迭代用于检索清单中的下一个

ChannelFuture： ChannelFuture是netty的一个回调不管是否成功返回

ChannelFutureListener：ChannelFuture通过addListener 注册。当操作完成时，可以被通知（不管成功与否）

ps.ChannelFutureListener加上了之后就可以说是实现异步。

四 channel

通常来说, 所有的 netty 的 I/O 操作都是从 Channel 开始的. 一个 channel 类似于一个 stream.

Stream 和 Channel 对比

我们可以在同一个 Channel 中执行读和写操作, 然而同一个 Stream 仅仅支持读或写.

Channel 可以异步地读写, 而 Stream 是阻塞的同步读写.

Channel 总是从 Buffer 中读取数据, 或将数据写入到 Buffer 中.

Channel 类型有:

FileChannel, 文件操作

DatagramChannel, UDP 操作

SocketChannel, TCP 操作

ServerSocketChannel, TCP 操作, 使用在服务器端.

五 Buffer

与 Channel 进行交互时, 我们就需要使用到 Buffer, 即数据从 Buffer读取到 Channel 中, 并且从 Channel 中写入到 Buffer 中.

Buffer 其实就是一块内存区域, 并提供了一些操作方法让我们能够方便地进行数据的读写.

Buffer 类型有:

ByteBuffer，CharBuffer，DoubleBuffer，FloatBuffer，IntBuffer，LongBuffer，ShortBuffer（就是基本类型啊）

六 Selector

Selector 允许一个单一的线程来操作多个 Channel. 如果我们的应用程序中使用了多个 Channel, 那么使用 Selector 很方便的实现这样的目的, 但是因为在一个线程中使用了多个 Channel, 因此也会造成了每个 Channel 传输效率的降低.

为了使用 Selector, 我们首先需要将 Channel 注册到 Selector 中, 随后调用 Selector 的 select()方法, 这个方法会阻塞, 直到注册在 Selector 中的 Channel 发送可读写事件. 当这个方法返回后, 当前的这个线程就可以处理 Channel 的事件了.

七 Bootstrap

Bootstrap 是 Netty 提供的一个便利的工厂类, 我们可以通过它来完成 Netty 的客户端或服务器端的 Netty 初始化.

作者：lgp20151222

原文：https://www.cnblogs.com/ydymz/p/10219637.html