(三) Netty

作者: 穿秋衣的李白 | 来源:发表于2020-09-14 09:57 被阅读0次

背景

通过选择合适的 NIO 框架，加上高性能的压缩二进制编解码技术，精心的设计 Reactor 线程模型，达到支持10W TPS的跨节点远程服务调用。

定义

Netty 是一个高性能、异步事件驱动的 NIO 框架，它提供了对 TCP、UDP 和文件传输的支持，作为一个异步 NIO 框架，Netty 的所有 IO 操作都是异步非阻塞的，通过 Future-Listener 机制，用户可以方便的主动获取或者通过通知机制获得 IO 操作结果。

NIO知识准备

缓冲区 Buffer：Buffer 是一个对象，它包含一些要写入或者要读出的数据。在 NIO 类库中加入 Buffer 对象，体现了新库与原 I/O 的一个重要区别。在面向流的 I/O 中，可以将数据直接写入或者将数据直接读到 Stream 对象中。在 NIO 库中，所有数据都是用缓冲区处理的。在读取数据时，它是直接读到缓冲区中的；在写入数据时，写入到缓冲区中。任何时候访问 NIO 中的数据，都是通过缓冲区进行操作。
缓冲区实质上是一个数组。通常它是一个字节数组（ByteBuffer），也可以使用其他种类的数组。但是一个缓冲区不仅仅是一个数组，缓冲区提供了对数据的结构化访问以及维护读写位置（limit）等信息。
最常用的缓冲区是 ByteBuffer，一个 ByteBuffer 提供了一组功能用于操作 byte 数组。比较常用的就是 get 和 put 系列方法。

通道 Channel：Channel 是一个通道，可以通过它读取和写入数据，它就像自来水管一样，网络数据通过 Channel 读取和写入。通道与流的不同之处在于通道是双向的，流只是在一个方向上移动（一个流必须是 InputStream 或者 OutputStream 的子类），而且通道可以用于读、写或者同时用于读写。因为 Channel 是全双工的，所以它可以比流更好地映射底层操作系统的 API。特别是在 UNIX 网络编程模型中，底层操作系统的通道都是全双工的，同时支持读写操作。比较常用的 Channel 是 SocketChannel 和 ServerSocketChannel。

多路复用器 Selector：Selector 是 Java NIO 编程的基础，熟练地掌握 Selector 对于掌握 NIO 编程至关重要。多路复用器提供选择已经就绪的任务的能力。简单来讲，Selector 会不断地轮询注册在其上的 Channel，如果某个 Channel 上面有新的 TCP 连接接入、读和写事件，这个 Channel 就处于就绪状态，会被 Selector 轮询出来，然后通过 SelectionKey 可以获取就绪 Channel 的集合，进行后续的 I/O 操作。

RPC调用的性能模型分析

传统 RPC 调用性能差的三宗罪

网络传输方式问题：传统的 RPC 框架或者基于 RMI 等方式的远程服务（过程）调用采用了同步阻塞 IO，当客户端的并发压力或者网络时延增大之后，同步阻塞 IO 会由于频繁的 wait 导致 IO 线程经常性的阻塞，由于线程无法高效的工作，IO 处理能力自然下降。

BIO通信模型
采用 BIO 通信模型的服务端，通常由一个独立的 Acceptor 线程负责监听客户端的连接，接收到客户端连接之后为客户端连接创建一个新的线程处理请求消息，处理完成之后，返回应答消息给客户端，线程销毁，这就是典型的一请求一应答模型。该架构最大的问题就是不具备弹性伸缩能力，当并发访问量增加后，服务端的线程个数和并发访问数成线性正比，由于线程是 JAVA 虚拟机非常宝贵的系统资源，当线程数膨胀之后，系统的性能急剧下降，随着并发量的继续增加，可能会发生句柄溢出、线程堆栈溢出等问题，并导致服务器最终宕机。
序列化方式问题：Java 序列化存在如下几个典型问题：

Java 序列化机制是 Java 内部的一种对象编解码技术，无法跨语言使用；例如对于异构系统之间的对接，Java 序列化后的码流需要能够通过其它语言反序列化成原始对象（副本），目前很难支持；
相比于其它开源的序列化框架，Java 序列化后的码流太大，无论是网络传输还是持久化到磁盘，都会导致额外的资源占用；
序列化性能差（CPU 资源占用高）。

