Netty 核心专题

• 主从 Reactor 模型
• Boss/Worker 分工
• Channel 绑定单一 EventLoop

Netty 采用主从 Reactor 模型：Boss EventLoopGroup 负责监听端口、接受连接（accept），把新连接注册到 Worker EventLoopGroup；Worker EventLoopGroup 负责处理已连接 Channel 的读写事件与业务调度。一个 Channel 在其生命周期内绑定到单一的 EventLoop（一个线程），该 Channel 的所有 IO 事件和 handler 都在这个 EventLoop 上串行执行，天然避免并发竞争、无需加锁。意义：单一 EventLoop 保证 Channel 的事件处理线程安全（无锁串行），简化 handler 编写；EventLoop 复用连接（一个线程处理多个 Channel），减少线程数。Boss 只管 accept，Worker 管读写，职责分离。

主从 Reactor 把"接受连接"与"处理读写"分离到不同线程组。Channel 绑定单一 EventLoop 获得"无锁串行"的线程安全，细节是 Netty 高性能与简洁的关键。

• TCP 粘包拆包
• 解码器
• 适用场景

TCP 面向字节流，无消息边界，可能出现粘包（多消息合并）与拆包（消息被拆）。Netty 用解码器按帧还原消息：FixedLengthFrameDecoder（定长，每条消息固定长度，适合固定长度协议）；DelimiterBasedFrameDecoder（分隔符，按指定分隔符切分，适合文本协议如自定义分隔）；LineBasedFrameDecoder（行解码，按 \n 切分，适合按行文本协议）；LengthFieldBasedFrameDecoder（长度字段，按长度字段提取，适合二进制协议，最常用）。选型看协议：定长用 FixedLength，文本行用 LineBased，自定义分隔用 Delimiter，二进制带长度用 LengthFieldBased。长度字段解码器最通用。

粘包拆包是"字节流无边界"问题，解码器按帧还原。选型取决于协议格式（定长/分隔/长度字段），LengthFieldBasedFrameDecoder 是二进制协议的标准方案。

• ChannelPipeline 责任链
• 入站/出站顺序
• @Sharable

ChannelPipeline 是 ChannelHandler 的责任链，入站事件（Inbound，如 read、channelActive）从头部 handler 沿链向后传播，出站事件（Outbound，如 write、connect）从尾部 handler 沿链向前传播。每个 handler 处理事件后调用 ctx.fireChannelRead/ctx.write 传给下一个。handler 默认每个 Channel 一个实例（非共享），若要在多个 Channel 共享需加 @Sharable 注解，且必须保证 handler 无状态（线程安全），否则共享会引发并发问题。@Sharable 注意事项：只对无状态 handler 使用，否则并发状态竞争。

责任链按"入站从前向后、出站从后向前"传播，handler 用 ctx.fireXxx 传递。@Sharable 仅用于无状态 handler，否则并发不安全。

• EventLoop 与 Reactor
• Channel 绑定
• 负载均衡

Netty 的 EventLoop 是 Reactor 模式的实现：每个 EventLoop 是一个线程，运行一个事件循环（select + 处理 IO 事件），是单 Reactor 单线程的抽象。EventLoopGroup 管理多个 EventLoop，对应 Reactor 的多线程。Channel 绑定 EventLoop 通过轮询（round-robin）或负载均衡选择：新 Channel 注册时从 EventLoopGroup 中选一个 EventLoop（Netty 用轮询分配，保证均衡），该 Channel 生命周期只绑定这一个 EventLoop。N 个 EventLoop 通过轮询分配 Channel，实现线程复用与负载均衡。绑定后 Channel 事件在该 EventLoop 串行处理。

EventLoop 是 Reactor 单线程，EventLoopGroup 是多 Reactor。Channel 通过轮询绑定一个 EventLoop，实现多线程负载均衡与无锁串行。

• Netty Future/Promise
• addListener 回调
• 线程安全

