Netty · FLF Blog

Netty 是什么

书面笔记版

Netty 是一个基于 Java NIO 的异步事件驱动网络通信框架，主要用于快速开发高性能、高并发的网络服务。

它屏蔽了原生 NIO 的复杂细节，提供了更易用的线程模型、事件模型、编解码器、内存管理和连接管理能力。

常见应用场景：

场景	说明
RPC 框架	Dubbo、gRPC Java 的部分网络层思想都和 Netty 这类异步通信模型相关
长连接服务	IM、推送、网关、游戏服务器
自定义协议	私有 TCP 协议、二进制协议
高性能网关	需要管理大量连接和高吞吐请求

Netty 的核心不是替代 HTTP 业务框架，而是解决底层网络通信问题。

面试口述版

Netty 是一个基于 Java NIO 的异步事件驱动网络框架，用来开发高性能网络服务。它把原生 NIO 里比较复杂的 Selector、Channel、Buffer、线程调度和异常处理封装好了，还提供了 Pipeline、编解码器、ByteBuf 和连接管理能力。像 RPC、网关、IM、推送这类需要高并发长连接或自定义协议的场景，经常会用到 Netty。

为什么要使用 Netty 做网络编程

书面笔记版

Java 自己也能做网络编程，常见方式有三类：

模型	核心 API	特点
BIO	`Socket`、`ServerSocket`	阻塞 IO，模型简单，但一个连接通常要占用一个线程
NIO	`SocketChannel`、`ServerSocketChannel`、`Selector`	非阻塞 IO，少量线程可以管理大量连接，但 API 使用复杂
AIO	`AsynchronousSocketChannel`、`AsynchronousServerSocketChannel`	异步 IO，通过回调或 Future 感知完成结果

也就是说，Netty 不是因为 Java 不能写网络程序才出现的，而是因为直接使用原生 API 的工程成本比较高。

原生网络编程需要自己处理连接接入、读写事件、线程模型、粘包拆包、编解码、ByteBuffer 管理、异常处理、连接关闭和性能优化。业务复杂后，代码很容易变得难维护。

Netty 基于 Java NIO 做了工程化封装，提供了 EventLoop、ChannelPipeline、ChannelHandler、ByteBuf、编解码器、异步ChannelFuture等能力，让开发者更专注于协议设计和业务处理。

面试口述版

Java 原生当然可以做网络编程，比如 BIO 里的 Socket 和 ServerSocket，NIO 里的 SocketChannel、ServerSocketChannel 和 Selector，还有 AIO 里的异步 Channel。但直接写原生网络程序，很多工程细节都要自己处理，比如线程模型、Selector 轮询、ByteBuffer 读写、粘包拆包、编解码、异常和连接管理。Netty 是在 Java NIO 之上的工程化封装，提供 EventLoop、Pipeline、ByteBuf、Decoder 和异步 Future，所以更适合开发高并发、长连接、自定义协议这类网络服务。

为什么不用原生 NIO

书面笔记版

原生 NIO 可以实现非阻塞 IO，但直接使用成本较高。

问题	原生 NIO 的痛点	Netty 的处理
API 复杂	Selector、SelectionKey、Channel、Buffer 要自己组合	封装为 Channel、EventLoop、Pipeline
半包粘包	TCP 是字节流，需要自己处理边界	提供多种 Decoder
线程模型	Reactor 模型要自己设计	提供 Boss/Worker EventLoopGroup
Buffer 使用	ByteBuffer 读写切换容易出错	ByteBuf 分离读写指针
异常处理	连接关闭、空轮询、异常传播都要处理	提供成熟事件传播机制
性能优化	内存池、零拷贝、批量 flush 要自己做	内置多种优化能力

Netty 不是让 NIO 更神秘，而是把 NIO 工程化。

面试口述版

原生 NIO 能做非阻塞通信，但直接写会很复杂，比如 Selector 轮询、SelectionKey 状态管理、ByteBuffer 读写切换、粘包拆包、线程模型和异常处理都要自己实现。Netty 在 NIO 上做了工程化封装，提供 EventLoop、ChannelPipeline、ByteBuf、编解码器和成熟的线程模型，所以开发效率、稳定性和性能都更好。

Netty 核心组件

书面笔记版

Netty 的核心组件可以按启动、连接、线程、事件处理四层理解。