线程模型问题：由于采用同步阻塞 IO，这会导致每个 TCP 连接都占用 1 个线程，由于线程资源是 JVM 虚拟机非常宝贵的资源，当 IO 读写阻塞导致线程无法及时释放时，会导致系统性能急剧下降，严重的甚至会导致虚拟机无法创建新的线程。

高性能的三大主题

传输：用什么样的通道将数据发送给对方，BIO、NIO 或者 AIO，IO 模型在很大程度上决定了框架的性能。
协议：采用什么样的通信协议，HTTP 或者内部私有协议。协议的选择不同，性能模型也不同。相比于公有协议，内部私有协议的性能通常可以被设计的更优。
线程：数据报如何读取？读取之后的编解码在哪个线程进行，编解码后的消息如何派发，Reactor 线程模型的不同，对性能的影响也非常大。

Netty 高性能之道

异步非阻塞IO

在 IO 编程过程中，当需要同时处理多个客户端接入请求时，可以利用多线程或者 IO 多路复用技术进行处理。IO 多路复用技术通过把多个 IO 的阻塞复用到同一个 select 的阻塞上，从而使得系统在单线程的情况下可以同时处理多个客户端请求。与传统的多线程 / 多进程模型比，I/O 多路复用的最大优势是系统开销小，系统不需要创建新的额外进程或者线程，也不需要维护这些进程和线程的运行，降低了系统的维护工作量，节省了系统资源。

JDK1.4 提供了对非阻塞 IO（NIO）的支持，JDK1.5_update10 版本使用 epoll 替代了传统的 select/poll，极大的提升了 NIO 通信的性能。

NIO多路复用模型

与 Socket 类和 ServerSocket 类相对应，NIO 也提供了 SocketChannel 和 ServerSocketChannel 两种不同的套接字通道实现。这两种新增的通道都支持阻塞和非阻塞两种模式。阻塞模式使用非常简单，但是性能和可靠性都不好，非阻塞模式正好相反。开发人员一般可以根据自己的需要来选择合适的模式，一般来说，低负载、低并发的应用程序可以选择同步阻塞 IO 以降低编程复杂度。但是对于高负载、高并发的网络应用，需要使用 NIO 的非阻塞模式进行开发。

Netty 架构按照 Reactor 模式设计和实现，它的服务端通信序列图如下：

NIO服务端通信序列
客户端通信序列图如下：

NIO客户端通信序列
总结：Netty 的 IO 线程 NioEventLoop 由于聚合了多路复用器 Selector，可以同时并发处理成百上千个客户端 Channel，由于读写操作都是非阻塞的，这就可以充分提升 IO 线程的运行效率，避免由于频繁 IO 阻塞导致的线程挂起。另外，由于 Netty 采用了异步通信模式，一个 IO 线程可以并发处理 N 个客户端连接和读写操作，这从根本上解决了传统同步阻塞 IO 一连接一线程模型，架构的性能、弹性伸缩能力和可靠性都得到了极大的提升。

零拷贝

Netty 的“零拷贝”主要体现在如下三个方面：

Netty 的接收和发送 ByteBuffer 采用 DIRECT BUFFERS，使用堆外直接内存进行 Socket 读写，不需要进行字节缓冲区的二次拷贝。如果使用传统的堆内存（HEAP BUFFERS）进行 Socket 读写，JVM 会将堆内存 Buffer 拷贝一份到直接内存中，然后才写入 Socket 中。相比于堆外直接内存，消息在发送过程中多了一次缓冲区的内存拷贝。
Netty 提供了组合 Buffer 对象，可以聚合多个 ByteBuffer 对象，用户可以像操作一个 Buffer 那样方便的对组合 Buffer 进行操作，避免了传统通过内存拷贝的方式将几个小 Buffer 合并成一个大的 Buffer。
Netty 的文件传输采用了 transferTo 方法，它可以直接将文件缓冲区的数据发送到目标 Channel，避免了传统通过循环 write 方式导致的内存拷贝问题。

下面，我们对上述三种“零拷贝”进行说明，先看 Netty 接收 Buffer 的创建：

异步消息读取“零拷贝”

每循环读取一次消息，就通过 ByteBufAllocator 的 ioBuffer 方法获取 ByteBuf 对象，下面继续看它的接口定义：