Netty 的 Future/Promise 与 JDK Future 的差异：JDK Future 的 get() 阻塞等待，get(timeout) 带超时，不支持回调；Netty Future 提供 addListener 回调（异步完成时通知，不阻塞），支持链式、可指定执行线程，且支持失败原因。Promise 是 Future 的子接口，可主动设置成功/失败结果（可写）。线程安全：Netty Future 的监听器回调保证在注册线程或指定线程执行，结果设置线程安全（状态原子）。差异核心：Netty 支持回调式异步（非阻塞）、可写结果（Promise）、线程安全通知。

Netty Future 支持 addListener 异步回调（非阻塞）、Promise 可写结果、回调线程安全。相比 JDK Future 的阻塞 get，更适异步编程。

• EpollEventLoopGroup
• sendfile 零拷贝
• 传输路径

Netty 的 EpollEventLoopGroup 使用 Linux 的 epoll（边缘触发/水平触发）实现高性能事件监听。零拷贝 sendfile 路径：发送文件时用 FileRegion（如 DefaultFileRegion），Netty 通过 sendfile 系统调用（Linux 的 sendfile/transferTo）把文件数据直接从内核空间发送到 socket，无需把数据拷贝到用户态（内核态 0 拷贝），避免用户态缓冲与拷贝。FileRegion 的 transferTo 利用内核 sendfile，实现文件发送的零拷贝。相比传统 read+write 的用户态拷贝，sendfile 减少多次拷贝，提升文件传输吞吐。

EpollEventLoopGroup 用 epoll 监听，FileRegion 走 sendfile 系统调用，文件数据从内核直接发送，避免用户态拷贝，实现零拷贝。

• 上下文传播
• @Sharable 陷阱
• 竞争

ChannelHandler 上下文传播：handler 通过 ChannelHandlerContext（ctx）访问 pipeline 与下一个 handler，ctx.fireChannelRead 等传播事件。传播顺序由 handler 注册顺序决定（入站从前向后、出站从后向前）。@Sharable 陷阱：把 handler 标注 @Sharable 后可在多个 Channel/EventLoop 共享，但若有状态（成员变量）则多个 Channel 并发访问同一实例，产生数据竞争、状态错乱。陷阱即"标注 @Sharable 但 handler 非线程安全"。规避：只对无状态 handler 用 @Sharable，有状态 handler 用 @ChannelHandler.Sharable 或每 Channel 新建。

ctx 传播事件，@Sharable 让 handler 跨 Channel 共享，但非线程安全 handler 产生并发竞争。规避是无状态才共享。

• 池化
• 引用计数
• 泄漏检测

Netty 的 ByteBuf 内存管理：池化（PooledByteBufAllocator）复用 ByteBuf 缓冲，减少分配/释放开销，提升性能（类似对象池，按大小分桶复用）。引用计数（refCnt）：ByteBuf 通过引用计数管理生命周期，retain 增加引用、release 减少，归零时回收（池化回池或释放内存）。内存泄漏检测（ResourceLeakDetector）：检测未 release 的 ByteBuf（泄漏），通过 LeakDetector 记录分配栈，泄漏时打印 StackTrace 定位泄漏点。泄漏级别（DISABLED/SIMPLE/ADVANCED/PARANOID）控制检测开销。管理核心是"池化复用 + 引用计数 + 泄漏检测"。

池化复用减分配，引用计数管理生命周期（retain/release），泄漏检测定位未释放。三者保证 ByteBuf 高效且不泄漏。

• CompositeByteBuf
• slice
• FileRegion 与堆外

Netty 的零拷贝体现在：CompositeByteBuf（组合多个 ByteBuf 为逻辑整体，避免复制拼接）；slice/duplicate（共享底层内存的视图切片，避免复制数据）；FileRegion（sendfile 内核零拷贝发送文件）；堆外内存（DirectBuffer 直接操作 off-heap，避免堆内→堆外拷贝）。这些都避免"不必要的内存拷贝"：CompositeByteBuf 免拼接拷贝，slice 免切片拷贝，FileRegion 免用户态拷贝，堆外免堆↔堆外拷贝。零拷贝降低拷贝与分配开销，提升吞吐。