组件	作用
`Bootstrap`/`ServerBootstrap`	客户端或服务端启动入口
`EventLoopGroup`	线程组，负责处理 IO 事件和任务
`EventLoop`	一个事件循环线程，通常绑定多个 Channel
`Channel`	对网络连接的抽象
`ChannelPipeline`	Channel 内部的处理器链
`ChannelHandler`	业务处理、编解码、异常处理的具体节点
`ChannelFuture`	异步操作结果
`ByteBuf`	Netty 自己的字节缓冲区

服务端启动时，ServerBootstrap 通常配置两个线程组：

bossGroup：负责接收客户端连接。
workerGroup：负责处理连接上的读写事件。

一个典型请求会经过：

flowchart LR A[Socket 连接] --> B[Channel] B --> C[EventLoop] B --> D[ChannelPipeline] D --> E[Decoder] E --> F[Business Handler] F --> G[Encoder] G --> H[Socket 写回]

面试口述版

Netty 里比较核心的组件有 Bootstrap、EventLoopGroup、EventLoop、Channel、ChannelPipeline、ChannelHandler、ChannelFuture 和 ByteBuf。Bootstrap 负责启动，Channel 表示连接，EventLoop 负责处理连接上的 IO 事件，Pipeline 是处理器链，Handler 负责具体的编解码和业务逻辑，ChannelFuture 表示异步结果，ByteBuf 是 Netty 自己封装的缓冲区。

Reactor 线程模型

书面笔记版

Reactor 模型的核心思想是：一个或多个线程负责监听 IO 事件，事件就绪后分发给对应处理器执行。

常见 Reactor 模型：

模型	特点	问题
单 Reactor 单线程	一个线程负责连接接收、读写和业务处理	实现简单，但无法利用多核，业务阻塞会影响所有连接
单 Reactor 多线程	Reactor 负责 IO 事件，业务交给线程池	IO 和业务分离，但连接接收和读写仍集中在一个 Reactor
主从 Reactor 多线程	Main Reactor 接收连接，Sub Reactor 处理读写，业务可再交给业务线程池	高并发场景最常见

Netty 服务端常用主从 Reactor 模型：

flowchart TD A[Client] --> B[Boss EventLoopGroup] B --> C[Accept 新连接] C --> D[注册到 Worker EventLoopGroup] D --> E[Worker EventLoop] E --> F[读写 IO 事件] F --> G[ChannelPipeline] G --> H[业务 Handler]

注意：Netty 的 Handler 默认运行在绑定该 Channel 的 EventLoop 线程里。如果业务逻辑耗时，应该投递到业务线程池，避免阻塞 IO 线程。

面试口述版

Reactor 模型就是用事件驱动的方式处理 IO。Netty 服务端一般是主从 Reactor：BossGroup 负责 accept 新连接，接收到连接后注册到 WorkerGroup，WorkerGroup 里的 EventLoop 负责这个连接后续的读写事件。一个 Channel 通常绑定到一个 EventLoop，后续 IO 事件都在这个 EventLoop 线程执行，所以不要在 IO 线程里做耗时业务。

EventLoop 和线程绑定关系

书面笔记版

EventLoop 本质上是一个单线程事件循环，负责处理：

注册到它上面的 Channel 的 IO 事件。
用户提交的普通任务。
定时任务。

重要规则：

一个 EventLoop 只绑定一个线程。
一个 Channel 生命周期内通常只注册到一个 EventLoop。
一个 EventLoop 可以管理多个 Channel。
同一个 Channel 的 IO 事件串行执行，天然减少并发锁竞争。

这种绑定关系的好处是：

同一个连接的读写处理有线程亲和性。
Handler 内处理连接级状态时，不需要频繁加锁。
减少线程切换成本。

但缺点是：某个 Handler 阻塞 EventLoop，会影响这个 EventLoop 管理的所有 Channel。

面试口述版

EventLoop 可以理解成一个单线程事件循环。一个 EventLoop 对应一个线程，一个 Channel 通常只绑定一个 EventLoop，而一个 EventLoop 可以管理多个 Channel。同一个 Channel 的 IO 事件会在同一个 EventLoop 线程里串行执行，所以连接级状态处理起来比较简单，不需要大量加锁。但如果在 Handler 里做耗时操作，会阻塞这个 EventLoop 上的其他连接。

ChannelPipeline 和 Handler 执行顺序

书面笔记版

ChannelPipeline 是 Netty 的责任链，用来组织多个ChannelHandler。

Handler 分为两类：

类型	方向	常见方法
`ChannelInboundHandler`	入站事件，从链表头向尾传播	`channelRead`、`channelActive`、`exceptionCaught`
`ChannelOutboundHandler`	出站事件，从链表尾向头传播	`write`、`flush`、`connect`

