Netty：35k Star 的 Java 网络框架

Netty 是一个 Java 网络应用框架，专注异步事件驱动的协议服务器与客户端开发。

在 Java 生态里，Netty 的位置比较特殊。几乎所有需要处理网络通信的中间件，底层都跑着 Netty。Dubbo、Elasticsearch、Spark、Cassandra、Flink，这些项目都依赖 Netty 做网络层。

Netty 目前斩获了 34,975 个 Star，在 Java 开源项目里排名靠前。

Netty 解决了什么问题

Java 原生的 NIO API（java.nio）可以用，但用起来很麻烦。需要手动管理 Selector、Channel、Buffer 三者的交互，处理半包、粘包、连接断开、内存泄漏各种边界情况。代码写出来又长又容易出错，稍不注意就会踩坑。

Netty 在 NIO 之上做了一层封装，提供了 ChannelPipeline 机制。数据从网络进来后，经过一系列 ChannelHandler 逐步处理，每个 Handler 只负责一件事。比如一个典型的 HTTP 服务，Pipeline 里会有解码器、编码器、业务处理器，各司其职。

这种设计让协议解析、编解码、业务逻辑互相解耦。想加一个监控指标，插一个 Handler 就行，不用动其他代码。

核心组件

Netty 的核心模型围绕四个组件。

Channel 对应一次网络连接。客户端发起连接拿到一个 Channel，服务端接受连接也会创建一个 Channel。所有的读写操作都通过 Channel 完成。

EventLoop 负责处理 Channel 上的 I/O 事件。一个 EventLoop 可以管理多个 Channel，但一个 Channel 绑定一个 EventLoop。这个设计保证了同一个 Channel 的所有事件在同一个线程中处理，省去了线程同步的开销。

ChannelPipeline 是 Handler 的链式容器。新数据进来从 Head 开始，依次经过各个 Handler，最后到达 Tail。每个 Handler 可以处理数据、修改数据、或者传递给下一个 Handler。

ByteBuf 是 Netty 自己的字节缓冲区。相比 java.nio.ByteBuffer，ByteBuf 把读写索引分开，支持引用计数和零拷贝，还提供了衍生缓冲区用于切片操作。用起来比原生 API 方便很多。

使用方式

Netty 4.2 要求 Java 8 或更高版本。io_uring 原生传输需要 Java 9+。

构建项目需要 Maven。在 Linux 或 macOS 上编译时，需要额外安装系统依赖，因为 Netty 会编译原生传输模块（epoll、kqueue、io_uring）。Windows 上不需要这些。

Netty 的模块化支持做得不错。Java 9+ 使用 JPMS 的项目，可以参考仓库中的 Modular Netty guide，里面分使用者和开发者两个部分做了说明。

谁在用 Netty

随便列几个：Dubbo 的网络层基于 Netty，Elasticsearch 节点间通信用的 Netty，Cassandra 内部通信依赖 Netty，Apache Flink 的网络传输层用的 Netty，gRPC Java 底层也是 Netty。

这些项目覆盖了 RPC、搜索、存储、流计算等场景。能同时满足这些需求，说明 Netty 的抽象层设计经得住考验。

什么场景适合直接用 Netty

自定义 RPC 框架、即时通讯系统、游戏服务器、物联网网关、需要处理大量长连接的服务，这些场景下 Netty 基本是标配。

如果只是做 HTTP 接口，Spring Boot 内嵌的 Tomcat 就够了，或者用 Spring WebFlux，不需要直接对接 Netty 的 API。

Netty 在 Java 网络编程领域已经统治了很多年。34,975 个 Star 背后，是十多年来大量生产环境的实际使用。对于 Java 开发者来说，了解 Netty 的工作原理，是理解整个 Java 中间件生态的一把钥匙。

用。对于 Java 开发者来说，了解 Netty 的工作原理，是理解整个 Java 中间件生态的一把钥匙。