零拷贝各层面：Composite 免拼接、slice 免切片、FileRegion 免用户态、堆外免堆外拷贝。核心是减少内存拷贝。

• IdleStateHandler
• 三种空闲检测
• 断线重连

IdleStateHandler 检测三种空闲：读空闲（readerIdleTime，超时未读）、写空闲（writerIdleTime，超时未写）、读写空闲（allIdleTime，超时未读写）。空闲时触发 IdleStateEvent，handler 中处理（如发心跳、判定连接失效）。断线重连：客户端在 IdleStateEvent 时发心跳（ping），若持续无响应（读空闲/超时）判定连接失效，关闭连接并触发重连（用 Bootstrap 重新 connect，带退避重试）。服务端可在读空闲超时后关闭空闲连接（释放资源）。实现是"空闲检测 + 心跳 + 超时判定 + 重连"。

IdleStateHandler 检测读/写/读写空闲，触发事件后发心跳或判定失效。断线重连是"心跳确认 + 超时关闭 + 重新连接"。

• 池化与引用计数
• LeakDetector
• 泄漏检测

Netty 的 ByteBuf 池化（PooledByteBufAllocator）复用缓冲，引用计数（refCnt）管理生命周期（retain/release）。若 ByteBuf 未 release（泄漏），池化缓冲无法回收，持续泄漏。内存泄漏检测用 ResourceLeakDetector：分配 ByteBuf 时记录泄漏样本（含分配栈），release 时移除；若 GC 时仍存在未 release 的样本，判定泄漏并打印 StackTrace 定位。泄漏级别（DISABLED/SIMPLE/ADVANCED/PARANOID）控制检测强度与开销。检测机制是"样本记录 + GC 时核对 + 打印分配栈"。泄漏时需在对应的 release 路径补 release。

池化 + 引用计数管理缓冲，LeakDetector 记录分配栈并在 GC 时发现未释放的泄漏，打印栈定位。泄漏检测保缓冲不泄漏。

• LineBasedFrameDecoder
• FixedLengthFrameDecoder
• 自定义协议解码器

粘包拆包解码器选择：LineBasedFrameDecoder（按 \n 切分，适合文本行协议，如 FTP 响应）；FixedLengthFrameDecoder（固定长度，适合定长协议，如简单二进制）；DelimiterBasedFrameDecoder（自定义分隔符，适合自定义分隔文本协议）；LengthFieldBasedFrameDecoder（长度字段，适合带长度头的二进制协议，最通用）；自定义协议（ByteToMessageDecoder 手写，适合复杂协议头）。选择依据协议格式：文本行用 LineBased，定长用 FixedLength，分隔用 Delimiter，二进制长度用 LengthFieldBased，复杂协议手写。长度字段二进制协议最流行。

解码器按协议格式选：文本行、定长、分隔、长度字段、自定义。二进制带长度头用 LengthFieldBasedFrameDecoder，复杂协议手写。

• EventLoop 阻塞
• 耗时操作影响
• offload

在 EventLoop 中执行阻塞/耗时操作会阻塞该 EventLoop 的事件循环，导致该线程上所有 Channel 的 IO 事件被延迟（一个 Channel 阻塞影响同线程其他 Channel），吞吐下降。正确 offload（离线）方式：把耗时/阻塞操作放到业务线程池（executor）执行，EventLoop 只做 IO 与快速处理；用 ctx.executor().schedule 或提交到 ThreadPoolExecutor；回调再回到 EventLoop（通过 ctx.executor() 提交）。原则：EventLoop 不做阻塞/耗时操作，耗时操作 offload 到线程池，结果回 EventLoop。避免阻塞 EventLoop 是 Netty 高性能的关键。

EventLoop 阻塞影响所在线程所有 Channel，耗时操作 offload 到线程池，回调回 EventLoop。保持 EventLoop 快速处理 IO。

• FastThreadLocal
• 数组索引
• 哈希优化

