10｜Netty native epoll 与零拷贝：从 Java NIO 再往下看一层![

10Netty native epoll 与零拷贝从 Java NIO 再往下看一层前面我们一直用NioEventLoopGroup、NioSocketChannel来讲 Netty。这是 Netty 最常见、最跨平台的使用方式EventLoopGroupbossGroupnewNioEventLoopGroup(1);EventLoopGroupworkerGroupnewNioEventLoopGroup();newServerBootstrap().group(bossGroup,workerGroup).channel(NioServerSocketChannel.class).childHandler(...);这里的Nio指的是Java NIO底层依赖的是SelectorServerSocketChannelSocketChannel但如果你看一些高性能服务尤其是 Linux 生产环境会看到另一类配置EventLoopGroupbossGroupnewEpollEventLoopGroup(1);EventLoopGroupworkerGroupnewEpollEventLoopGroup();newServerBootstrap().group(bossGroup,workerGroup).channel(EpollServerSocketChannel.class).childHandler(...);这就是 Netty 的 native epoll transport。这一篇回答几个问题Netty 已经有 Java NIO为什么还要 native epollNioEventLoopGroup 和 EpollEventLoopGroup 有什么区别native epoll 一定比 Java NIO 快吗Netty 里的零拷贝体现在哪里FileRegion 和 sendfile 是什么关系如果把它放到真实业务系统里epoll 和零拷贝不是两个孤立的底层名词而是两类很具体的工程压力大量连接怎么等海量数据怎么搬。比如云边系统里边缘侧可能要上传日志、图片、视频片段或业务结果到对象存储云端网关要转发 Web、App、开放 API 或内部服务请求媒体链路要处理 RTSP、RTMP、WebRTC、HLS、GB28181 等不同协议下的持续数据流。这里的压力不只是“业务逻辑复杂”而是连接多、数据大、传输持续、慢客户端多、网络质量不稳定。这时候就会自然追到几个问题一个线程能不能管理很多连接等待网络事件时线程到底在做什么文件从磁盘发到网络是否一定要先完整读进 JVM大文件、媒体流、普通接口请求能不能混在同一条资源通道里底层优化能解决多少问题哪些问题仍然是架构设计问题这就是这篇文章的业务入口epoll 优化的是“等事件”零拷贝优化的是“搬数据”但系统是否稳定还取决于我们如何划分链路、隔离资源和控制背压。先给结论Java NIO 是跨平台的非阻塞 IO 抽象Netty native epoll 是 Linux 下更贴近操作系统能力的实现FileRegion / transferTo 则用于 file - socket 场景减少数据拷贝。一、Java NIO 和 Linux epoll 的关系Java NIO 提供了一组跨平台 APISelectorSelectableChannelSelectionKeySocketChannelServerSocketChannel应用层写的是selector.select();但在 Linux 上JDK 的 Selector 底层通常会使用操作系统提供的 IO 多路复用能力。可能是epoll也就是说Java NIO Selector 是 Java 层抽象Linux epoll 是操作系统底层机制。Netty 的NioEventLoop是基于 Java NIO Selector 来实现事件循环。主线类似NioEventLoop.run()Selector.select()processSelectedKeys()ChannelPipeline这种方式的优势是跨平台JDK 标准 API使用简单兼容性好但它也有一层 Java NIO 抽象。Netty native epoll 则是绕过 JDK NIO 的部分抽象直接使用 Linux epoll 相关 native 能力。二、Netty native transport 是什么Netty 提供了多种 transport。常见包括NIO transportEpoll transportKQueue transportIOUring transport大致对应NIOJava 标准 NIO跨平台。EpollLinux native epoll。KQueuemacOS / BSD native kqueue。IOUringLinux io_uring更新的异步 IO 能力。本文重点看 epoll。如果使用 native epoll代码会从NioEventLoopGroupNioServerSocketChannelNioSocketChannel变成EpollEventLoopGroupEpollServerSocketChannelEpollSocketChannel它们的上层模型仍然是 Netty 的EventLoopChannelPipelineByteBuf也就是说换 transport不等于换编程模型。你写 Handler、Pipeline、ByteBuf 的方式基本不变。变化发生在底层 IO 实现。三、为什么要用 native epollnative epoll 的价值不是“让业务代码自动飞起来”。它主要带来几个方面的优势。第一更贴近 Linux 网络栈。Netty native epoll 可以暴露更多 Linux 特有能力。例如TCP_CORKSO_REUSEPORTEPOLLET 边缘触发更细的 socket option这些能力在 Java 标准 NIO 抽象里不一定完整暴露。第二减少 JDK Selector 层的一些限制和历史问题。Java NIO Selector 是跨平台抽象兼容性很好但也会带来一些额外层次。native transport 可以针对 Linux 做更专门的优化。第三在某些高连接、高吞吐场景下性能可能更好。但这里要谨慎native epoll 不保证所有场景都比 NIO 快。如果系统瓶颈在业务逻辑数据库下游服务序列化TLS带宽磁盘换 epoll transport 不一定有明显收益。它更适合底层网络开销已经变成重要因素的场景。四、NioEventLoop 和 EpollEventLoop 的相同点不管是 NIO 还是 epollNetty 的上层模型基本一致。都是EventLoopGroupEventLoopChannelPipelineHandler核心原则也一样一个 Channel 通常绑定一个 EventLoop。不要阻塞 EventLoop。writeAndFlush 走出站 Pipeline。写不完的数据进入 ChannelOutboundBuffer。ByteBuf 需要正确释放。所以如果你已经理解了NioEventLoopChannelPipelineByteBufChannelOutboundBuffer再看 epoll transport不需要重学 Netty。只是把底层等待事件的机制换成了更贴近 Linux 的实现。五、NioEventLoop 和 EpollEventLoop 的不同点不同点主要在底层 IO。NioEventLoop依赖java.nio.channels.Selector而EpollEventLoop依赖 Netty native 提供的 epoll 封装。可以粗略理解为NioEventLoop通过 JDK Selector 等待事件。EpollEventLoop通过 native epoll 等待事件。对应的 Channel 也不同。NIONioServerSocketChannelNioSocketChannelEpollEpollServerSocketChannelEpollSocketChannel但这些 Channel 仍然会接入同样的 Pipeline 机制。所以业务 Handler 感知不到太多差异。六、epoll edge-triggered 和 level-triggeredLinux epoll 有两种常见触发模式水平触发 level-triggered边缘触发 edge-triggered水平触发可以理解为只要 fd 还有数据可读epoll 就会持续通知。边缘触发可以理解为只有状态发生变化时通知一次。边缘触发通常要求使用非阻塞 fd一次事件里尽量把数据读到 EAGAIN否则可能漏读。Netty native epoll 可以使用更贴近 Linux epoll 的能力。但普通使用者通常不需要直接操作这些细节。Netty 会把底层复杂性封装在 Channel 和 EventLoop 中。你需要记住的是无论底层 NIO 还是 epollChannel 上的读写都不能阻塞。七、SO_REUSEPORT 有什么用Linux 下SO_REUSEPORT允许多个 socket 绑定同一个 IP 和端口。这对多进程或多 EventLoop 接收连接可能有帮助。它可以让内核在多个监听 socket 之间分配新连接。Nginx 也有类似能力reuseport在 Netty native epoll 中也可以使用相关选项。它解决的问题是多监听者之间如何更好地分摊 accept 压力。但它不是所有服务都必须开启。是否使用要结合连接数CPU 核数负载模型内核版本压测结果八、Netty 零拷贝的几个层次Netty 里谈零拷贝要分层。第一层CompositeByteBuf。多个 ByteBuf 组合成一个逻辑 ByteBuf避免拼接时复制数据。第二层slice / duplicate。创建 ByteBuf 视图共享底层内存避免复制数据。第三层FileRegion。文件区域直接写到 Channel底层可能使用 FileChannel.transferTo。第四层操作系统 sendfile。file - socket尽量减少用户态和内核态之间的数据拷贝。这些都可以叫“零拷贝思想”但层次不同。所以不能笼统说Netty 零拷贝 sendfile。更准确是Netty 在应用层 buffer 组合、内存视图、文件传输等多个层次减少数据复制。九、FileRegion 是什么Netty 中和系统级零拷贝最相关的是FileRegion常见实现DefaultFileRegion它表示文件中的一段区域。典型使用场景把本地文件发送到网络连接。示意代码FileChannelfileChannelFileChannel.open(path,StandardOpenOption.READ);DefaultFileRegionregionnewDefaultFileRegion(fileChannel,0,fileChannel.size());ctx.writeAndFlush(region);底层写出时Netty 可以走FileChannel.transferTo(…)在 Linux 上条件合适时可能进一步走sendfile这和我们前面零拷贝文章里的路径一致磁盘内核 page cachesocket / 网卡用户态只发指令不搬大块数据。十、FileRegion 的边界FileRegion 适合本地文件原样发送到 socket。例如静态文件服务器大文件下载视频文件分发日志文件传输但它不适合所有场景。如果数据需要压缩加密内容改写动态生成协议重组业务解析就很难保持严格 file - socket 零拷贝。尤其是 TLS 场景。如果 TLS 加密在用户态完成文件内容通常需要进入用户态进行加密处理。这会破坏传统 sendfile 路径。所以FileRegion 不是万能加速器。它适合非常明确的 file - socket 场景。十一、DefaultFileRegion 和 ChunkedFile 怎么选Netty 中发送文件时除了 FileRegion还可能看到ChunkedFileChunkedWriteHandler二者思路不同。DefaultFileRegion更偏向零拷贝 file - socket。ChunkedFile更偏向分块读取文件再逐块写出。什么时候用 ChunkedFile常见是TLS 场景需要经过用户态处理不能使用 sendfile 的场景所以可以简单记明文文件直发优先考虑 FileRegion。需要 TLS 或用户态处理通常走 ChunkedFile / ChunkedWriteHandler。十二、native epoll 和零拷贝是同一件事吗不是。这是两个不同层面的优化。native epoll 优化的是等待和事件通知。也就是大量连接哪些可读、哪些可写。零拷贝优化的是数据搬运。也就是大块数据如何少经过用户态、少占 CPU 拷贝。可以这样对比epoll管连接事件。sendfile / FileRegion管文件数据发送。ByteBuf slice / composite管应用层 buffer 复制。它们都属于高性能 IO 的组成部分但解决的问题不同。十三、native epoll 是否一定要用不一定。如果你的系统是普通业务服务瓶颈在数据库缓存下游 HTTP业务逻辑序列化切 native epoll 可能没有明显收益。如果你的系统是网关长连接服务IM游戏网关高吞吐文件传输大量连接的代理服务并且运行在 Linux 上那么 native epoll 更值得考虑。但是否使用最好通过压测验证。不要把它当成打开就一定翻倍。更现实的收益是更贴近 Linux 网络能力更多 socket option某些场景下更低开销更好的高连接支持十四、如何选择 NIO 和 epoll可以按这个思路判断。优先使用 NIO 的情况需要跨平台对 Linux 特有优化不敏感业务瓶颈不在网络层部署简单优先考虑 epoll 的情况只部署 Linux连接数很高网络事件非常密集需要 Linux 特有 socket option追求更低网络层开销已经通过压测证明网络层是瓶颈在 Spring Cloud Gateway / Reactor Netty 场景里也可以通过依赖和配置让底层使用 native transport。但仍然要记住native transport 只是底层优化不会修复阻塞 Filter、慢下游、连接池耗尽、写队列堆积这些架构问题。十五、从 Netty 再看 Nginx学到这里可以把 Netty 和 Nginx 再对照一下。Nginxworker 进程epoll 事件驱动sendfile 静态文件配置驱动反向代理NettyEventLoop 线程NIO / epoll transportFileRegion 文件传输Pipeline 可编程扩展自定义协议两者定位不同。Nginx 是成品服务器。Netty 是网络编程框架。但底层思想高度相似少量执行单元管理大量连接非阻塞 IO 等待事件数据能不拷贝就少拷贝慢连接不能阻塞主循环。这也是为什么前面先学 epoll、零拷贝、Nginx再学 Netty会更容易形成整体认知。十六、结论Netty 的 NIO transport 和 native epoll transport本质上都是为了实现少量 EventLoop 管理大量连接事件。区别在于NIO基于 Java 标准 Selector跨平台。native epoll基于 Linux epoll native 能力更贴近 Linux 网络栈。Netty 的零拷贝也要分层理解slice / duplicate减少 ByteBuf 数据复制。CompositeByteBuf组合多个 ByteBuf减少拼接复制。FileRegion表示文件区域支持 file - socket 高效传输。sendfile操作系统层面减少用户态/内核态数据搬运。所以这一篇可以用两句话收束native epoll 优化的是事件等待FileRegion / sendfile 优化的是文件数据搬运。它们不是 Netty 的全部但它们让 Netty 能更贴近操作系统能力支撑更高性能的网络系统。对我的架构判断有什么用这篇文章真正有价值的地方是把“高性能”拆成两个更可判断的问题连接事件如何被管理数据搬运如何被减少。对边缘侧、云端、媒体链路、大文件上传这类系统来说不能只问“用不用 epoll”“有没有零拷贝”。更应该先判断流量类型场景主要压力更关键的判断普通 HTTP 接口请求响应、下游调用、连接池是否阻塞 EventLoop超时和限流是否清晰MQTT 消息链路高频小消息、持续连接、消息风暴消费速度、反回环、队列边界、主题治理大文件上传磁盘/网络搬运、失败恢复是否和普通接口隔离是否支持分片/续传/限速媒体流链路持续带宽、弱网、编码兼容、慢客户端是否区分主画面/预览流是否能降级和限流静态文件/下载file - socket 搬运是否适合 sendfile / FileRegion是否受 TLS 影响所以我以后做架构判断时会把问题拆成几层这是连接数瓶颈还是数据搬运瓶颈是控制面流量、数据面流量还是媒体流量能否用 epoll/native transport 降低事件等待开销能否用流式传输、分片、对象存储直传或零拷贝减少 JVM 压力大文件和媒体流是否会拖垮普通业务接口底层优化之前是否已经把超时、限流、背压、隔离和降级做好这也是业务架构师视角和纯技术点学习的区别纯技术点会问 epoll 和 NIO 谁更快架构师要问这个系统到底卡在“等连接”、 “搬数据”、 “等下游”还是“业务模型没隔离”。