Netty原理-EW帮帮网

Netty 3.x： 早期版本，API 与 4.x 差异较大，已不再推荐使用。
Netty 4.x： 当前主流稳定版本。API 经过重新设计，性能、稳定性和易用性大幅提升。广泛用于生产环境。
Netty 5.x： 曾经开发过，旨在引入一些新特性（如 ForkJoinPool），但由于性能提升不明显且引入复杂性，官方已放弃 5.x 分支。主要精力集中在维护和改进 4.x。
Netty 5 (重启)： 社区近期有重启 Netty 5 开发的讨论，目标是更好地支持 Java 21+（如虚拟线程、结构化并发），但目前仍在非常早期的孵化阶段。生产环境应首选 Netty 4.x。

2、核心价值与解决的问题

简化 NIO 开发： Java 原生 NIO API 非常复杂且容易出错（如 Selector 管理、ByteBuffer 处理、线程模型）。Netty 提供了更高层次的抽象，封装了这些复杂性。

原生NIO存在的问题：

1> NIO 的类库和 API 繁杂，使用麻烦：需要熟练掌握 Selector、ServerSocketChannel、SocketChannel、ByteBuffer等。
2> 需要具备其他的额外技能：要熟悉 Java 多线程编程，因为 NIO 编程涉及到 Reactor 模式，必须对多线程和网络编程非常熟悉，才能编写出高质量的 NIO 程序。
3> 开发工作量和难度都非常大：例如客户端面临断连重连、网络闪断、半包读写、失败缓存、网络拥塞和异常流的处理等等。

高性能： 精心设计的线程模型（Reactor 模式）、零拷贝、内存池化、无锁设计等特性，使其在网络 I/O 密集型应用中性能卓越，通常优于原生 Java NIO 和传统的阻塞 I/O (BIO)。
高可扩展性： 模块化、事件驱动的设计使其非常容易添加或修改协议、编解码逻辑、处理流程。
健壮性： 处理了很多网络编程中的边缘情况（如连接重置、慢客户端、资源泄露风险），提高了应用的稳定性。
社区与生态： 拥有庞大的用户群和活跃的社区，被众多知名项目（如 Dubbo、gRPC-Java、Spark、Elasticsearch、Cassandra、RocketMQ、Zookeeper、Play Framework 等）广泛采用，意味着有丰富的经验和资源可用。

3、核心组件

Netty 的核心基于 Reactor 线程模型（通常是主从多线程 Reactor 模型）和 ChannelPipeline 责任链模式。

3.1 Bootstrap / ServerBootstrap

启动 Netty 应用的引导类。Bootstrap 用于客户端，ServerBootstrap 用于服务器端。
负责组装和配置其他核心组件（EventLoopGroup、Channel、ChannelHandler 等），并最终绑定端口（服务器）或连接（客户端）。

3.2 EventLoopGroup（选择器池） / EventLoop（选择器）

EventLoopGroup： 本质是一个线程池（通常是 NioEventLoopGroup），包含一个或多个 EventLoop。服务器端通常配置两个：bossGroup 负责接受新连接，workerGroup 负责处理已接受连接的 I/O 操作
EventLoop： 事件循环的核心抽象。每个 EventLoop 绑定一个特定的线程，在其生命周期内负责处理注册在其上的所有 Channel 的 I/O 事件（读、写、连接、异常等）和执行提交到它上面的所有任务（Runnable）。一个 Channel 在其生命周期内只由一个 EventLoop（及其绑定的线程）处理，避免了并发问题。 这是 Netty 高性能和线程安全的关键。

3.3 Channel（Socket）

网络连接的抽象（如 NioSocketChannel 对应 TCP 连接，NioDatagramChannel 对应 UDP 连接）。代表一个打开的连接（如 Socket）或一个可以绑定/连接的实体。
提供了基本的网络操作（bind, connect, read, write, close, register）和获取网络配置状态的方法。
所有 I/O 操作都是异步的，立即返回一个 ChannelFuture，用于注册监听器获取操作结果。
ChannelOption：在创建 Channel 实例后,一般都需要设置 ChannelOption 参数。ChannelOption 是 Socket 的标准参数，而非 Netty 独创的。常用的参数配置有：
- ChannelOption.SO_BACKLOG：对应 TCP/IP 协议 listen 函数中的 backlog 参数，用来初始化服务器可连接队列大小。服务端处理客户端连接请求是顺序处理的，所以同一时间只能处理一个客户端连接。多个客户端来的时候，服务端将不能处理的客户端连接请求放在队列中等待处理，backlog 参数指定了队列的大小。
- ChannelOption.SO_KEEPALIVE ：一直保持连接活动状态。该参数用于设置TCP连接，当设置该选项以后，连接会测试链接的状态，这个选项用于可能长时间没有数据交流的连接。当设置该选项以后，如果在两小时内没有数据的通信时，TCP会自动发送一个活动探测数据报文。

3.4 ChannelFuture / ChannelPromise