ByteBufAllocator 通过 ioBuffer 分配堆外内存
当进行 Socket IO 读写的时候，为了避免从堆内存拷贝一份副本到直接内存，Netty 的 ByteBuf 分配器直接创建非堆内存避免缓冲区的二次拷贝，通过“零拷贝”来提升读写性能。(简单来说就是使用堆外内存进行Socket读写，减少了一次堆内存拷贝到直接内存的操作)。

下面我们继续看第二种“零拷贝”的实现 CompositeByteBuf，它对外将多个 ByteBuf 封装成一个 ByteBuf，对外提供统一封装后的 ByteBuf 接口，它的类定义如下：

CompositeByteBuf 类继承关系

通过继承关系我们可以看出 CompositeByteBuf 实际就是个 ByteBuf 的包装器，它将多个 ByteBuf 组合成一个集合，然后对外提供统一的 ByteBuf 接口，相关定义如下：

CompositeByteBuf 类定义
添加 ByteBuf，不需要做内存拷贝，相关代码如下：

新增 ByteBuf 的“零拷贝”

最后，我们看下文件传输的“零拷贝”：

文件传输“零拷贝”
Netty 文件传输 DefaultFileRegion 通过 transferTo 方法将文件发送到目标 Channel 中，下面重点看 FileChannel 的 transferTo 方法，它的 API DOC 说明如下：

文件传输 “零拷贝”
对于很多操作系统它直接将文件缓冲区的内容发送到目标 Channel 中，而不需要通过拷贝的方式，这是一种更加高效的传输方式，它实现了文件传输的“零拷贝”。

内存池

随着 JVM 虚拟机和 JIT 即时编译技术的发展，对象的分配和回收是个非常轻量级的工作。但是对于缓冲区 Buffer，情况却稍有不同，特别是对于堆外直接内存的分配和回收，是一件耗时的操作。为了尽量重用缓冲区，Netty 提供了基于内存池的缓冲区重用机制。下面我们一起看下 Netty ByteBuf 的实现：

内存池 ByteBuf
Netty 提供了多种内存管理策略，通过在启动辅助类中配置相关参数，可以实现差异化的定制。
下面通过性能测试，我们看下基于内存池循环利用的 ByteBuf 和普通 ByteBuf 的性能差异。
用例一，使用内存池分配器创建直接内存缓冲区：

基于内存池的非堆内存缓冲区测试用例
用例二，使用非堆内存分配器创建的直接内存缓冲区：

基于非内存池创建的非堆内存缓冲区测试用例
各执行 300 万次，性能对比结果如下所示：性能测试表明，采用内存池的 ByteBuf 相比于朝生夕灭的 ByteBuf，性能高 23 倍左右（性能数据与使用场景强相关）。

内存池和非内存池缓冲区写入性能对比
下面我们一起简单分析下 Netty 内存池的内存分配：

AbstractByteBufAllocator 的缓冲区分配
继续看 newDirectBuffer 方法，我们发现它是一个抽象方法，由 AbstractByteBufAllocator 的子类负责具体实现，代码如下：

newDirectBuffer 的不同实现
代码跳转到 PooledByteBufAllocator 的 newDirectBuffer 方法，从 Cache 中获取内存区域 PoolArena，调用它的 allocate 方法进行内存分配：

PooledByteBufAllocator 的内存分配
PoolArena 的 allocate 方法如下

PoolArena 的缓冲区分配
我们重点分析 newByteBuf 的实现，它同样是个抽象方法，由子类 DirectArena 和 HeapArena 来实现不同类型的缓冲区分配，由于测试用例使用的是堆外内存，

PoolArena 的 newByteBuf 抽象方法
因此重点分析 DirectArena 的实现：如果没有开启使用 sun 的 unsafe，则

DirectArena 的 newByteBuf 方法实现
执行 PooledDirectByteBuf 的 newInstance 方法，代码如下：

PooledDirectByteBuf 的 newInstance 方法实现
通过 RECYCLER 的 get 方法循环使用 ByteBuf 对象，如果是非内存池实现，则直接创建一个新的 ByteBuf 对象。从缓冲池中获取 ByteBuf 之后，调用 AbstractReferenceCountedByteBuf 的 setRefCnt 方法设置引用计数器，用于对象的引用计数和内存回收（类似 JVM 垃圾回收机制）。

高效的 Reactor 线程模型

常用的 Reactor 线程模型有三种，Reactor 单线程模型；Reactor 多线程模型；主从 Reactor 多线程模型。
Reactor 单线程模型，指的是所有的 IO 操作都在同一个 NIO 线程上面完成，NIO 线程的职责如下：

