Netty总结

柔光的暖阳◎ 2022-05-18 07:56 177阅读 0赞

# 一、IO模型 #

1.  **阻塞IO（bloking IO）**：优点：能够及时返回数据，无延迟；方便调试；缺点：需要付出等待的代价
2.  **非阻塞IO（non-blocking IO）**：优点：不需要等待任务 ，而是把时间花费到其它任务上，也就是这个当前线程同时处理多个任务；缺点：导致任务完成的响应延迟增大，因为每隔一段时间才去执行询问的动作，但是任务可能在两个询问动作的时间间隔内完成，这会导致整体数据吞吐量的降低
3.  **多路复用IO（multiplexing IO）**：优点：能够同时处理多个连接，系统开销小，系统不需要创建新的额外进程或者线程，也不需要维护这些进程和线程的运行，降低了系统的维护工作量，节省了系统资源；      缺点：如果处理的连结数目不高的话，使用select/epoll的web server不一定比使用multi-threading + blocking IO的web server性能更好，可能延迟还更大。（因为阻塞可以保证没有延迟，但是多路复用是处理先存在的数据，所以数据的顺序则不管，导致处理一个完整的任务的时间上有延迟）
4.  **信号驱动式IO（signal-driven IO）**
5.  **异步IO（asynchronous IO）**

**    前四种是同步的，最后一种是异步的**

# 二、阻塞和非阻塞，同步和异步 #

*  **同步与异步**：描述的是用户线程与内核的交互方式，同步指用户线程发起IO请求后需要等待或者轮询内核IO操作完成后才能继续执行；而异步是指用户线程发起IO请求后仍然继续执行，当内核IO操作完成后会通知用户线程，或者调用用户线程注册的回调函数。
 *  **阻塞与非阻塞**：描述是用户线程调用内核IO操作的方式，阻塞是指IO操作需要彻底完成后才返回到用户空间；而非阻塞是指IO操作被调用后立即返回给用户一个状态值，无需等到IO操作彻底完成

以银行取款为例：

*  同步 ： 自己亲自出马持银行卡到银行取钱（使用同步IO时，Java自己处理IO读写）；
 *  异步 ： 委托一小弟拿银行卡到银行取钱，然后给你（使用异步IO时，Java将IO读写委托给OS处理，需要将数据缓冲区地址和大小传给OS(银行卡和密码)，OS需要支持异步IO操作API）；
 *  阻塞 ： ATM排队取款，你只能等待（使用阻塞IO时，Java调用会一直阻塞到读写完成才返回）；
 *  非阻塞 ： 柜台取款，取个号，然后坐在椅子上做其它事，等号广播会通知你办理，没到号你就不能去，你可以不断问大堂经理排到了没有，大堂经理如果说还没到你就不能去（使用非阻塞IO时，如果不能读写Java调用会马上返回，当IO事件分发器会通知可读写时再继续进行读写，不断循环直到读写完成）

# 三、BIO、NIO、AIO #

*  BIO(同步阻塞IO)：一个连接一个线程，客户端有连接请求时服务器端就需要启动一个线程进行处理。线程开销大。
 *  NIO(同步非阻塞IO)：一个请求一个线程，但客户端发送的连接请求都会注册到多路复用器上，多路复用器轮询到连接有I/O请求时才启动一个线程进行处理
 *  AIO(异步非阻塞IO，NIO.2)：一个有效请求一个线程，客户端的I/O请求都是由OS先完成了再通知服务器应用去启动线程进行处理
 *  BIO是面向流的，流是单向阻塞的。NIO是面向缓冲区，非阻塞的，NIO的channel是双向的

BIO、NIO、AIO适用场景分析:

*  BIO方式适用于连接数目比较小且固定的架构，这种方式对服务器资源要求比较高，并发局限于应用中，JDK1.4以前的唯一选择，但程序直观简单易理解。
 *  NIO方式适用于连接数目多且连接比较短（轻操作）的架构，比如聊天服务器，并发局限于应用中，编程比较复杂，JDK1.4开始支持。
 *  AIO方式使用于连接数目多且连接比较长（重操作）的架构，比如相册服务器，充分调用OS参与并发操作，编程比较复杂，JDK7开始支持。

# 四、NIO介绍 #

###     4.1 NIO的特点 ###

事件驱动模型、单线程处理多任务、非阻塞I/O，基于block的传输比基于流的传输更高效、更高级的IO函数zero-copy、IO多路复用大大提高了Java网络应用的可伸缩性和实用性。基于Reactor线程模型

