Netty 4.2 升级看点:事件循环解耦,io_uring 进入主线
Netty 4.2 把事件循环与具体传输实现拆开,将 io_uring 纳入正式支持,并调整了默认内存分配策略。对使用 Netty 的团队来说,这次升级既带来扩展能力,也需要重新检查 TLS 连接和依赖管理。
10 月 16 日,微信公众号“Java后端”刊文讨论这些变化。[1] 不过,4.2 并非刚发布的新版本:Netty 4.2.0.Final 已于 2025 年 4 月 3 日推出,基础运行要求为 JDK 8,io_uring 则要求 JDK 9 及以上。[2]
事件循环统一,监控和定制更容易复用
过去,NIO、epoll 等传输各有事件循环组,扩展逻辑容易与具体实现绑定。4.2 将 I/O 处理抽到独立组件,通过工厂注入统一的 MultiThreadIoEventLoopGroup。官方推荐的新写法是:[2][3]
EventLoopGroup group = new MultiThreadIoEventLoopGroup(
NioIoHandler.newFactory()
);这套结构便于统计注册的 Channel 或句柄数量、每轮处理量,以及 I/O 和任务处理分别耗费的时间。需要跨平台维护监控逻辑的团队,可以围绕统一的事件循环扩展。[2]
更换工厂时,启动配置中的 Channel 类型仍需匹配对应传输。[3]
io_uring 转正,孵化版需要改代码迁移
4.2 将 io_uring 从孵化模块移入正式传输模块 netty-transport-native-io_uring。原有孵化实现与新版本不兼容,官方也在正式版发布时宣布不再继续为 4.1 提供孵化版 io_uring 支持。[2]
迁移涉及包名和 API:包路径改为 io.netty.channel.uring,类名前缀从 IOUring 调整为 IoUring,原来的 IOUringEventLoopGroup 由统一事件循环组配合 IoUringIoHandler 取代。[3]
对网关、RPC 和消息服务而言,这提供了评估新传输实现的机会。具体收益仍需放在自身流量、硬件和运行环境中测量,不能仅凭采用 io_uring 就推定吞吐量提升。
内存分配器换了默认值,性能要看负载
原先处于实验阶段的 adaptive 分配器成为默认选项。Netty 团队预期,多数负载下它可以减少内存占用,性能与 pooled 相当或略好,设计时也考虑了虚拟线程。[2]
官方迁移指南同时建议把版本升级与分配器切换分开:先保留 pooled 完成升级,再测试 adaptive,观察堆内存、直接内存和 GC 活动。保留旧分配器可使用启动参数:[3]
-Dio.netty.allocator.type=pooledTLS 默认校验主机名,依赖版本必须统一
4.2 客户端 TLS 默认开启主机名校验。连接地址与证书身份不匹配时,原先可以建立的连接可能失败。[3] 原文把这一变化概括为连接自签证书会直接出错;实际排查应分别检查证书信任关系和主机名匹配,二者是不同问题。
依赖管理也需要一起处理:4.1 与 4.2 不能在同一 classpath 中混用,官方建议通过 netty-bom 统一版本,并检查间接依赖。[3]
Java 24 的变化需要分清版本
原文称 Java 24 默认禁止使用 sun.misc.Unsafe,这一说法不准确。Netty 官方说明指出,Java 24 开始在首次调用相关内存访问方法时输出警告。[4]
Netty 4.2.2 起增加了 MemorySegment 支持,但具体路径有版本和配置条件:4.2.3 起可在 Java 24 上通过启用原生访问,直接链接系统的 malloc、free;共享 arena 的回退路径则因 JDK 问题需要 Java 25。不能把它理解为所有 4.2.2 以上环境都会自动、无条件完成替换。[4]
4.2 的升级价值,需要结合应用瓶颈判断。需要扩展事件循环、迁移孵化版 io_uring,或验证内存策略的团队,有了更明确的改进方向;落地时则应先处理连接校验与版本一致性,再逐项评估运行表现。
来源
[1] 鹏磊:《Netty 4.2 大更新后,到底有多强大?》,微信公众号“Java后端”,2026 年 10 月 16 日。原文唯一配图为推广横幅,无技术统计信息。
[2] Netty:Netty 4.2.0.Final released,2025 年 4 月 3 日。
[3] Netty:Netty 4.2 Migration Guide,查阅于 2026 年 10 月 16 日。
[4] Netty:Java 24 and sun.misc.Unsafe,页面标注更新于 2025 年 7 月 23 日。
#Netty #Java #io_uring #网络编程 #内存管理 #TLS #开源技术