作为 NIO 服务端，接收客户端的 TCP 连接；
作为 NIO 客户端，向服务端发起 TCP 连接；
读取通信对端的请求或者应答消息；
向通信对端发送消息请求或者应答消息。

Reactor 单线程模型示意图如下所示：

Reactor 单线程模型

由于 Reactor 模式使用的是异步非阻塞 IO，所有的 IO 操作都不会导致阻塞，理论上一个线程可以独立处理所有 IO 相关的操作。从架构层面看，一个 NIO 线程确实可以完成其承担的职责。例如，通过 Acceptor 接收客户端的 TCP 连接请求消息，链路建立成功之后，通过 Dispatch 将对应的 ByteBuffer 派发到指定的 Handler 上进行消息解码。用户 Handler 可以通过 NIO 线程将消息发送给客户端。

对于一些小容量应用场景，可以使用单线程模型。但是对于高负载、大并发的应用却不合适，主要原因如下：

一个 NIO 线程同时处理成百上千的链路，性能上无法支撑，即便 NIO 线程的 CPU 负荷达到 100%，也无法满足海量消息的编码、解码、读取和发送；
当 NIO 线程负载过重之后，处理速度将变慢，这会导致大量客户端连接超时，超时之后往往会进行重发，这更加重了 NIO 线程的负载，最终会导致大量消息积压和处理超时，NIO 线程会成为系统的性能瓶颈；
可靠性问题：一旦 NIO 线程意外跑飞，或者进入死循环，会导致整个系统通信模块不可用，不能接收和处理外部消息，造成节点故障。

为了解决这些问题，演进出了 Reactor 多线程模型，下面我们一起学习下 Reactor 多线程模型。

Rector 多线程模型与单线程模型最大的区别就是有一组 NIO 线程处理 IO 操作，它的原理图如下：

Reactor 多线程模型

有专门一个 NIO 线程 -Acceptor 线程用于监听服务端，接收客户端的 TCP 连接请求；
网络 IO 操作 - 读、写等由一个 NIO 线程池负责，线程池可以采用标准的 JDK 线程池实现，它包含一个任务队列和 N 个可用的线程，由这些 NIO 线程负责消息的读取、解码、编码和发送；
1 个 NIO 线程可以同时处理 N 条链路，但是 1 个链路只对应 1 个 NIO 线程，防止发生并发操作问题。

在绝大多数场景下，Reactor 多线程模型都可以满足性能需求；但是，在极特殊应用场景中，一个 NIO 线程负责监听和处理所有的客户端连接可能会存在性能问题。例如百万客户端并发连接，或者服务端需要对客户端的握手消息进行安全认证，认证本身非常损耗性能。在这类场景下，单独一个 Acceptor 线程可能会存在性能不足问题，为了解决性能问题，产生了第三种 Reactor 线程模型 - 主从 Reactor 多线程模型。

主从 Reactor 线程模型的特点是：服务端用于接收客户端连接的不再是个 1 个单独的 NIO 线程，而是一个独立的 NIO 线程池。Acceptor 接收到客户端 TCP 连接请求处理完成后（可能包含接入认证等），将新创建的 SocketChannel 注册到 IO 线程池（sub reactor 线程池）的某个 IO 线程上，由它负责 SocketChannel 的读写和编解码工作。Acceptor 线程池仅仅只用于客户端的登陆、握手和安全认证，一旦链路建立成功，就将链路注册到后端 subReactor 线程池的 IO 线程上，由 IO 线程负责后续的 IO 操作。它的线程模型如下图所示：

Reactor 主从多线程模型

利用主从 NIO 线程模型，可以解决 1 个服务端监听线程无法有效处理所有客户端连接的性能不足问题。因此，在 Netty 的官方 demo 中，推荐使用该线程模型。

事实上，Netty 的线程模型并非固定不变，通过在启动辅助类中创建不同的 EventLoopGroup 实例并通过适当的参数配置，就可以支持上述三种 Reactor 线程模型。正是因为 Netty 对 Reactor 线程模型的支持提供了灵活的定制能力，所以可以满足不同业务场景的性能诉求。

无锁化的串行设计理念

在大多数场景下，并行多线程处理可以提升系统的并发性能。但是，如果对于共享资源的并发访问处理不当，会带来严重的锁竞争，这最终会导致性能的下降。为了尽可能的避免锁竞争带来的性能损耗，可以通过串行化设计，即消息的处理尽可能在同一个线程内完成，期间不进行线程切换，这样就避免了多线程竞争和同步锁。