###     4.2 NIO编程 ###

1.  **Selector（选择器、多路复用器****）**：Selector会不断的轮询注册在其上的通道（Channel），如果某个通道发生了读写操作，这个通道就处于就绪状态，会被Selector轮询出来，然后通过SelectionKey可以取得就绪的Channel集合，从而进行后续的IO操作。有多种的状态位（SelectionKey.OP\_CONNECT，SelectionKey.OP\_ACCEPT，SelectionKey.OP\_READ，SelectionKey.OP\_WRITE）。一个多路复用器（Selector）可以负责成千上万的通道（Channel），没有上限。这也是JDK使用了epoll代替传统的select实现，获得连接句柄（客户端）没有限制。
2.  **Channel（管道、通道）**：通道是双向的，而流只能在一个方向上移动（一个流必须是InputStream或者OutputStream的子类），而通道可以用于读、写或者二者同时进行。通道分为两大类：一类是用于网络读写的SelectableChannel，另一类是用于文件操作的FileChannel，我们使用的SocketChannel和ServerSocketChannel都是SelectableChannel的子类。
3.  **Buffer（缓冲区）：**在NIO类库中，所有的数据都是用缓冲区处理的（读写）。 缓冲区实质上是一个数组，通常它是一个字节数组（ByteBuffer），也可以使用其他类型的数组。这个数组为缓冲区提供了访问数据的读写等操作属性，如位置、容量、上限等概念。Buffer类型：最常使用的是ByteBuffer，实际上每一种java基本类型都对应了一种缓存区（除了Boolean类型）。①ByteBuffer②CharBuffer③ShortBuffer④IntBuffer⑤LongBuffer⑥FloatBuffer⑦DoubleBuffer。    当向 Buffer 写入数据时，Buffer 会记录下写了多少数据。一旦要读取数据，需要通过 flip() 方法将 Buffer ***从写模式切换到读模式***。在读模式下，可以读取之前写入到 Buffer 的所有数据。一旦读完了所有的数据，就需要清空缓冲区，让它可以再次被写入。有两种方式能清空缓冲区：调用 clear() 或 compact() 方法。clear() 方法会清空整个缓冲区。compact() 方法只会清除已经读过的数据。任何未读的数据都被移到缓冲区的起始处，新写入的数据将放到缓冲区未读数据的后面