代表一个异步 I/O 操作的结果。Netty 中几乎所有操作都是异步的，操作调用会立即返回一个 ChannelFuture。
可以添加 ChannelFutureListener 来监听操作完成（成功、失败或取消），并在完成时得到通知或执行回调逻辑。
ChannelPromise 是一个可写的 ChannelFuture，用于设置操作结果。

3.5 ChannelHandler（业务处理者）

处理 I/O 事件（如数据到达、连接建立、异常发生）或拦截 I/O 操作的核心业务逻辑组件。开发者主要扩展或使用各种 ChannelHandler 来实现应用逻辑。ChannelHandler 接口定义了许多事件处理的方法，我们可以通过重写这些方法去实现具体的业务逻辑。

常见的子接口/实现类：
- ChannelInboundHandler：处理入站事件（数据从网络到应用，如 channelRead, channelActive, exceptionCaught）。
- ChannelOutboundHandler：处理出站事件（数据从应用到网络，如 write, bind, connect）。
- ChannelDuplexHandler：同时处理入站和出站事件。
- SimpleChannelInboundHandler：简化了对特定类型消息处理的 ChannelInboundHandlerAdapter。
- ByteToMessageDecoder / MessageToByteEncoder：常用的编解码基类，处理字节与消息对象的转换。
- HttpObjectAggregator, HttpRequestDecoder, HttpResponseEncoder： HTTP 协议相关的 Handler。

3.6 ChannelPipeline（管道）

一个 ChannelHandler 实例组成的责任链，是一个Handler的集合。每个 Channel 创建时都会分配一个唯一的 ChannelPipeline。
所有进入（入站）或离开（出站） Channel 的事件都会流经这个管道。
管道中的 ChannelHandler 按添加顺序依次处理事件。入站事件从头（head）到尾（tail）传递，出站事件从尾到头传递。每个 Handler 可以决定是否将事件传递给下一个 Handler。
开发者通过添加、移除或替换 ChannelHandler 来动态改变处理逻辑，实现高度灵活性和可扩展性。

3.7 ChannelHandlerContext

代表了 ChannelHandler 和 ChannelPipeline 之间的绑定关系。它是 ChannelHandler 与 Pipeline 交互的接口。
通过 ChannelHandlerContext，Handler 可以：
- 触发事件（入站或出站）传递给 Pipeline 中的下一个 Handler (fireChannelRead(), write())。
- 访问关联的 Channel 和 EventLoop。
- 管理 Handler 的状态（如 @Sharable 注解的使用）。
通常建议通过 ChannelHandlerContext 来操作（如 ctx.write()），而不是直接通过 Channel (channel.write())，因为前者能确保事件在正确的上下文中传播（尤其是出站操作）。

3.8 ByteBuf（缓冲区）

Netty 提供的高性能、可扩展的字节缓冲区，是 java.nio.ByteBuffer 的卓越替代品。
关键优势：
- 池化： 支持对象池（默认启用），显著减少 GC 压力和内存分配成本，提升性能。
- 复合缓冲区： 通过 CompositeByteBuf 透明地将多个 ByteBuf 组合成一个逻辑视图，避免不必要的内存拷贝（零拷贝）。
- 灵活的 API： 读写索引分离、丰富的操作（查找、比较、切片、复制）、引用计数（需要手动管理释放）。
- 直接内存支持： 可以直接在 JVM 堆外分配内存（ByteBufAllocator.directBuffer()），避免数据在 JVM 堆和系统内存间拷贝，进一步提升 I/O 效率（但需注意管理释放）。

4、核心架构：Reactor模式

4.1 单Reactor单线程模型

Selector是可以实现应用程序通过一个阻塞对象监听多路连接请求
Reactor 对象通过 Selector监控客户端请求事件，收到事件后通过 Dispatch 进行分发
是建立连接请求事件，则由 Acceptor 通过 Accept 处理连接请求，然后创建一个 Handler 对象处理连接完成后的后续业务处理
Handler 会完成 Read→业务处理→Send 的完整业务流程

优点：模型简单，没有多线程、进程通信、竞争的问题，全部都在一个线程中完成

缺点：

性能问题: 只有一个线程，无法完全发挥多核 CPU 的性能。Handler 在处理某个连接上的业务时，整个进程无法处理其他连接事件，很容易导致性能瓶颈
可靠性问题: 线程意外终止或者进入死循环，会导致整个系统通信模块不可用，不能接收和处理外部消息，造成节点故障

4.2 单Reactor多线程模型

Reactor 对象通过 selector 监控客户端请求事件, 收到事件后，通过 dispatch 进行分发
- 如果建立连接请求, 则由 Acceptor 通过accept 处理连接请求
- 如果不是连接请求，则由 reactor 分发调用连接对应的 handler 来处理
handler 只负责响应事件，不做具体的业务处理, 通过 read 读取数据后，会分发给后面的worker 线程池的某个线程处理业务
worker 线程池会分配独立线程完成真正的业务，并将结果返回给 handler
handler 收到响应后，通过 send 将结果返回给 client

优点:可以充分的利用多核 cpu 的处理能力
缺点:多线程数据共享和访问比较复杂， reactor 处理所有的事件的监听和响应，在单线程运行，在高并发场景容易出现性能瓶颈

4.3 主从Reactor多线程模型