为了尽可能提升性能，Netty 采用了串行无锁化设计，在 IO 线程内部进行串行操作，避免多线程竞争导致的性能下降。表面上看，串行化设计似乎 CPU 利用率不高，并发程度不够。但是，通过调整 NIO 线程池的线程参数，可以同时启动多个串行化的线程并行运行，这种局部无锁化的串行线程设计相比一个队列 - 多个工作线程模型性能更优。

Netty 的串行化设计工作原理图如下

Netty 串行化工作原理图

Netty 的 NioEventLoop 读取到消息之后，直接调用 ChannelPipeline 的 fireChannelRead(Object msg)，只要用户不主动切换线程，一直会由 NioEventLoop 调用到用户的 Handler，期间不进行线程切换，这种串行化处理方式避免了多线程操作导致的锁的竞争，从性能角度看是最优的。

高效的并发编程

Netty 的高效并发编程主要体现在如下几点：

volatile 的大量、正确使用 ;
CAS 和原子类的广泛使用；
线程安全容器的使用；
通过读写锁提升并发性能。

详见https://blog.csdn.net/weixin_42322850/article/details/89892596

高性能的序列化框架

影响序列化性能的关键因素总结如下：

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

Netty 默认提供了对 Google Protobuf 的支持（Protobuf 序列化后的码流只有 Java 序列化的 1/4 左右），通过扩展 Netty 的编解码接口，用户可以实现其它的高性能序列化框架，例如 Thrift 的压缩二进制编解码框架。

灵活的 TCP 参数配置能力

合理设置 TCP 参数在某些场景下对于性能的提升可以起到显著的效果，例如 SO_RCVBUF 和 SO_SNDBUF。如果设置不当，对性能的影响是非常大的。下面我们总结下对性能影响比较大的几个配置项：

SO_RCVBUF 和 SO_SNDBUF：通常建议值为 128K 或者 256K；
SO_TCPNODELAY：NAGLE 算法通过将缓冲区内的小封包自动相连，组成较大的封包，阻止大量小封包的发送阻塞网络，从而提高网络应用效率。但是对于时延敏感的应用场景需要关闭该优化算法；
软中断：如果 Linux 内核版本支持 RPS（2.6.35 以上版本），开启 RPS 后可以实现软中断，提升网络吞吐量。RPS 根据数据包的源地址，目的地址以及目的和源端口，计算出一个 hash 值，然后根据这个 hash 值来选择软中断运行的 cpu，从上层来看，也就是说将每个连接和 cpu 绑定，并通过这个 hash 值，来均衡软中断在多个 cpu 上，提升网络并行处理性能。

Netty 在启动辅助类中可以灵活的配置 TCP 参数，满足不同的用户场景。相关配置接口定义如下：

Netty 的 TCP 参数配置定义

Netty关键类库

Netty 的核心类库可以分为 5 大类：
1、ByteBuf 和相关辅助类：ByteBuf 是个 Byte 数组的缓冲区，它的基本功能应该与 JDK 的 ByteBuffer 一致，提供以下几类基本功能：

7 种 Java 基础类型、byte 数组、ByteBuffer（ByteBuf）等的读写。
缓冲区自身的 copy 和 slice 等。
设置网络字节序。
构造缓冲区实例。
操作位置指针等方法。
动态的扩展和收缩。

从内存分配的角度看，ByteBuf 可以分为两类：堆内存（HeapByteBuf）字节缓冲区：特点是内存的分配和回收速度快，可以被 JVM 自动回收；缺点就是如果进行 Socket 的 I/O 读写，需要额外做一次内存复制，将堆内存对应的缓冲区复制到内核 Channel 中，性能会有一定程度的下降。直接内存（DirectByteBuf）字节缓冲区：非堆内存，它在堆外进行内存分配，相比于堆内存，它的分配和回收速度会慢一些，但是将它写入或者从 Socket Channel 中读取时，由于少了一次内存复制，速度比堆内存快。
2、Channel 和 Unsafe：io.netty.channel.Channel 是 Netty 网络操作抽象类，它聚合了一组功能，包括但不限于网路的读、写，客户端发起连接、主动关闭连接，链路关闭，获取通信双方的网络地址等。它也包含了 Netty 框架相关的一些功能，包括获取该 Chanel 的 EventLoop，获取缓冲分配器 ByteBufAllocator 和 pipeline 等。Unsafe 是个内部接口，聚合在 Channel 中协助进行网络读写相关的操作，它提供的主要功能如下表所示：