案例详情访问[https://blog.csdn.net/qq\_33314107/article/details/80353427][https_blog.csdn.net_qq_33314107_article_details_80353427]

# 五、select、poll和epoll区别 #

**     1、支持一个进程所能打开的最大连接数**

![format_png][]

**    2、FD(套接字数量****)剧增后带来的IO效率问题**

**           ![format_png 1][]**

**   3、消息传递方式**

**         ![format_png 2][]**

综上，表面上看epoll的性能最好，但是在连接数少并且连接都十分活跃的情况下，select和poll的性能可能比epoll好，毕竟epoll的通知机制需要很多函数回调。select低效是因为每次它都需要轮询。但低效也是相对的，视情况而定，也可通过良好的设计改善。

详情访问[https://blog.csdn.net/qq\_33314107/article/details/81712589][https_blog.csdn.net_qq_33314107_article_details_81712589]

# 六、Netty和Mina的比较 #

1.  Netty的文档更清晰，很多Mina的特性在Netty里都有；
2.  Netty更新周期更短，新版本的发布比较快；
3.  它们的架构差别不大，Mina靠apache生存，而Netty靠jboss，和jboss的结合度非常高，Netty有对google protocal buf的支持，有更完整的ioc容器支持(spring,guice,jbossmc和osgi)；
4.  Netty比Mina使用起来更简单，Netty里你可以自定义的处理upstream events或/和downstream events，可以使用decoder和encoder来解码和编码发送内容；
5.  Netty和Mina在处理UDP时有一些不同，Netty将UDP无连接的特性暴露出来；而Mina对UDP进行了高级层次的抽象，可以把UDP当成”面向连接”的协议，而要Netty做到这一点比较困难
6.  Mina将内核和一些特性的联系过于紧密，使得用户在不需要这些特性的时候无法脱离，相比下性能会有所下降，Netty解决了这个设计问题；

# 七、Netty介绍 #

*  一个高性能、异步事件驱动的NIO框架，它提供了对TCP、UDP和文件传输的支持
 *  使用更高效的socket底层，对epoll空轮询引起的cpu占用飙升在内部进行了处理，避免了直接使用NIO的陷阱，简化了NIO的处理方式。
 *  采用多种decoder/encoder 支持，对TCP粘包/分包进行自动化处理
 *  可使用接受/处理线程池，提高连接效率，对重连、心跳检测的简单支持
 *  可配置IO线程数、TCP参数， TCP接收和发送缓冲区使用直接内存代替堆内存，通过内存池的方式循环利用ByteBuf
 *  通过引用计数器及时申请释放不再引用的对象，降低了GC频率
 *  使用单线程串行化的方式，高效的Reactor线程模型
 *  大量使用了volitale、使用了CAS和原子类、线程安全类的使用、读写锁的使用

# 八、Netty线程模型 #

*  Netty通过Reactor模型基于多路复用器接收并处理用户请求，内部实现了两个线程池，boss线程池和work线程池，其中boss线程池的线程负责处理请求的accept事件，当接收到accept事件的请求时，把对应的socket封装到一个NioSocketChannel中，并交给work线程池，其中work线程池负责请求的read和write事件，由对应的Handler处理。
 *  单线程模型：所有I/O操作都由一个线程完成，即多路复用、事件分发和处理都是在一个Reactor线程上完成的。既要接收客户端的连接请求,向服务端发起连接，又要发送/读取请求或应答/响应消息。一个NIO 线程同时处理成百上千的链路，性能上无法支撑，速度慢，若线程进入死循环，整个程序不可用，对于高负载、大并发的应用场景不合适。
 *  多线程模型：有一个NIO 线程（Acceptor） 只负责监听服务端，接收客户端的TCP 连接请求；NIO 线程池负责网络IO 的操作，即消息的读取、解码、编码和发送；1 个NIO 线程可以同时处理N 条链路，但是1 个链路只对应1 个NIO 线程，这是为了防止发生并发操作问题。但在并发百万客户端连接或需要安全认证时，一个Acceptor 线程可能会存在性能不足问题。
 *  主从多线程模型：Acceptor 线程用于绑定监听端口，接收客户端连接，将SocketChannel 从主线程池的Reactor 线程的多路复用器上移除，重新注册到Sub 线程池的线程上，用于处理I/O 的读写等操作，从而保证mainReactor只负责接入认证、握手等操作；

详情访问[https://blog.csdn.net/cj2580/article/details/78124780][https_blog.csdn.net_cj2580_article_details_78124780]

# 九、TCP 粘包/拆包 #

TCP是以流的方式来处理数据，一个完整的包可能会被TCP拆分成多个包进行发送，也可能把小的封装成一个大的数据包发送

**产生的原因：**

1.  应用程序写入的字节大小大于套接字发送缓冲区的大小，会发生拆包现象，而应用程序写入数据小于套接字缓冲区大小，网卡将应用多次写入的数据发送到网络上，这将会发生粘包现象；
2.  进行MSS大小的TCP分段，当TCP报文长度-TCP头部长度>最大报文段长度MSS的时候将发生拆包
3.  以太网帧的payload（净荷）大于最大传输单元MTU（1500字节）进行ip分片

**解决方案：**

1.  消息定长；例如：每个报文的大小固定为200个字节，如果不够，空位补空格；对应Netty中的定长类 ：FixedLengthFrameDecoder
2.  在包尾都增加特殊字符进行分割；例如：加回车、加换行、FTP协议等；对应Netty中的类：1）自定义分隔符类 ：DelimiterBasedFrameDecoder   2）行分隔符类：LineBasedFrameDecoder
3.  将消息分为消息头和消息体；例：在消息头中包含表示消息总长度的字段，然后进行业务逻辑的处理。对应Netty中的基于消息头指定消息长度类：LengthFieldBasedFrameDecoder
4.  更复杂的应用层协议；解决TCP粘包/分包问题的实例请阅读我的下一篇博文：[解决TCP粘包/分包的实例][TCP]

# 十、序列化 #

###    10.1 概念 ###

序列化（编码）将对象序列化为二进制形式（字节数组），主要用于网络传输、数据持久化等；反序列化（解码）是将将从网络、磁盘等读取的字节数组还原成原始对象，主要用于网络传输对象的解码，以便完成远程调用

###    10.2  影响序列化性能的关键因素 ###

1.  序列化后的码流大小（网络带宽的占用）；
2.  序列化的性能（CPU资源占用）；
3.  是否支持跨语言（异构系统的对接和开发语言切换）

###    10.3 Serializable序列化问题 ###

1.  序列化 ID 不同，无法相互序列化和反序列化
2.  序列化并不保存静态变量
3.  Transient 关键字能阻止该变量被序列化到文件
4.  子类实现 Serializable 接口，父类不实现，父类的字段数据将不被序列化
5.  当写入文件的为同一对象时，并不会再将对象的内容进行存储，而只是再次存储一份引用
6.  在序列化过程中，虚拟机会试图调用对象类里的 writeObject 和 readObject 方法，进行用户自定义的序列化和反序列化，如果没有这样的方法，则默认调用是 ObjectOutputStream 的 defaultWriteObject 方法以及 ObjectInputStream 的 defaultReadObject 方法。用户自定义的 writeObject 和 readObject 方法可以允许用户控制序列化的过程，比如可以在序列化的过程中动态改变序列化的数值。基于这个原理，可以在实际应用中得到使用，用于敏感字段的加密工作

###    10.4 方式 ###

1.  **Java默认提供的序列化**：必须实现Serializable接口。无法跨语言、序列化后的码流太大、序列化的性能差
2.  **XML**，优点：人机可读性好，可指定元素或特性的名称。缺点：序列化数据只包含数据本身以及类的结构，不包括类型标识和程序集信息；只能序列化公共属性和字段；不能序列化方法；文件庞大，文件格式复杂，传输占带宽。适用场景：当做配置文件存储数据，实时数据转换
3.  **JSON**：Json序列化一般会使用jackson包，通过ObjectMapper类来进行一些操作，比如将对象转化为byte数组或者将json串转化为对象，优点：兼容性高、数据格式比较简单，易于读写、序列化后数据较小，可扩展性好，兼容性好、与XML相比，其协议比较简单，解析速度比较快。缺点：数据的描述性比XML差、不适合性能要求为ms级别的情况、额外空间开销比较大。适用场景（可替代ＸＭＬ）：跨防火墙访问、可调式性要求高、基于Web browser的Ajax请求、传输数据量相对小，实时性要求相对低（例如秒级别）的服务
4.  **Fastjson**，阿里巴巴开发的一个性能很好的Java 语言实现的 Json解析器和生成器。优点：接口简单易用、目前java语言中最快的json库。缺点：过于注重快，而偏离了“标准”及功能性、代码质量不高，文档不全。适用场景：协议交互、Web输出、Android客户端
5.  Thrift，不仅是序列化协议，还是一个RPC框架。优点：序列化后的体积小, 速度快、支持多种语言和丰富的数据类型、对于数据字段的增删具有较强的兼容性、支持二进制压缩编码。缺点：使用者较少、跨防火墙访问时，不安全、不具有可读性，调试代码时相对困难、不能与其他传输层协议共同使用（例如HTTP）、无法支持向持久层直接读写数据，即不适合做数据持久化序列化协议。适用场景：分布式系统的RPC解决方案
6.  Avro，Hadoop的一个子项目，解决了JSON的冗长和没有IDL的问题。优点：支持丰富的数据类型、简单的动态语言结合功能、具有自我描述属性、提高了数据解析速度、快速可压缩的二进制数据形式、可以实现远程过程调用RPC、支持跨编程语言实现。缺点：对于习惯于静态类型语言的用户不直观。适用场景：在Hadoop中做Hive、Pig和MapReduce的持久化数据格式。
7.  Protobuf，将数据结构以.proto文件进行描述，通过代码生成工具可以生成对应数据结构的POJO对象和Protobuf相关的方法和属性。优点：序列化后码流小，性能高、结构化数据存储格式（XML JSON等）、通过标识字段的顺序，可以实现协议的前向兼容、结构化的文档更容易管理和维护。缺点：需要依赖于工具生成代码、支持的语言相对较少，官方只支持Java 、C++ 、python。适用场景：对性能要求高的RPC调用、具有良好的跨防火墙的访问属性、适合应用层对象的持久化
8.  其它

*  protostuff 基于protobuf协议，但不需要配置proto文件，直接导包即可
 *  Jboss marshaling 可以直接序列化java类， 无须实java.io.Serializable接口
 *  Message pack 一个高效的二进制序列化格式
 *  Hessian 采用二进制协议的轻量级remoting onhttp工具
 *  kryo 基于protobuf协议，只支持java语言,需要注册（Registration），然后序列化（Output），反序列化（Input）

# 十一、Netty的zero-copy(零拷贝) #

1.  Netty的接收和发送ByteBuffer采用Direct Buffer，使用堆外直接内存进行Socket读写，不需要进行字节缓冲区的二次拷贝。堆内存多了一次内存拷贝，JVM会将堆内存Buffer拷贝一份到直接内存中，然后才写入Socket中。ByteBuffer由ChannelConfig分配，而ChannelConfig创建ByteBufAllocator默认使用Direct Buffer
2.  CompositeByteBuf 类可以将多个 ByteBuf 合并为一个逻辑上的 ByteBuf, 避免了传统通过内存拷贝的方式将几个小Buffer合并成一个大的Buffer。addComponents方法将 header 与 body 合并为一个逻辑上的 ByteBuf, 这两个 ByteBuf 在CompositeByteBuf 内部都是单独存在的, CompositeByteBuf 只是逻辑上是一个整体
3.  通过 FileRegion 包装的FileChannel.tranferTo方法 实现文件传输, 可以直接将文件缓冲区的数据发送到目标 Channel，避免了传统通过循环write方式导致的内存拷贝问题。
4.  通过 wrap方法, 我们可以将 byte\[\] 数组、ByteBuf、ByteBuffer等包装成一个 Netty ByteBuf 对象, 进而避免了拷贝操作
5.  Selector BUG：若Selector的轮询结果为空，也没有wakeup或新消息处理，则发生空轮询，CPU使用率100%
6.  Netty的解决办法：对Selector的select操作周期进行统计，每完成一次空的select操作进行一次计数，若在某个周期内连续发生N次空轮询，则触发了epoll死循环bug。重建Selector，判断是否是其他线程发起的重建请求，若不是则将原SocketChannel从旧的Selector上去除注册，重新注册到新的Selector上，并将原来的Selector关闭

# 十二、Netty的高性能表现 #

1.   心跳，对服务端：会定时清除闲置会话inactive(netty5)，对客户端:用来检测会话是否断开，是否重来，检测网络延迟，其中idleStateHandler类 用来检测会话状态
2.  串行无锁化设计，即消息的处理尽可能在同一个线程内完成，期间不进行线程切换，这样就避免了多线程竞争和同步锁。表面上看，串行化设计似乎CPU利用率不高，并发程度不够。但是，通过调整NIO线程池的线程参数，可以同时启动多个串行化的线程并行运行，这种局部无锁化的串行线程设计相比一个队列-多个工作线程模型性能更优。
3.  可靠性，链路有效性检测：链路空闲检测机制，读/写空闲超时机制；内存保护机制：通过内存池重用ByteBuf;ByteBuf的解码保护；优雅停机：不再接收新消息、退出前的预处理操作、资源的释放操作。
4.  Netty安全性：支持的安全协议：SSL V2和V3，TLS，SSL单向认证、双向认证和第三方CA认证。
5.  高效并发编程的体现：volatile的大量、正确使用；CAS和原子类的广泛使用；线程安全容器的使用；通过读写锁提升并发性能。IO通信性能三原则：传输（AIO）、协议（Http）、线程（主从多线程）
6.  流量整型的作用（变压器）：防止由于上下游网元性能不均衡导致下游网元被压垮，业务流中断；防止由于通信模块接受消息过快，后端业务线程处理不及时导致撑死问题。
7.  TCP参数配置：SO\_RCVBUF和SO\_SNDBUF：通常建议值为128K或者256K；SO\_TCPNODELAY：NAGLE算法通过将缓冲区内的小封包自动相连，组成较大的封包，阻止大量小封包的发送阻塞网络，从而提高网络应用效率。但是对于时延敏感的应用场景需要关闭该优化算法；

# 十三、Netty案例 #

详情访问[https://www.cnblogs.com/myJavaEE/p/6793332.html][https_www.cnblogs.com_myJavaEE_p_6793332.html]

[https_blog.csdn.net_qq_33314107_article_details_80353427]: https://blog.csdn.net/qq_33314107/article/details/80353427
[format_png]: /images/20220518/2f251dd08579466a8e3fbb31c87d6232.png
[format_png 1]: /images/20220518/36e3674d3cd248eab3caa552997d0623.png
[format_png 2]: /images/20220518/52f7357fc3e341e28159dee42abb3722.png
[https_blog.csdn.net_qq_33314107_article_details_81712589]: https://blog.csdn.net/qq_33314107/article/details/81712589
[https_blog.csdn.net_cj2580_article_details_78124780]: https://blog.csdn.net/cj2580/article/details/78124780
[TCP]: http://blog.csdn.net/baiye_xing/article/details/73189191
[https_www.cnblogs.com_myJavaEE_p_6793332.html]: https://www.cnblogs.com/myJavaEE/p/6793332.html