入站事件通常是读数据：

Socket -> Head -> Decoder -> BusinessHandler -> Tail

出站事件通常是写数据：

BusinessHandler -> Encoder -> Head -> Socket

常见顺序：

入站时先经过解码器，把字节转成业务对象。
再进入业务 Handler。
出站时先由业务 Handler 写出响应对象。
再经过编码器，把业务对象转成字节。
最后写回 Socket。

如果某个 Handler 不调用 ctx.fireChannelRead() 或不继续传播事件，后面的入站 Handler 就收不到事件。

面试口述版

ChannelPipeline 是一条责任链，里面放多个 Handler。入站事件从头到尾传播，比如读请求时先经过 Decoder，再到业务 Handler；出站事件从尾到头传播，比如业务 Handler 写响应，会先经过 Encoder，再写到 Socket。需要注意事件传播，如果 Handler 没有调用 fireChannelRead 或相关传播方法，后面的 Handler 就不会继续执行。

ByteBuf 和 ByteBuffer 的区别

书面笔记版

ByteBuf 是 Netty 对字节缓冲区的封装，比 Java NIO 的ByteBuffer 更适合网络通信。

对比点	`ByteBuffer`	`ByteBuf`
读写指针	一个 position，需要 flip 切换读写模式	readerIndex 和 writerIndex 分离
扩容	容量固定，扩容不方便	可以按需扩容
池化	原生不强调池化	支持池化，减少内存分配
零拷贝	能力较弱	支持 slice、duplicate、CompositeByteBuf
引用计数	无	有引用计数，需要释放

ByteBuf 的内存位置：

类型	特点
堆内存 `HeapByteBuf`	分配在 JVM 堆上，受 GC 管理，适合需要访问 byte 数组的场景
直接内存 `DirectByteBuf`	分配在堆外，减少堆内数组和本地内存之间的复制，适合网络 IO

ByteBuf 还可以按分配方式分为池化和非池化：

类型	特点
`PooledByteBuf`	复用内存块，降低频繁分配和回收成本
`UnpooledByteBuf`	每次按需分配，不经过 Netty 内存池

注意：PooledByteBuf 表示是否池化，不表示内存一定在堆内或堆外。池化 ByteBuf 可以是池化堆内内存，也可以是池化堆外直接内存。

引用计数注意点：

ByteBuf 默认使用引用计数。
计数为 0 后内存会被释放。
继续访问已释放的 ByteBuf 会报错。
自己保留跨线程或异步使用时，通常要 retain()。
使用完成后要匹配 release()。

面试口述版

ByteBuf 是 Netty 自己的缓冲区，比 ByteBuffer 更好用。ByteBuffer 只有一个 position，读写要 flip 切换，容易出错；ByteBuf 分成 readerIndex 和 writerIndex，读写更清晰。ByteBuf 还支持自动扩容、池化、堆外内存和零拷贝能力。但它有引用计数，用完要正确 release，否则可能内存泄漏，释放后继续访问也会出问题。

Netty 使用堆内内存还是堆外内存

书面笔记版

Netty 堆内内存和堆外内存都支持，不能简单说 Netty 只使用某一种。

类型	位置	JVM 关系	适用场景
`HeapByteBuf`	JVM 堆内	受 JVM 堆大小和 GC 管理	业务代码需要频繁访问`byte[]`
`DirectByteBuf`	JVM 堆外直接内存	不占`-Xmx`，但仍属于 JVM 进程内存，受直接内存上限影响	网络 IO、减少堆内到本地内存的复制

网络 IO 场景更偏向使用堆外直接内存。原因是 Socket 读写最终要和操作系统内核交互，如果数据在 JVM 堆内，通常需要先复制到本地内存再进行 IO；使用 DirectByteBuf 可以减少这一步复制。

它和 JVM 有关系：

堆内内存受 -Xmx 和 GC 影响。
堆外直接内存不直接占用 -Xmx，但会占用 JVM 进程内存。
直接内存通常受 -XX:MaxDirectMemorySize 这类参数限制。
Netty 的 ByteBuf 使用引用计数管理生命周期，用完不 release() 可能导致堆外内存泄漏。

所以排查 Netty 内存问题时，不能只看 Java 堆。堆外泄漏时，经常表现为 JVM 堆使用率不高，但进程内存持续上涨，最终可能出现直接内存不足。

面试口述版