Unsafe API 功能列表
3、ChannelPipeline 和 ChannelHandler: Netty 的 ChannelPipeline 和 ChannelHandler 机制类似于 Servlet 和 Filter 过滤器，这类拦截器实际上是职责链模式的一种变形，主要是为了方便事件的拦截和用户业务逻辑的定制。Servlet Filter 是 JEE Web 应用程序级的 Java 代码组件，它能够以声明的方式插入到 HTTP 请求响应的处理过程中，用于拦截请求和响应，以便能够查看、提取或以某种方式操作正在客户端和服务器之间交换的数据。

拦截器封装了业务定制逻辑，能够实现对 Web 应用程序的预处理和事后处理。过滤器提供了一种面向对象的模块化机制，用来将公共任务封装到可插入的组件中。

这些组件通过 Web 部署配置文件（web.xml）进行声明，可以方便地添加和删除过滤器，无须改动任何应用程序代码或 JSP 页面，由 Servlet 进行动态调用。通过在请求 / 响应链中使用过滤器，可以对应用程序（而不是以任何方式替代）的 Servlet 或 JSP 页面提供的核心处理进行补充，而不破坏 Servlet 或 JSP 页面的功能。由于是纯 Java 实现，所以 Servlet 过滤器具有跨平台的可重用性，使得它们很容易地被部署到任何符合 Servlet 规范的 JEE 环境中。

Netty 的 Channel 过滤器实现原理与 Servlet Filter 机制一致，它将 Channel 的数据管道抽象为 ChannelPipeline，消息在 ChannelPipeline 中流动和传递。ChannelPipeline 持有 I/O 事件拦截器 ChannelHandler 的链表，由 ChannelHandler 对 I/O 事件进行拦截和处理，可以方便地通过新增和删除 ChannelHandler 来实现不同的业务逻辑定制，不需要对已有的 ChannelHandler 进行修改，能够实现对修改封闭和对扩展的支持。ChannelPipeline 是 ChannelHandler 的容器，它负责 ChannelHandler 的管理和事件拦截与调度：

ChannelPipeline 对事件流的拦截和处理流

Netty 中的事件分为 inbound 事件和 outbound 事件。inbound 事件通常由 I/O 线程触发，例如 TCP 链路建立事件、链路关闭事件、读事件、异常通知事件等。

Outbound 事件通常是由用户主动发起的网络 I/O 操作，例如用户发起的连接操作、绑定操作、消息发送等操作。ChannelHandler 类似于 Servlet 的 Filter 过滤器，负责对 I/O 事件或者 I/O 操作进行拦截和处理，它可以选择性地拦截和处理自己感兴趣的事件，也可以透传和终止事件的传递。基于 ChannelHandler 接口，用户可以方便地进行业务逻辑定制，例如打印日志、统一封装异常信息、性能统计和消息编解码等。

4、EventLoop：Netty 的 NioEventLoop 并不是一个纯粹的 I/O 线程，它除了负责 I/O 的读写之外，还兼顾处理以下两类任务：

普通 Task：通过调用 NioEventLoop 的 execute(Runnable task) 方法实现，Netty 有很多系统 Task，创建它们的主要原因是：当 I/O 线程和用户线程同时操作网络资源时，为了防止并发操作导致的锁竞争，将用户线程的操作封装成 Task 放入消息队列中，由 I/O 线程负责执行，这样就实现了局部无锁化。
定时任务：通过调用 NioEventLoop 的 schedule(Runnable command, long delay, TimeUnit unit) 方法实现。

Netty 的线程模型并不是一成不变的，它实际取决于用户的启动参数配置。通过设置不同的启动参数，Netty 可以同时支持 Reactor 单线程模型、多线程模型和主从 Reactor 多线层模型。它的工作原理如下所示：

Netty 的线程模型

通过调整线程池的线程个数、是否共享线程池等方式，Netty 的 Reactor 线程模型可以在单线程、多线程和主从多线程间切换，这种灵活的配置方式可以最大程度地满足不同用户的个性化定制。