Reactor 主线程 MainReactor 对象通过 select 监听客户端连接事件，收到事件后，通过Acceptor 处理客户端连接事件
当 Acceptor 处理完客户端连接事件之后（与客户端建立好 Socket 连接），MainReactor 将连接分配给 SubReactor。（即：MainReactor 只负责监听客户端连接请求，和客户端建立连接之后将连接交由 SubReactor 监听后面的 IO 事件。)
SubReactor 将连接加入到自己的连接队列进行监听，并创建 Handler 对各种事件进行处理
当连接上有新事件发生的时候，SubReactor 就会调用对应的 Handler 处理
Handler 通过 read 从连接上读取请求数据，将请求数据分发给 Worker 线程池进行业务处理
Worker 线程池会分配独立线程来完成真正的业务处理，并将处理结果返回给 Handler。Handler 通过 send 向客户端发送响应数据
一个 MainReactor 可以对应多个 SubReactor，即一个 MainReactor 线程可以对应多个SubReactor 线程

优点：

MainReactor 线程与 SubReactor 线程的数据交互简单职责明确，MainReactor 线程只需要接收新连接，SubReactor 线程完成后续的业务处理
MainReactor 线程与 SubReactor 线程的数据交互简单， MainReactor 线程只需要把新连接传给 SubReactor 线程，SubReactor 线程无需返回数据
多个 SubReactor 线程能够应对更高的并发请求

缺点：

这种模式的缺点是编程复杂度较高。但是由于其优点明显，在许多项目中被广泛使用，包括Nginx、Memcached、Netty 等。这种模式也被叫做服务器的 1+M+N 线程模式，即使用该模式开发的服务器包含一个（或多个，1 只是表示相对较少）连接建立线程+M 个 IO 线程+N 个业务处理线程。这是业界成熟的服务器程序设计模式

4.4 Netty的主从Reactor模型

Netty抽象出两组线程池：BossGroup、WorkerGroup

1> Boss EventLoopGroup

负责监听和接收客户端连接（OP_ACCEPT 事件）。
每个 EventLoop 绑定一个端口，通过 Selector 轮询新连接。
连接建立后，将其注册到 Worker EventLoopGroup。
每个BossEventLoop中循环执行的步骤
- select：轮训注册在其上的 ServerSocketChannel 的 accept 事件（OP_ACCEPT 事件）
- processSelectedKeys：处理 accept 事件，与客户端建立连接，生成一个SocketChannel，并将其注册到某个 WorkerEventLoop 上的 Selector 上
- runAllTasks：再去以此循环处理任务队列中的其他任务

2> Worker EventLoopGroup

处理已建立连接的 I/O 操作（OP_READ/OP_WRITE 事件）。
每个 EventLoop 绑定多个 Channel（连接），处理其所有 I/O 事件。
每个WorkerEventLoop中循环执行的步骤
- select：轮训注册在其上的 SocketChannel 的 read/write 事件（OP_READ/OP_WRITE 事件）
- processSelectedKeys：在对应的 SocketChannel 上处理 read/write 事件，这里会使用 Pipeline（管道），Pipeline 中引用了Channel，即通过 Pipeline 可以获取到对应的 Channel，Pipeline 中维护了很多的处理器（拦截处理器、过滤处理器、自定义处理器等）。
- runAllTasks：再去以此循环处理任务队列中的其他任务

5、核心特性

异步非阻塞： 基于事件驱动模型，利用少量线程高效处理大量并发连接。
零拷贝：
- 使用 FileRegion 和 CompositeByteBuf 等技术，在网络传输中尽可能减少数据在用户空间和内核空间之间的拷贝次数。
- 使用直接内存 (DirectByteBuf) 避免数据在 JVM 堆和系统内存间拷贝。
内存管理：
- 强大的 ByteBuf 及其池化分配器 (PooledByteBufAllocator)。
- 精确的引用计数机制（需要开发者配合正确调用 retain()/release()），确保资源及时释放。
灵活的线程模型： 支持多种 Reactor 模式变体（单线程、多线程、主从多线程），通过配置 EventLoopGroup 即可实现。
丰富的协议支持： 内置了大量常见协议的编解码器（HTTP/1.1, HTTP/2, WebSocket, SSL/TLS, Protobuf, Thrift, MQTT, Redis, DNS 等），开箱即用。
高可扩展性： 基于 ChannelPipeline 和 ChannelHandler 的责任链模式，方便添加、移除、替换处理逻辑。

6、应用场景

高性能 RPC 框架通信层： Dubbo, gRPC-Java, Apache Thrift, Finagle 等。
消息中间件通信层： RocketMQ, Kafka (早期版本), ActiveMQ Artemis 等。
HTTP/WebSocket 服务器： 构建高性能 API Gateway、实时推送服务、游戏服务器。
分布式系统组件通信： ZooKeeper, Elasticsearch, Cassandra, HBase 等。
游戏服务器网络层： 处理大量玩家并发连接和实时交互。
物联网 (IoT) 平台接入层： 处理海量设备连接和数据传输。
代理服务器： 高性能反向代理、负载均衡器。

Netty原理

1、概念