Netty 的 FastThreadLocal 相比 JDK ThreadLocal 的优化：JDK ThreadLocal 用 ThreadLocalMap（哈希表 + 线性探测），查找需哈希与冲突处理；FastThreadLocal 为每个 FastThreadLocal 分配一个全局递增的 index，以该 index 作为数组下标直接访问 Thread 的 InternalThreadLocalMap 数组，O(1) 无哈希，查找更快。代价是每个 FastThreadLocal 有全局 index（可能累积），但访问快。FastThreadLocal 还优化了访问与清理。适合 Netty 高频访问的线程本地变量的场景。

FastThreadLocal 用全局 index 直接数组访问，替代 ThreadLocal 的哈希查找，O(1) 更快。适合 Netty 高频线程本地访问。

• writeAndFlush
• 高低水位线
• 背压

writeAndFlush 流程：把数据写入 Channel 的 outbound buffer（write 累积），再触发 flush 把缓冲数据发送到网络。若对端慢（不消费），outbound buffer 积压，内存增长。背压机制：高低水位线（write buffer watermark，高水位 highWaterMark 与低水位 lowWaterMark）控制积压：当缓冲字节数超过高水位时，Channel 变为不可写（isWritable() 为 false），通知上层停止写（背压）；当降到低水位以下恢复可写。上层通过 isWritable() 判断是否可继续写，避免无限积压导致内存溢出。背压是"水位线 + isWritable 通知"。

写出经 outbound buffer + flush，水位线控制积压：超高水位不可写（背压），低于低水位恢复。防内存积压。

• Netty 事件驱动
• 虚拟线程
• 取舍

Netty 用事件驱动 + 非阻塞 IO（Reactor），用少量线程处理海量连接，编程模型为回调/异步，吞吐高但复杂度高。虚拟线程用"每连接一虚拟线程"的阻塞式编程，阻塞时释放平台线程，代码同步简单，适合大量阻塞 IO。舍取：Netty 适合极致吞吐、连接密度高、清晰异步模型、需精细控制（如背压、协议）的场景，但开发复杂；虚拟线程适合开发简单、要求阻塞式代码、I/O 密集、吞吐足够高的场景，但仍受平台线程与 IO 模型限制。二者可结合（虚拟线程执行阻塞业务）。选型看复杂度容忍与吞吐需求。

Netty 事件驱动高吞吐但复杂，虚拟线程阻塞式简单但吞吐受限制。按开发复杂度与吞吐需求取舍，可结合。

• 入站/出站
• Handler 顺序
• 执行机制

ChannelPipeline 是 Handler 的双向链表，index 为 0 的是 head，index 为 size-1 的是 tail。入站事件（Inbound：read、channelActive、channelRead）从 head 开始向后传播（顺序是注册顺序），出站事件（Outbound：write、connect、flush）从 tail 开始向前传播（逆序）。每个 handler 处理事件后调用 ctx.fireChannelRead（入站继续）或 ctx.write（出站继续）传给下一个。Handler 顺序决定处理顺序：解码器在前、业务 handler 在后（入站），编码器在前、自定义 handler 在后（出站）。执行机制是"按链表顺序 + fireXxx 传播"。

入站从 head 向后、出站从 tail 向前，fireXxx 驱动传播。Handler 注册顺序决定处理顺序，解码器前置、业务后置。

• shutdownGracefully
• 停机流程
• 未完成任务

Netty 的 shutdownGracefully 优雅停机：先停止接受新连接，再等待已有事件/task 处理完成，最后关闭 EventLoop。流程：设置停止标志，EventLoop 不再接受新任务，处理完已加入队列的任务（如已注册的 IO 事件、定时任务），关闭所有 Channel，释放资源。shutdownGracefully 返回 Future，可等待完成。未完成任务处理：停机时排空队列中的任务（等待执行完），超时则强制关闭。优雅停机保证"在途任务完成、资源释放"，避免连接中断。可用 awaitTermination 等待。

shutdownGracefully 停止新连接、排空在途任务、关闭 Channel 与资源。优雅停机保证已处理任务完成，超时兜底。