为了尽可能地提升性能，Netty 在很多地方进行了无锁化的设计，例如在 I/O 线程内部进行串行操作，避免多线程竞争导致的性能下降问题。表面上看，串行化设计似乎 CPU 利用率不高，并发程度不够。但是，通过调整 NIO 线程池的线程参数，可以同时启动多个串行化的线程并行运行，这种局部无锁化的串行线程设计相比一个队列—多个工作线程的模型性能更优。它的设计原理如下图所示：

NioEventLoop 串行执行 ChannelHandler
5、Future 和 Promise：在 Netty 中，所有的 I/O 操作都是异步的，这意味着任何 I/O 调用都会立即返回，而不是像传统 BIO 那样同步等待操作完成。异步操作会带来一个问题：调用者如何获取异步操作的结果？ ChannelFuture 就是为了解决这个问题而专门设计的。下面我们一起看它的原理。ChannelFuture 有两种状态：uncompleted 和 completed。当开始一个 I/O 操作时，一个新的 ChannelFuture 被创建，此时它处于 uncompleted 状态——非失败、非成功、非取消，因为 I/O 操作此时还没有完成。一旦 I/O 操作完成，ChannelFuture 将会被设置成 completed，它的结果有如下三种可能：

操作成功。
操作失败。
操作被取消。

ChannelFuture 的状态迁移图如下所示：

ChannelFuture 状态迁移图

Promise 是可写的 Future，Future 自身并没有写操作相关的接口，Netty 通过 Promise 对 Future 进行扩展，用于设置 I/O 操作的结果，它的接口定义如下：

Netty 的 Promise 接口定义

Netty关键流程

重点掌握 Netty 服务端和客户端的创建，以及创建过程中使用到的核心类库和 API、以及消息的发送和接收、消息的编解码。
Netty 服务端创建流程如下：

Netty 服务端创建流程

Netty 客户端创建流程如下：

Netty 客户端创建流程

Netty项目实战

如果项目中需要用到 Netty，则直接在项目中应用，通过实践来不断提升对 Netty 的理解和掌握。如果暂时使用不到，则可以通过学习一些开源的 RPC 或者服务框架，看这些框架是怎么集成并使用 Netty 的。以 gRPC Java 版为例，我们一起看下 gRPC 是如何使用 Netty 的。

gRPC 服务端

gRPC 通过对 Netty HTTP/2 的封装，向用户屏蔽底层 RPC 通信的协议细节，Netty HTTP/2 服务端的创建流程如下：

Netty HTTP/2 服务端创建流程

服务端 HTTP/2 消息的读写主要通过 gRPC 的 NettyServerHandler 实现，它的类继承关系如下所示：

gRPC NettyServerHandler 类继承关系
从类继承关系可以看出，NettyServerHandler 主要负责 HTTP/2 协议消息相关的处理，例如 HTTP/2 请求消息体和消息头的读取、Frame 消息的发送、Stream 状态消息的处理等，相关接口定义如下：

NettyServerHandler 处理 HTTP/2 协议消息相关接口

gRPC 客户端

gRPC 的客户端调用主要包括基于 Netty 的 HTTP/2 客户端创建、客户端负载均衡、请求消息的发送和响应接收处理四个流程,gRPC 的客户端调用总体流程如下图所示:

gRPC 客户端总体调用流程

gRPC 的客户端调用流程如下：

客户端 Stub(GreeterBlockingStub) 调用 sayHello(request)，发起 RPC 调用。
通过 DnsNameResolver 进行域名解析，获取服务端的地址信息（列表），随后使用默认的 LoadBalancer 策略，选择一个具体的 gRPC 服务端实例。
如果与路由选中的服务端之间没有可用的连接，则创建 NettyClientTransport 和 NettyClientHandler，发起 HTTP/2 连接。
对请求消息使用 PB（Protobuf）做序列化，通过 HTTP/2 Stream 发送给 gRPC 服务端。
接收到服务端响应之后，使用 PB（Protobuf）做反序列化。
回调 GrpcFuture 的 set(Response) 方法，唤醒阻塞的客户端调用线程，获取 RPC 响应。

需要指出的是，客户端同步阻塞 RPC 调用阻塞的是调用方线程（通常是业务线程），底层 Transport 的 I/O 线程（Netty 的 NioEventLoop）仍然是非阻塞的。

线程模型

gRPC 服务端线程模型整体上可以分为两大类：
1. 网络通信相关的线程模型，基于 Netty4.1 的线程模型实现。
2. 服务接口调用线程模型，基于 JDK 线程池实现。
gRPC 服务端线程模型和交互图如下所示：