Netty 堆内和堆外都能用，堆内是 HeapByteBuf，堆外是 DirectByteBuf。网络 IO 场景一般更倾向用堆外直接内存，因为 Socket 读写要和操作系统内核交互，堆外内存可以减少一次堆内数据到本地内存的复制。它和 JVM 也有关系，堆外内存虽然不占 Xmx，但仍然属于 JVM 进程内存，并且会受 MaxDirectMemorySize 这类直接内存限制。Netty 的 ByteBuf 还有引用计数，用完不 release 可能导致堆外内存泄漏，表现为堆不高但进程内存一直涨。

TCP 粘包和拆包

书面笔记版

TCP 是面向字节流的协议，本身没有消息边界。应用层一次写入的数据，不一定对应接收方一次读取的数据。

现象	说明
粘包	多个小消息被接收方一次读到
拆包	一个完整消息被拆成多次读到

产生原因：

TCP 面向字节流，不保留应用层消息边界。
发送方可能启用 Nagle 算法合并小包。
接收方缓冲区读取时机和大小不固定。
网络传输和操作系统缓冲区调度导致分段不同。

解决思路是应用层定义协议边界：

方案	Netty 常用解码器	适用场景
固定长度	`FixedLengthFrameDecoder`	每个消息长度固定
分隔符	`DelimiterBasedFrameDecoder`、`LineBasedFrameDecoder`	文本协议、按换行分割
长度字段	`LengthFieldBasedFrameDecoder`	二进制协议，最常用
自定义协议	自定义 `ByteToMessageDecoder`	协议复杂或有特殊校验

长度字段协议常见格式：

+------------+-------------+--------------+
| magic/code | body length | body content |
+------------+-------------+--------------+

其中 body length 用来告诉接收方后面 body 有多少字节。

面试口述版

TCP 是字节流协议，没有消息边界，所以可能出现粘包和拆包。粘包就是多个消息一次读到，拆包就是一个消息分多次读到。解决办法不是依赖 TCP，而是在应用层设计协议边界，比如固定长度、分隔符、长度字段。Netty 里常用 FixedLengthFrameDecoder、DelimiterBasedFrameDecoder、LineBasedFrameDecoder，二进制协议最常用的是 LengthFieldBasedFrameDecoder。

Netty 零拷贝

书面笔记版

Netty 里的零拷贝主要是减少用户态内存之间不必要的数据复制，不完全等同于操作系统层面的 sendfile 零拷贝。

常见体现：

能力	说明
`CompositeByteBuf`	把多个 ByteBuf 组合成逻辑上的一个 ByteBuf，避免合并复制
`slice()`	基于原 ByteBuf 切出子视图，不复制底层数据
`duplicate()`	复制读写指针视图，不复制底层数据
`FileRegion`	文件传输时可利用`transferTo`减少数据复制
Direct Buffer	使用堆外内存，网络 IO 时减少一次堆内到堆外复制

注意：slice()、duplicate()共享底层内存，也共享引用计数相关生命周期，使用时要注意 retain()和 release()。

面试口述版

Netty 的零拷贝主要指减少不必要的内存复制，比如 CompositeByteBuf 可以把多个 ByteBuf 组合起来，不需要复制成一个大数组；slice 和 duplicate 可以创建视图，不复制底层数据；文件传输可以用 FileRegion 走 transferTo；使用 DirectByteBuf 也能减少网络 IO 时堆内到堆外的复制。要注意这些视图通常共享底层内存和引用计数。

心跳和空闲检测

书面笔记版

长连接服务需要心跳机制判断连接是否仍然可用。

Netty 常用 IdleStateHandler 做空闲检测：

参数	含义
readerIdleTime	多久没有读事件，触发读空闲
writerIdleTime	多久没有写事件，触发写空闲
allIdleTime	多久没有读写事件，触发全部空闲

常见处理方式：

客户端定时发送心跳包。
服务端用 IdleStateHandler 检测读空闲。
一段时间没有收到心跳，服务端关闭连接。
客户端监听断连事件，按退避策略重连。

心跳不要过于频繁，否则大量长连接会产生明显额外流量和 CPU 开销。生产环境通常结合业务实时性、网关超时、NAT 超时和移动网络情况设置。

面试口述版

Netty 长连接一般用 IdleStateHandler 做空闲检测。比如服务端设置读空闲时间，如果一段时间没有收到客户端数据或心跳，就触发 IdleStateEvent，业务 Handler 可以记录次数，超过阈值就关闭连接。客户端断开后可以做重连，但最好加退避策略，避免大量客户端同时重连打爆服务端。