gRPC 服务端线程模型

其中，HTTP/2 服务端创建、HTTP/2 请求消息的接入和响应发送都由 Netty 负责，gRPC 消息的序列化和反序列化、以及应用服务接口的调用由 gRPC 的 SerializingExecutor 线程池负责。

gRPC 客户端的线程主要分为三类：

业务调用线程
客户端连接和 I/O 读写线程
请求消息业务处理和响应回调线程

gRPC 客户端线程模型工作原理如下图所示（同步阻塞调用为例）：

客户端调用线程模型

客户端调用主要涉及的线程包括：

应用线程，负责调用 gRPC 服务端并获取响应，其中请求消息的序列化由该线程负责。
客户端负载均衡以及 Netty Client 创建，由 grpc-default-executor 线程池负责。
HTTP/2 客户端链路创建、网络 I/O 数据的读写，由 Netty NioEventLoop 线程负责。
响应消息的反序列化由 SerializingExecutor 负责，与服务端不同的是，客户端使用的是 ThreadlessExecutor，并非 JDK 线程池。
SerializingExecutor 通过调用 responseFuture 的 set(value)，唤醒阻塞的应用线程，完成一次 RPC 调用。

gRPC 采用的是网络 I/O 线程和业务调用线程分离的策略，大部分场景下该策略是最优的。但是，对于那些接口逻辑非常简单，执行时间很短，不需要与外部网元交互、访问数据库和磁盘，也不需要等待其它资源的，则建议接口调用直接在 Netty /O 线程中执行，不需要再投递到后端的服务线程池。避免线程上下文切换，同时也消除了线程并发问题。

例如提供配置项或者接口，系统默认将消息投递到后端服务调度线程，但是也支持短路策略，直接在 Netty 的 NioEventLoop 中执行消息的序列化和反序列化、以及服务接口调用。

减少锁竞争优化：当前 gRPC 的线程切换策略如下：

gRPC 线程锁竞争

优化之后的 gRPC 线程切换策略：

gRPC 线程锁竞争优化
通过线程绑定技术（例如采用一致性 hash 做映射）, 将 Netty 的 I/O 线程与后端的服务调度线程做绑定，1 个 I/O 线程绑定一个或者多个服务调用线程，降低锁竞争，提升性能。

Netty 故障定位技巧

接收不到消息

如果业务的 ChannelHandler 接收不到消息，可能的原因如下：

业务的解码 ChannelHandler 存在 BUG，导致消息解码失败，没有投递到后端。
业务发送的是畸形或者错误码流（例如长度错误），导致业务解码 ChannelHandler 无法正确解码出业务消息。
业务 ChannelHandler 执行了一些耗时或者阻塞操作，导致 Netty 的 NioEventLoop 被挂住，无法读取消息。
执行业务 ChannelHandler 的线程池队列积压，导致新接收的消息在排队，没有得到及时处理。
对方确实没有发送消息。

定位策略如下：

在业务的首个 ChannelHandler 的 channelRead 方法中打断点调试，看是否读取到消息。
在 ChannelHandler 中添加 LoggingHandler，打印接口日志。
查看 NioEventLoop 线程状态，看是否发生了阻塞。
通过 tcpdump 抓包看消息是否发送成功。

内存泄漏

通过 jmap -dump:format=b,file=xx pid 命令 Dump 内存堆栈，然后使用 MemoryAnalyzer 工具对内存占用进行分析，查找内存泄漏点，然后结合代码进行分析，定位内存泄漏的具体原因，示例如下所示：

通过 MemoryAnalyzer 工具分析内存堆栈

性能问题如果出现性能问题，首先需要确认是 Netty 问题还是业务问题，通过 jstack 命令或者 jvisualvm 工具打印线程堆栈，按照线程 CPU 使用率进行排序（top -Hp 命令采集），看线程在忙什么。通常如果采集几次都发现 Netty 的 NIO 线程堆栈停留在 select 操作上，说明 I/O 比较空闲，性能瓶颈不在 Netty，需要继续分析看是否是后端的业务处理线程存在性能瓶颈:

Netty NIO 线程运行堆栈
如果发现性能瓶颈在网络 I/O 读写上，可以适当调大 NioEventLoopGroup 中的 work I/O 线程数，直到 I/O 处理性能能够满足业务需求。

注：本文转载自林雪峰的《Netty 系列之 Netty 高性能之道》与《Netty 学习和进阶策略》