Netty 高性能原因

书面笔记版

Netty 高性能来自多个方面，不是单个优化点。

原因	说明
NIO 非阻塞 IO	少量线程管理大量连接
Reactor 线程模型	IO 事件分发清晰，Boss/Worker 职责分离
EventLoop 串行化	同一 Channel 事件在同一线程执行，减少锁竞争
ByteBuf	读写指针分离、池化、堆外内存、引用计数
零拷贝	减少不必要的内存复制
Pipeline 机制	编解码和业务处理解耦
批量写和异步 Future	提升吞吐，避免同步阻塞等待

常见调优点：

IO 线程不要执行耗时业务。
合理设置 Boss/Worker 线程数。
业务线程池要设置队列和拒绝策略。
合理使用池化 ByteBuf，避免内存泄漏。
大量小包写出时注意 flush 策略。
设置高低水位线，避免写缓冲无限膨胀。
监控连接数、EventLoop 延迟、直接内存、GC、异常断连。

面试口述版

Netty 性能高主要因为它基于 NIO 非阻塞 IO，用 Reactor 模型让少量线程管理大量连接；同一个 Channel 的事件在同一个 EventLoop 里串行执行，减少锁竞争；ByteBuf 支持池化、堆外内存和引用计数，降低内存分配成本；Pipeline 让编解码和业务处理解耦；再加上零拷贝、异步 Future、批量写等机制，整体吞吐会比较高。

Netty 常见坑

书面笔记版

问题	原因	处理方式
EventLoop 被阻塞	Handler 里执行慢 SQL、远程调用、复杂计算	耗时任务放到业务线程池
ByteBuf 泄漏	retain/release 不匹配	开启 leak detector，明确对象所有权
粘包拆包	没有定义协议边界	使用合适 Decoder
写缓冲堆积	对端慢、发送过快	设置水位线、限流、关注 `isWritable()`
重连风暴	大量客户端同时重连	指数退避、随机抖动、限流
Handler 共享错误	`@Sharable` Handler 内保存连接级可变状态	不共享有状态 Handler，或把状态放 Channel 属性
异常未关闭连接	异常只打印不处理	在 `exceptionCaught` 中按场景关闭或降级

@Sharable 的 Handler 必须是线程安全的。如果 Handler 里有成员变量保存请求级或连接级状态，不应该共享同一个实例。

面试口述版

Netty 常见坑有几个：第一，不要在 EventLoop 线程里做耗时业务，否则会影响这个线程上的所有连接；第二，ByteBuf 有引用计数，retain 和 release 不匹配会泄漏或提前释放；第三，TCP 必须处理粘包拆包；第四，写太快可能导致写缓冲堆积，要关注水位线和 isWritable；第五，重连要做退避，避免重连风暴；另外共享 Handler 时要保证线程安全。

Netty 面试追问

书面笔记版

Netty 默认是同步还是异步？

Netty 的 IO 操作是异步的，调用 writeAndFlush() 这类方法通常会立即返回 ChannelFuture，真正写入完成后通过监听器回调结果。

ChannelFuture 的作用是什么？

ChannelFuture 表示异步 IO 操作的结果，可以添加 Listener 在操作成功、失败或取消时执行逻辑。不要在 EventLoop 线程里长时间阻塞等待 Future 完成。

Netty 如何保证同一个连接的顺序性？

同一个 Channel 通常绑定同一个 EventLoop，IO 事件在这个 EventLoop 线程中串行处理，因此同一连接内的事件天然有顺序性。

业务线程池处理完结果后怎么写回？

业务线程处理完成后可以调用 ctx.writeAndFlush() 写回。Netty 会保证最终写操作回到对应 Channel 的 EventLoop 中执行。

为什么 Handler 里不能随便阻塞？

因为 Handler 默认运行在 EventLoop 线程里，一个 EventLoop 管理多个 Channel。阻塞一个 Handler，不只是影响当前请求，还会影响这个 EventLoop 上其他连接的 IO 事件处理。

面试口述版

如果面试官追问，我会强调 Netty 是异步事件驱动的，IO 操作返回 ChannelFuture，通过 Listener 感知结果。同一个 Channel 绑定同一个 EventLoop，所以同一连接的事件是串行有序的。Handler 默认在 EventLoop 里执行，不能随便阻塞，耗时业务要交给业务线程池。业务线程处理完后再 writeAndFlush，Netty 会把写操作调度回对应的 EventLoop。