前几周有个读者在群里问一台 4C8G 的机器想撑住 5 万个长连接设备Java 到底行不行底下有人说“换 Go 吧”也有人直接贴了一段 Netty 的初始化代码。我的回复是先别急着换语言Netty 在 Java 生态里就是为这件事准备的问题往往不在语言而在你对 IO 模型的理解够不够深。这一次的打卡内容是 Day470 和 Day471主题是 Netty 概述和它的高性能架构设计。我会把这两天的学习内容按“问题 - 原理 - 代码 - 排障”的方式完整梳理一遍重点回答三个问题Netty 为什么快“快”是怎么落到线程模型、零拷贝、内存管理这些具体设计里的以及拿到真实项目里WebSocket 鉴权、物联网充电桩接入这类场景到底该怎么用。这篇内容适合刚接触 Netty、想系统入门的开发者也适合准备 Netty 面试或者正在做 IM、消息推送、物联网网关等长连接服务的同学。1. 先看传统 IO 的天花板Netty 到底解决了什么问题1.1 从一次网络请求的完整旅程说起很多初学者对 Netty 的第一印象是“一个很厉害的 NIO 框架”但到底厉害在哪说不清楚。要搞明白这个问题得先看看传统 BIOBlocking IO到底把性能堵死在哪里。我拿最典型的 ServerSocket 代码举例。服务端每来一个连接就accept()一个 Socket每处理一次读写线程就阻塞在read()上等数据。也就是说一个连接从建立到关闭基本要独占一条线程。代码写起来很直观但代价是线程的数量直接被连接数绑架了。ServerSocket serverSocket new ServerSocket(8080); while (true) { Socket socket serverSocket.accept(); // 阻塞等待连接 new Thread(() - { InputStream in socket.getInputStream(); byte[] buf new byte[1024]; while (in.read(buf) ! -1) { // 阻塞等待数据 // 业务处理 } }).start(); }这种模型的瓶颈非常明显一台普通机器能创建的线程数是有限的每条线程默认栈大小 1MB 左右哪怕不考虑 CPU 调度开销2 万个连接也需要 2 万条线程内存早就爆了。就算你用线程池限制到 500 条那 500 个连接之后的新连接只能排队吞吐量照样上不去。“C10K 问题”——1 万个并发连接就是在这种模型里被逼出来的。顺着这个思路往下想如果改成“一个线程处理多个连接”那不就可以用少量线程扛住海量连接了吗这正是 NIO 的核心思路。JDK 1.4 引入 NIO提供了 Selector 多路复用器让一个线程可以同时监听成千上万个 Channel 的事件。但光有 Selector 还不够如何在此基础上搭建一套稳定、易用的线程模型才是 Netty 真正解决的事情。1.2 为什么线程越多性能反而上不去有了线程池之后很多人觉得问题解决了连接照常 accept但处理任务丢给一个固定大小的线程池比如 200 个线程。这套“伪异步 IO”方案在连接数不多的时候确实能跑但压测一上量就会原形毕露。原因是底层的read()仍然是阻塞的。也就是说200 个线程里只要有 200 个连接同时处于“等数据”的状态这 200 条线程就全部阻塞在 read 上后面的任务只能在队列里排队。连接一多线程池任务队列积压越来越严重CPU 可能有空闲核心但请求就是处理不过来。我自己做过一个测试用伪异步模型去扛 5000 个长连接线程池 200结果大量连接超时GC 频繁线程栈里全是SocketInputStream.read。线程多不一定快因为线程切换本身也要消耗 CPU当大量线程都在“等”而不是“干”的时候增加线程数只会让系统花更多时间在做上下文切换而不是在执行业务逻辑。1.3 换个角度看把 NIO 想成一家餐厅如果你觉得 Selector 和事件循环有点抽象可以用餐厅来类比。BIO 模型相当于每个顾客配一个专属服务员服务员从顾客坐下来到离开全程一对一服务。这个方案的优点是服务很周到缺点是一个服务员只能服务一桌客人一多就得无限招人。伪异步 IO 相当于服务员总数固定但还是“一桌一个”客人等位就等着吧。NIO 模型则是另一套逻辑门口只有一个门迎负责把所有顾客领到空位上顾客要点菜时按一下桌上的铃后台几个服务员听到铃声谁有空谁过去处理顾客要结账再按铃服务员再过来一次。服务员不再从头到尾盯着一桌而是“按需响应事件”。这个门迎就是 Selector它负责不停地问每个连接“你有事件吗有的话我就通知对应的服务员去处理。”这就是事件驱动。Netty 做的事情是把这套“门迎 服务员按铃响应”的模型工程化、产品化并且把细节都优化到极致。理解了这一点接下来再看 Reactor 模型和 EventLoop就会顺很多。2. 高性能架构的核心引擎Reactor 模型与 EventLoop2.1 Reactor 三种模型的演进以及 Netty 选了什么Reactor 模式在 Doug Lea 的《Scalable IO in Java》里被系统讲过演进路径是单线程 - 多线程 - 主从多线程。Netty 对这套模型做了非常完整的落地。单线程 Reactor一个线程同时负责 accept 新连接、read 数据、write 数据。代码简单但一个线程扛不住大量连接的读写而且只要这个线程上有一个耗时操作所有连接全部卡住基本只适合演示。多线程 Reactor一个线程只负责 accept然后把读写事件交给一个 worker 线程池处理。和伪异步 IO 的区别是这里的读写不再阻塞等待而是事件来了一次处理一次处理完线程立刻释放所以不会被“等待中的连接”占满。主从多线程 Reactor有两组线程池一组叫 boss专门负责 accept 新连接另一组叫 worker负责已建立连接的读写事件。Netty 默认就是这种模型。好处很明显处理新连接的线程不会被现有连接的 IO 拖慢处理读写的线程也不会因为 accept 阻塞而停顿。用 Netty 初始化一个服务端你看到的代码是长这样的EventLoopGroup bossGroup new NioEventLoopGroup(1); EventLoopGroup workerGroup new NioEventLoopGroup(); ServerBootstrap bootstrap new ServerBootstrap(); bootstrap.group(bossGroup, workerGroup) .channel(NioServerSocketChannel.class) .option(ChannelOption.SO_BACKLOG, 1024) .childOption(ChannelOption.TCP_NODELAY, true) .childHandler(new ChannelInitializerSocketChannel() { Override protected void initChannel(SocketChannel ch) { ch.pipeline().addLast(new StringDecoder()); ch.pipeline().addLast(new StringEncoder()); ch.pipeline().addLast(new SimpleServerHandler()); } }); ChannelFuture future bootstrap.bind(8080).sync(); future.channel().closeFuture().sync();bossGroup 传入 1表示只有一个线程做 acceptworkerGroup 不传参数默认线程数是 CPU 核数的 2 倍。为什么是 2 倍而不是等于核数因为 Netty 默认假设一半时间在处理 IO 事件一半时间可能被其他事情打断2 倍可以在多数场景下把 CPU 用满。如果机器上有大量业务逻辑阻塞你可以通过-Dio.netty.eventLoopThreads调整但别盲目调大线程切换开销也会随之上升。2.2 EventLoop 与 Channel 的绑定为什么不用加锁理解了有两个线程组接下来要搞懂 EventLoop 是什么。简单说EventLoop 就是一个死循环从 Selector 里拿就绪事件逐个执行对应的任务。你可以把它理解成“一个线程 一个任务队列”。Netty 把 EventLoop 归属到某个线程上线程启动后所有注册到这个 EventLoop 上的事件都在这个线程里串行执行。这里有一个很关键的设计每个 Channel 一旦创建就会和一个 EventLoop 绑定后续这个 Channel 的所有 IO 事件、业务 handler 调用都只会在这一个 EventLoop 线程上执行。这就意味着同一个 Channel 内的多个事件处理天然是单线程串行的不需要像传统并发编程那样加锁。但这里有个隐患虽然同一个 Channel 是串行的一个 EventLoop 却会绑定很多个 Channel。假如你在某个 handler 里做了一个耗时的数据库查询或者Thread.sleep(1000)那这 1000 毫秒内所有绑在这个 EventLoop 上的其他 Channel 全都会被拖住。这也是 Netty 使用中最高频的坑——handler 里严禁做阻塞操作。耗时的逻辑要么扔到独立的业务线程池要么通过 MQ 异步解耦千万不要在 IO 线程里等。2.3 一个请求在 Netty 中的完整执行路径拿一个客户端发字符串消息的场景完整路径是这样的客户端连接到达后boss 线程 accept把这个连接封装成 NioSocketChannel并注册到某一个 worker 的 EventLoop 上然后 Netty 会自动执行initChannel里配置的 ChannelInitializer把一系列 handler 添加到这条 Channel 的 Pipeline 上。Pipeline 就像一个流水线。事件入站时从 head 开始按顺序经过每个 handler事件出站时从 tail 开始逆序经过每个 handler。比如我们上面配置的 Pipeline数据的流向是这样的head - StringDecoder - SimpleServerHandler - StringEncoder - tail如果客户端发来的是字节流会先被 StringDecoder 解码成字符串再进入业务 handler业务处理完成后如果调用ctx.writeAndFlush(response)字符串会从 tail 反向走到 StringEncoder编码成 ByteBuf最后写到 Socket。这种设计的好处是“拆装方便”你想加一个 MQTT 解码器就在 Pipeline 中插入一个 handler想加鉴权就再加一个 handler互不干扰。很多初学者以为 Netty 的 handler 是并行执行的其实不是。对于同一个 ChannelPipeline 上的执行是串行的、有顺序的。理解这一点非常重要因为你的业务逻辑如果依赖解码器处理完后的结果就必须把它放在解码器之后的 handler 里。3. 零拷贝与内存管理Netty 高性能的“第二板斧”3.1 传统 IO 的四次拷贝到底浪费在哪除了线程模型Netty 高性能的另一个核心点是减少不必要的数据拷贝。传统 IO 在“文件 - 网络”这条链路上数据要经历四次拷贝磁盘数据通过 DMA 拷贝到内核缓冲区CPU 把内核缓冲区数据拷贝到用户空间缓冲区CPU 把用户空间缓冲区数据拷贝到 Socket 发送缓冲区DMA 把 Socket 发送缓冲区数据拷贝到网卡。每一步拷贝都消耗 CPU 和内存带宽尤其是第 2、3 步数据从内核态到用户态来回穿梭纯属浪费——因为中间只是透传并没有做任何加工。Linux 后来提供了sendfile()系统调用可以跳过用户空间让数据直接从内核缓冲区到 Socket 缓冲区这就是“零拷贝”这个说法的来源。严格来说不是零次拷贝而是把拷贝次数从四次降到两次真正省掉了用户态参与的那两次。Netty 中对应的用法是FileRegion。通过FileRegion配合NioSocketChannel底层会尝试走transferTo()把文件内容直接发出去不需要你在用户态把整个文件读成 byte[] 再写出去。对大文件传输场景效果非常明显。3.2 Netty 里的零拷贝落地CompositeByteBuf、FileRegion 与 Direct BufferNetty 的零拷贝比操作系统层面的“sendfile 零拷贝”含义更宽它还包含“避免无意义的 Buffer 复制”和“避免堆内堆外来回倒腾”。具体来说有三个点。第一个是CompositeByteBuf。你收到一个消息可能被拆成了多个 ByteBuf如果想把它们拼成一个完整的消息再解析传统做法是新开一个 byte[]把几段数据 copy 进去。CompositeByteBuf 做的事情是把多个 ByteBuf 组合成一个逻辑上的 ByteBuf读取时像操作一个缓冲区一样但底层没有发生真正的数据复制。对拆包很频繁的接收端来说省掉的复制量很可观。第二个是FileRegion。前面刚提过它底层走 sendfile适合“文件内容直接下发给客户端”这种场景。如果你的服务要支持客户端下载文件别用FileInputStream.read把文件整个读进内存直接FileRegion写出去。第三个是Direct Buffer也就是堆外内存。在 Java 里用普通 byte[] 创建 ByteBuf数据存在堆内而堆内数据在通过 Socket 发送时底层还是需要复制到堆外的 DirectByteBuffer 才能交给操作系统。Netty 默认使用的 PooledByteBufAllocator 会优先分配堆外内存数据从网卡到用户态的过程中尽量不经过堆内减少一次复制也减轻 GC 的压力。代价是堆外内存不归 GC 管分配和释放都需要你手动负责这块非常容易出问题。3.3 容易被忽略的坑堆外内存不及时释放很多新手用 Netty 写 demo 时不会遇到问题一上生产就频繁内存告警最常见的根因就是 ByteBuf 没释放。Netty 的 ByteBuf 是引用计数的。你在 handler 里收到一个ByteBuf如果用完了要调用ReferenceCountUtil.release(msg)或者msg.release()释放如果要把消息继续传给后面的 handler则不能贸然 release。而SimpleChannelInboundHandler之所以方便是因为它在channelRead0执行完后会自动释放消息你不需要管。如果继承的是ChannelInboundHandlerAdapter就要自己显式管理。这里我建议你按下面这个规则来继承SimpleChannelInboundHandlerT框架帮你释放业务里别乱调 release继承ChannelInboundHandlerAdapter要么在 finally 里 release要么明确ctx.fireChannelRead(msg)继续传递、由下一个 handler 处理把消息写成响应时写出的 ByteBuf 会在发送完成后由 Netty 负责释放不需要你手动 release。排查内存泄漏时可以在启动参数里加-Dio.netty.leakDetection.levelparanoid。开启后如果哪里忘记 release日志里会打出详细的分配堆栈一下子就能定位到泄漏位置。这个参数我建议在测试和压测环境一定要开生产环境可以降到 simple 级别减少性能损耗。4. 高并发下的“暗礁”粘包拆包与自定义协议设计4.1 粘包拆包是怎么产生的很多人第一次接触 Netty 时的练习题就是“实现一个聊天室”一跑通就以为 Netty 会在底层帮你把消息切好。其实不会。TCP 是面向字节流的协议它只负责把字节可靠地从一端传到另一端并不关心你发的是什么消息。你调用两次writeTCP 可能把两段数据合并成一段发送你调用一次writeTCP 也可能因为网络原因把数据拆成多次发送。这就是粘包和拆包的本质粘包是接收方一次读到多条应用消息拆包是一条应用消息被分成了多次读到。原因包括 Nagle 算法开启、网络拥塞、接收缓冲区大小不足等等。解决思路就一个应用层必须定义自己的消息边界接收端根据这个边界把字节流切分成一条条完整的消息。在 Netty 里这个工作交给各类ByteToMessageDecoder。关于 Nagle 算法多说一句它会把小包合并成大包再发送目的是减少网络中小包数量但对低延迟应用很不友好。做即时通信或物联网长连接时一般会在childOption里设置TCP_NODELAYtrue关闭 Nagle 算法避免消息被故意“攒着”不发。我在实际项目里遇到过客户端发了消息迟迟不到服务端的情况最后发现就是 Nagle 和接收端 Delayed ACK 互相作用导致的延迟。4.2 内置拆包器怎么选四种 FrameDecoder 对比Netty 内置了多种拆包器选择标准其实很简单看你的协议长什么样。拆包器适合场景协议示例LineBasedFrameDecoder按行分隔的文本协议msg\n或msg\r\nDelimiterBasedFrameDecoder自定义分隔符msg$$$FixedLengthFrameDecoder固定报文长度每条消息都是 16 字节LengthFieldBasedFrameDecoder二进制协议长度前缀[长度][类型][数据]如果协议是类似 Redis 那种以\r\n结尾的文本协议LineBasedFrameDecoder最省事。DelimiterBasedFrameDecoder更灵活可以用任意字节序列作为分隔符。FixedLengthFrameDecoder适合嵌入式设备那种规规矩矩的定长报文但业务扩展时比较痛苦。大部分互联网场景尤其是自定义二进制协议都会用LengthFieldBasedFrameDecoder因为它把长度信息放在头部解析效率高而且能天然规避分隔符转义问题——你的 payload 里就算出现了“分隔符”字样也不影响切割。选择拆包器时要时刻记着一句话拆包器只负责“把一条完整的消息切出来”不负责“把字节解析成 Java 对象”。切割之后的解析还需要你再写一个ByteToMessageDecoder或直接交给业务 handler 处理。4.3 LengthFieldBasedFrameDecoder 实战4 字节长度头协议我举一个很常见的自定义协议消息格式为len(4字节) type(1字节) payload(N字节)。其中 len 表示 typepayload 的总长度也就是“后面还有多少字节”。用 LengthFieldBasedFrameDecoder 时需要想清楚五个参数maxFrameLength最大帧长度超过会抛TooLongFrameException防止恶意大包。lengthFieldOffset长度字段偏移量我们这里长度字段在开头所以是 0。lengthFieldLength长度字段占几个字节这里 4。lengthAdjustment读完长度字段后跳到真正的数据开始处需要额外偏移多少字节。长度字段占 4 字节len 本身表示 typepayload 的长度读完后指针停在索引 4 的位置而真正的业务数据从索引 5 才开始中间还隔了 1 字节 type所以 lengthAdjustment 是 1。initialBytesToStrip解析后剥离掉前面几个字节。如果把长度头剥掉就设 4。如果你希望后面的 handler 连 type 一起收到就剥 4如果只想让 handler 收 payload就剥 5。ch.pipeline().addLast(new LengthFieldBasedFrameDecoder( 1024 * 1024, // maxFrameLength假设最大 1MB 0, // lengthFieldOffset 4, // lengthFieldLength 1, // lengthAdjustment 4 // initialBytesToStrip ));假设客户端发送的字节是00 00 00 05 01 68 65 6C 6C 6F其中00 00 00 05是长度01是 typehello是 payload。经过上面的 decoder 后业务 handler 收到的字节是01 68 65 6C 6C 6F也就是 type payload。如果配置initialBytesToStrip5收到的就是纯 payload68 65 6C 6C 6F。这里最大的坑是 lengthAdjustment 算错。很多人在协议里用“len 只表示 payload 长度后面还有 type 字段”时以为 lengthAdjustment 为 0结果解析出的数据永远多了或者少了几个字节。记住一个原则它表示的是“从长度字段结束的位置到真正的业务数据内容开始的位置还差多少字节”。长度字段结束在索引 4业务内容从索引 5 开始差 1就是 1。5. 从原理到实战WebSocket 鉴权和充电桩接入怎么落地5.1 WebSocket 鉴权的正确位置握手前而不是握手后“Netty WebSocket 怎么做鉴权”是很高频的搜索词。很多人的做法是先让 WebSocket 连接建立成功然后在业务层收到第一条消息时再校验 token不对就关连接。这样虽然能工作但代价是未经认证的连接已经建立了一些攻击者可以借此占住连接资源。更合理的做法是在握手阶段就做鉴权。WebSocket 的握手本质上是一个带Upgrade: websocket头的 HTTP 请求所以你必须让HttpServerCodec先处理握手再在它之后、WebSocketServerProtocolHandler之前插入一个鉴权 handler拦截握手阶段的HttpRequest。校验通过就fireChannelRead放行让握手流程继续校验失败就返回 401 并关闭连接。public class WsAuthHandler extends ChannelInboundHandlerAdapter { Override public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception { if (msg instanceof HttpRequest) { HttpRequest req (HttpRequest) msg; String token req.headers().get(X-Auth-Token); if (token null) { QueryStringDecoder decoder new QueryStringDecoder(req.uri()); token decoder.parameters().get(token) null ? null : decoder.parameters().get(token).get(0); } if (!checkToken(token)) { FullHttpResponse resp new DefaultFullHttpResponse( HTTP_1_1, HttpResponseStatus.UNAUTHORIZED, Unpooled.copiedBuffer(unauthorized, CharsetUtil.UTF_8)); ctx.writeAndFlush(resp).addListener(ChannelFutureListener.CLOSE); return; } } ctx.fireChannelRead(msg); } }Pipeline 配置顺序ch.pipeline().addLast(new HttpServerCodec()); ch.pipeline().addLast(new WsAuthHandler()); ch.pipeline().addLast(new WebSocketServerProtocolHandler(/ws)); ch.pipeline().addLast(new TextWebSocketFrameHandler());这里有个细节要提醒如果鉴权 handler 里要做 JWT 签名校验或者查 Redis不要在 EventLoop 线程里同步执行。握手阶段本来就会挤占 IO 线程你再去查一次 Redis整个 EventLoop 上的其他连接都会被拖慢。正确做法是做成异步校验或者把校验结果缓存起来提前把 token 对应的用户信息加载到本地缓存EventLoop 里只做纯内存判断。5.2 SpringBoot 3.x Netty MQTT智能充电桩接入的经典拆法物联网充电桩这类场景设备数量多、网络不稳定、数据上报频繁特别适合用 Netty 来做接入层。一个比较经典的架构是充电桩通过 TCP 长连接接入 Netty 服务端Netty 解析设备报文后转发给 MQTT BrokerSpringBoot 业务系统订阅 MQTT 主题处理计量、计费、告警等业务逻辑。也可以让 Netty 直接实现 MQTT 协议的解码器但工程上往往直接借助现成的 MQTT Broker自己只负责设备接入和协议翻译。为什么中间要加一个 MQTT Broker因为 Netty 适合维护海量长连接但它本身不擅长做“消息持久化”“发布订阅路由”“QoS 保证”这套事情。充电桩上报一条充电记录可能同时要被计费服务、监控服务、用户通知服务消费如果全在 Netty 里点对点转发代码会非常混乱。引入 MQTT 后Netty 把设备数据发布到指定主题多个业务服务各自订阅互不干扰扩展性会好很多。在一个快速开发平台里集成 Netty 时比如在 JeecgBoot 项目里加消息推送模块我的建议是不要把 Netty 代码直接塞进 Web 项目的 Controller 里而是单独开一个netty-server的模块或服务。Netty 连接维护和 Web 业务周期差异很大混在一起容易相互影响。用ChannelGroup统一管理在线连接业务侧需要推送时通过 Spring 事件或者 Redis 发布订阅触发 Netty 服务端的写入接口这样 Web 层和 Netty 层只通过消息解耦。public class PushServer { private final ChannelGroup clients new DefaultChannelGroup(GlobalEventExecutor.INSTANCE); public void sendToAll(String message) { clients.writeAndFlush(Unpooled.copiedBuffer(message, CharsetUtil.UTF_8)); } ChannelHandler.Sharable public class ServerHandler extends SimpleChannelInboundHandlerString { Override protected void channelRead0(ChannelHandlerContext ctx, String msg) { // 处理设备上报 } Override public void channelActive(ChannelHandlerContext ctx) { clients.add(ctx.channel()); } Override public void channelInactive(ChannelHandlerContext ctx) { clients.remove(ctx.channel()); } } }5.3 心跳、重连、幂等长连接系统绕不开的三个工程细节真正上线一套长连接系统不能只看能不能连上。我这几年最大的感受是连接建立只是开始连接能不能稳定保持、断开后能不能快速恢复、重复消息能不能正确处理才是线上稳定性的分水岭。心跳保活是第一个要做的。Netty 提供了IdleStateHandler可以定期检测连接的读写空闲情况。比如充电桩每 30 秒上报一次状态那就设置读空闲 60 秒判定为异常连接触发IdleStateEvent后主动关闭。配套的逻辑是服务端读空闲超时 close客户端如果 45 秒没收到服务端任何消息就主动发心跳两边配合才能把一半开着的死连接及时清掉。ch.pipeline().addLast(idle, new IdleStateHandler(60, 0, 0, TimeUnit.SECONDS)); public class HeartbeatHandler extends ChannelInboundHandlerAdapter { Override public void userEventTriggered(ChannelHandlerContext ctx, Object evt) throws Exception { if (evt instanceof IdleStateEvent) { ctx.close(); // 读空闲超时主动断开 } else { super.userEventTriggered(ctx, evt); } } }断线重连要做成指数退避。很多设备掉线后在同一时刻疯狂重连会造成“重连风暴”把服务端打挂。我常用的策略是 1 秒、2 秒、4 秒、8 秒……最大 60 秒每次重连间隔加一点随机抖动避免所有设备同步重连。服务端收到重连请求时通过设备 ID 找到旧连接并 close防止同一设备多连接造成状态错乱。幂等也必须在设计协议时就考虑好。充电桩因为网络抖动很可能把同一条充电记录上报了两次。业务侧要在消费 MQTT 消息时做去重最常用的方式是给每条消息一个唯一 ID消费时用 Redis SETNX 或者数据库唯一索引拦截重复消息。否则就会出现用户充一次电被扣两次费的事故这种问题一旦发生补救成本极高。6. 高频面试题与线上排查技巧实录6.1 面试被问“Netty 为什么快”用一条主线答完整Netty 面试题经常被问到一个开放性题目“说说 Netty 为什么性能这么高”很多人的回答是堆名词NIO、零拷贝、多路复用、内存池。但面试官想听到的是一条有逻辑的主线。我建议你用这条线来答首先是 IO 模型Netty 基于 NIO 和事件驱动一个线程通过 Selector 监听大量连接不用每个连接开一个线程其次是线程模型主从 Reactor 模型把 accept 和 IO 读写的线程分开管理避免了线程上下文切换和连接数对线程数的绑架再次是零拷贝通过 FileRegion、CompositeByteBuf、Direct Buffer 减少了数据复制然后是内存池Netty 用 PooledByteBufAllocator 复用缓冲区减少了 GC 压力和频繁分配内存的开销最后是 Pipeline把协议编解码和业务处理做成一条可插拔的流水线扩展性和可维护性都很强。如果面试官追问细节可以补充这几个点Netty 使用 FastThreadLocal 替代普通的 ThreadLocal减少了并发访问开销它的线程模型保证同一个 Channel 的事件都在同一个线程执行避免了锁竞争它还针对 Linux 做了很多 epoll 优化比如EpollEventLoopGroup、边缘触发等性能比 JDK NIO 原生实现更好。就怕你记住了一堆名词却答不出它们分别解决了什么问题。面试官连续追问“零拷贝到底是怎么实现的”“为什么要用堆外内存”时只有真正理解原理的人才能稳住。6.2 线上三类高频问题的排查手段线上用 Netty 最容易踩的坑其实比较集中我按出现频率排一下。第一类是内存泄漏尤其是堆外内存泄漏。现象是Direct buffer memoryOOM或者 Java 进程占用的系统内存持续上涨最后被操作系统杀掉。排障第一步是开启 Netty 的内存泄漏检测日志里会打印泄漏点的分配堆栈。另外可以通过jmap -histo:live看 DirectByteBuffer 的实例数量如果数量持续增长基本可以确定有 ByteBuf 没释放。这种问题在测试环境不出现是因为并发量低时泄漏速度慢内存还没被耗尽。第二类是 EventLoop 线程被阻塞。现象是某一个客户端请求很慢经过排查发现其他很多连接也一起变慢。用jstack看线程栈如果发现nioEventLoopGroup-3-1线程上出现了Socket.read之外的耗时调用、锁等待、Thread.sleep那就是在 handler 里写了阻塞逻辑。解法是把耗时操作移到独立线程池或者用异步 IO。Netty 日志里如果出现blocked-the-thread相关告警基本就是这个原因。第三类是“半开连接”太多也就是连接在操作系统层面还存在但设备其实已经断网了。现象是服务端连接数一直在涨但活跃用户没那么多。解法就是前面说的IdleStateHandler心跳检测配合netstat -an | grep ESTABLISHED看连接状态一旦发现大量空闲连接就要检查心跳周期和超时时间是否合理。6.3 快查表现象、原因、处理对照现象可能原因排查手段与处理方向客户端收到完整消息总是乱掉没有配置拆包器或拆包参数错误检查 Pipeline 中是否加了 FrameDecoder重点看 lengthAdjustment连接建立后收不到任何数据NIO 的读事件没被触发或 IdleStateHandler 误判抓包看 TCP 层是否有数据检查 pipeline 顺序一个慢请求拖垮其他连接EventLoop 被业务代码阻塞jstack 定位线程栈耗时逻辑移到业务线程池Direct buffer memory OOMByteBuf 未释放开启 leakDetection检查 ChannelInboundHandlerAdapter 中是否有 release连接数持续增长心跳检测缺失或超时过长配置 IdleStateHandler读空闲主动 close大量设备同时掉线后重连风暴重连间隔固定没有抖动指数退避 随机抖动服务端限制单设备连接数业务重复计费消息重复上报消息唯一 ID Redis SETNX 或数据库唯一索引去重大文件传输内存爆掉用 byte[] 读文件再发送改用 FileRegion 走 sendfile这张表是我在维护长连接服务时总结的每次线上出问题我都会先对着看一遍。绝大部分 Netty 相关的“疑难杂症”最后都能归到这几个根因。再说一个经验Netty 自带的内存泄漏检测在测试和压测环境一定要开到 paranoid 级别生产环境至少保持 simple。很多线上内存问题之所以难查就是因为没开检测等到 OOM 时日志已经被冲掉了。日志里能打印出泄漏的分配堆栈这个问题就能变成一个顺藤摸瓜的简单问题。我个人做长连接服务这几年的体会是Netty 的性能优势说白了来自两件事一是用事件驱动替代线程阻塞把“等”这种浪费 CPU 的行为去掉二是尽可能减少数据的无意义复制让内存和带宽都花在刀刃上。这两点想透了再看源码就不会晕。如果你正打算学别一上来就死磕源码建议先在本地把线程模型、Pipeline、拆包器这几个点跑通再回到原理部分对照着看。最后可以自己做一个带鉴权、心跳、粘包处理的 WebSocket 服务把内部机制真正用出来一次比什么都管用。
前几周有个读者在群里问一台 4C8G 的机器想撑住 5 万个长连接设备Java 到底行不行底下有人说“换 Go 吧”也有人直接贴了一段 Netty 的初始化代码。我的回复是先别急着换语言Netty 在 Java 生态里就是为这件事准备的问题往往不在语言而在你对 IO 模型的理解够不够深。这一次的打卡内容是 Day470 和 Day471主题是 Netty 概述和它的高性能架构设计。我会把这两天的学习内容按“问题 - 原理 - 代码 - 排障”的方式完整梳理一遍重点回答三个问题Netty 为什么快“快”是怎么落到线程模型、零拷贝、内存管理这些具体设计里的以及拿到真实项目里WebSocket 鉴权、物联网充电桩接入这类场景到底该怎么用。这篇内容适合刚接触 Netty、想系统入门的开发者也适合准备 Netty 面试或者正在做 IM、消息推送、物联网网关等长连接服务的同学。1. 先看传统 IO 的天花板Netty 到底解决了什么问题1.1 从一次网络请求的完整旅程说起很多初学者对 Netty 的第一印象是“一个很厉害的 NIO 框架”但到底厉害在哪说不清楚。要搞明白这个问题得先看看传统 BIOBlocking IO到底把性能堵死在哪里。我拿最典型的 ServerSocket 代码举例。服务端每来一个连接就accept()一个 Socket每处理一次读写线程就阻塞在read()上等数据。也就是说一个连接从建立到关闭基本要独占一条线程。代码写起来很直观但代价是线程的数量直接被连接数绑架了。ServerSocket serverSocket new ServerSocket(8080); while (true) { Socket socket serverSocket.accept(); // 阻塞等待连接 new Thread(() - { InputStream in socket.getInputStream(); byte[] buf new byte[1024]; while (in.read(buf) ! -1) { // 阻塞等待数据 // 业务处理 } }).start(); }这种模型的瓶颈非常明显一台普通机器能创建的线程数是有限的每条线程默认栈大小 1MB 左右哪怕不考虑 CPU 调度开销2 万个连接也需要 2 万条线程内存早就爆了。就算你用线程池限制到 500 条那 500 个连接之后的新连接只能排队吞吐量照样上不去。“C10K 问题”——1 万个并发连接就是在这种模型里被逼出来的。顺着这个思路往下想如果改成“一个线程处理多个连接”那不就可以用少量线程扛住海量连接了吗这正是 NIO 的核心思路。JDK 1.4 引入 NIO提供了 Selector 多路复用器让一个线程可以同时监听成千上万个 Channel 的事件。但光有 Selector 还不够如何在此基础上搭建一套稳定、易用的线程模型才是 Netty 真正解决的事情。1.2 为什么线程越多性能反而上不去有了线程池之后很多人觉得问题解决了连接照常 accept但处理任务丢给一个固定大小的线程池比如 200 个线程。这套“伪异步 IO”方案在连接数不多的时候确实能跑但压测一上量就会原形毕露。原因是底层的read()仍然是阻塞的。也就是说200 个线程里只要有 200 个连接同时处于“等数据”的状态这 200 条线程就全部阻塞在 read 上后面的任务只能在队列里排队。连接一多线程池任务队列积压越来越严重CPU 可能有空闲核心但请求就是处理不过来。我自己做过一个测试用伪异步模型去扛 5000 个长连接线程池 200结果大量连接超时GC 频繁线程栈里全是SocketInputStream.read。线程多不一定快因为线程切换本身也要消耗 CPU当大量线程都在“等”而不是“干”的时候增加线程数只会让系统花更多时间在做上下文切换而不是在执行业务逻辑。1.3 换个角度看把 NIO 想成一家餐厅如果你觉得 Selector 和事件循环有点抽象可以用餐厅来类比。BIO 模型相当于每个顾客配一个专属服务员服务员从顾客坐下来到离开全程一对一服务。这个方案的优点是服务很周到缺点是一个服务员只能服务一桌客人一多就得无限招人。伪异步 IO 相当于服务员总数固定但还是“一桌一个”客人等位就等着吧。NIO 模型则是另一套逻辑门口只有一个门迎负责把所有顾客领到空位上顾客要点菜时按一下桌上的铃后台几个服务员听到铃声谁有空谁过去处理顾客要结账再按铃服务员再过来一次。服务员不再从头到尾盯着一桌而是“按需响应事件”。这个门迎就是 Selector它负责不停地问每个连接“你有事件吗有的话我就通知对应的服务员去处理。”这就是事件驱动。Netty 做的事情是把这套“门迎 服务员按铃响应”的模型工程化、产品化并且把细节都优化到极致。理解了这一点接下来再看 Reactor 模型和 EventLoop就会顺很多。2. 高性能架构的核心引擎Reactor 模型与 EventLoop2.1 Reactor 三种模型的演进以及 Netty 选了什么Reactor 模式在 Doug Lea 的《Scalable IO in Java》里被系统讲过演进路径是单线程 - 多线程 - 主从多线程。Netty 对这套模型做了非常完整的落地。单线程 Reactor一个线程同时负责 accept 新连接、read 数据、write 数据。代码简单但一个线程扛不住大量连接的读写而且只要这个线程上有一个耗时操作所有连接全部卡住基本只适合演示。多线程 Reactor一个线程只负责 accept然后把读写事件交给一个 worker 线程池处理。和伪异步 IO 的区别是这里的读写不再阻塞等待而是事件来了一次处理一次处理完线程立刻释放所以不会被“等待中的连接”占满。主从多线程 Reactor有两组线程池一组叫 boss专门负责 accept 新连接另一组叫 worker负责已建立连接的读写事件。Netty 默认就是这种模型。好处很明显处理新连接的线程不会被现有连接的 IO 拖慢处理读写的线程也不会因为 accept 阻塞而停顿。用 Netty 初始化一个服务端你看到的代码是长这样的EventLoopGroup bossGroup new NioEventLoopGroup(1); EventLoopGroup workerGroup new NioEventLoopGroup(); ServerBootstrap bootstrap new ServerBootstrap(); bootstrap.group(bossGroup, workerGroup) .channel(NioServerSocketChannel.class) .option(ChannelOption.SO_BACKLOG, 1024) .childOption(ChannelOption.TCP_NODELAY, true) .childHandler(new ChannelInitializerSocketChannel() { Override protected void initChannel(SocketChannel ch) { ch.pipeline().addLast(new StringDecoder()); ch.pipeline().addLast(new StringEncoder()); ch.pipeline().addLast(new SimpleServerHandler()); } }); ChannelFuture future bootstrap.bind(8080).sync(); future.channel().closeFuture().sync();bossGroup 传入 1表示只有一个线程做 acceptworkerGroup 不传参数默认线程数是 CPU 核数的 2 倍。为什么是 2 倍而不是等于核数因为 Netty 默认假设一半时间在处理 IO 事件一半时间可能被其他事情打断2 倍可以在多数场景下把 CPU 用满。如果机器上有大量业务逻辑阻塞你可以通过-Dio.netty.eventLoopThreads调整但别盲目调大线程切换开销也会随之上升。2.2 EventLoop 与 Channel 的绑定为什么不用加锁理解了有两个线程组接下来要搞懂 EventLoop 是什么。简单说EventLoop 就是一个死循环从 Selector 里拿就绪事件逐个执行对应的任务。你可以把它理解成“一个线程 一个任务队列”。Netty 把 EventLoop 归属到某个线程上线程启动后所有注册到这个 EventLoop 上的事件都在这个线程里串行执行。这里有一个很关键的设计每个 Channel 一旦创建就会和一个 EventLoop 绑定后续这个 Channel 的所有 IO 事件、业务 handler 调用都只会在这一个 EventLoop 线程上执行。这就意味着同一个 Channel 内的多个事件处理天然是单线程串行的不需要像传统并发编程那样加锁。但这里有个隐患虽然同一个 Channel 是串行的一个 EventLoop 却会绑定很多个 Channel。假如你在某个 handler 里做了一个耗时的数据库查询或者Thread.sleep(1000)那这 1000 毫秒内所有绑在这个 EventLoop 上的其他 Channel 全都会被拖住。这也是 Netty 使用中最高频的坑——handler 里严禁做阻塞操作。耗时的逻辑要么扔到独立的业务线程池要么通过 MQ 异步解耦千万不要在 IO 线程里等。2.3 一个请求在 Netty 中的完整执行路径拿一个客户端发字符串消息的场景完整路径是这样的客户端连接到达后boss 线程 accept把这个连接封装成 NioSocketChannel并注册到某一个 worker 的 EventLoop 上然后 Netty 会自动执行initChannel里配置的 ChannelInitializer把一系列 handler 添加到这条 Channel 的 Pipeline 上。Pipeline 就像一个流水线。事件入站时从 head 开始按顺序经过每个 handler事件出站时从 tail 开始逆序经过每个 handler。比如我们上面配置的 Pipeline数据的流向是这样的head - StringDecoder - SimpleServerHandler - StringEncoder - tail如果客户端发来的是字节流会先被 StringDecoder 解码成字符串再进入业务 handler业务处理完成后如果调用ctx.writeAndFlush(response)字符串会从 tail 反向走到 StringEncoder编码成 ByteBuf最后写到 Socket。这种设计的好处是“拆装方便”你想加一个 MQTT 解码器就在 Pipeline 中插入一个 handler想加鉴权就再加一个 handler互不干扰。很多初学者以为 Netty 的 handler 是并行执行的其实不是。对于同一个 ChannelPipeline 上的执行是串行的、有顺序的。理解这一点非常重要因为你的业务逻辑如果依赖解码器处理完后的结果就必须把它放在解码器之后的 handler 里。3. 零拷贝与内存管理Netty 高性能的“第二板斧”3.1 传统 IO 的四次拷贝到底浪费在哪除了线程模型Netty 高性能的另一个核心点是减少不必要的数据拷贝。传统 IO 在“文件 - 网络”这条链路上数据要经历四次拷贝磁盘数据通过 DMA 拷贝到内核缓冲区CPU 把内核缓冲区数据拷贝到用户空间缓冲区CPU 把用户空间缓冲区数据拷贝到 Socket 发送缓冲区DMA 把 Socket 发送缓冲区数据拷贝到网卡。每一步拷贝都消耗 CPU 和内存带宽尤其是第 2、3 步数据从内核态到用户态来回穿梭纯属浪费——因为中间只是透传并没有做任何加工。Linux 后来提供了sendfile()系统调用可以跳过用户空间让数据直接从内核缓冲区到 Socket 缓冲区这就是“零拷贝”这个说法的来源。严格来说不是零次拷贝而是把拷贝次数从四次降到两次真正省掉了用户态参与的那两次。Netty 中对应的用法是FileRegion。通过FileRegion配合NioSocketChannel底层会尝试走transferTo()把文件内容直接发出去不需要你在用户态把整个文件读成 byte[] 再写出去。对大文件传输场景效果非常明显。3.2 Netty 里的零拷贝落地CompositeByteBuf、FileRegion 与 Direct BufferNetty 的零拷贝比操作系统层面的“sendfile 零拷贝”含义更宽它还包含“避免无意义的 Buffer 复制”和“避免堆内堆外来回倒腾”。具体来说有三个点。第一个是CompositeByteBuf。你收到一个消息可能被拆成了多个 ByteBuf如果想把它们拼成一个完整的消息再解析传统做法是新开一个 byte[]把几段数据 copy 进去。CompositeByteBuf 做的事情是把多个 ByteBuf 组合成一个逻辑上的 ByteBuf读取时像操作一个缓冲区一样但底层没有发生真正的数据复制。对拆包很频繁的接收端来说省掉的复制量很可观。第二个是FileRegion。前面刚提过它底层走 sendfile适合“文件内容直接下发给客户端”这种场景。如果你的服务要支持客户端下载文件别用FileInputStream.read把文件整个读进内存直接FileRegion写出去。第三个是Direct Buffer也就是堆外内存。在 Java 里用普通 byte[] 创建 ByteBuf数据存在堆内而堆内数据在通过 Socket 发送时底层还是需要复制到堆外的 DirectByteBuffer 才能交给操作系统。Netty 默认使用的 PooledByteBufAllocator 会优先分配堆外内存数据从网卡到用户态的过程中尽量不经过堆内减少一次复制也减轻 GC 的压力。代价是堆外内存不归 GC 管分配和释放都需要你手动负责这块非常容易出问题。3.3 容易被忽略的坑堆外内存不及时释放很多新手用 Netty 写 demo 时不会遇到问题一上生产就频繁内存告警最常见的根因就是 ByteBuf 没释放。Netty 的 ByteBuf 是引用计数的。你在 handler 里收到一个ByteBuf如果用完了要调用ReferenceCountUtil.release(msg)或者msg.release()释放如果要把消息继续传给后面的 handler则不能贸然 release。而SimpleChannelInboundHandler之所以方便是因为它在channelRead0执行完后会自动释放消息你不需要管。如果继承的是ChannelInboundHandlerAdapter就要自己显式管理。这里我建议你按下面这个规则来继承SimpleChannelInboundHandlerT框架帮你释放业务里别乱调 release继承ChannelInboundHandlerAdapter要么在 finally 里 release要么明确ctx.fireChannelRead(msg)继续传递、由下一个 handler 处理把消息写成响应时写出的 ByteBuf 会在发送完成后由 Netty 负责释放不需要你手动 release。排查内存泄漏时可以在启动参数里加-Dio.netty.leakDetection.levelparanoid。开启后如果哪里忘记 release日志里会打出详细的分配堆栈一下子就能定位到泄漏位置。这个参数我建议在测试和压测环境一定要开生产环境可以降到 simple 级别减少性能损耗。4. 高并发下的“暗礁”粘包拆包与自定义协议设计4.1 粘包拆包是怎么产生的很多人第一次接触 Netty 时的练习题就是“实现一个聊天室”一跑通就以为 Netty 会在底层帮你把消息切好。其实不会。TCP 是面向字节流的协议它只负责把字节可靠地从一端传到另一端并不关心你发的是什么消息。你调用两次writeTCP 可能把两段数据合并成一段发送你调用一次writeTCP 也可能因为网络原因把数据拆成多次发送。这就是粘包和拆包的本质粘包是接收方一次读到多条应用消息拆包是一条应用消息被分成了多次读到。原因包括 Nagle 算法开启、网络拥塞、接收缓冲区大小不足等等。解决思路就一个应用层必须定义自己的消息边界接收端根据这个边界把字节流切分成一条条完整的消息。在 Netty 里这个工作交给各类ByteToMessageDecoder。关于 Nagle 算法多说一句它会把小包合并成大包再发送目的是减少网络中小包数量但对低延迟应用很不友好。做即时通信或物联网长连接时一般会在childOption里设置TCP_NODELAYtrue关闭 Nagle 算法避免消息被故意“攒着”不发。我在实际项目里遇到过客户端发了消息迟迟不到服务端的情况最后发现就是 Nagle 和接收端 Delayed ACK 互相作用导致的延迟。4.2 内置拆包器怎么选四种 FrameDecoder 对比Netty 内置了多种拆包器选择标准其实很简单看你的协议长什么样。拆包器适合场景协议示例LineBasedFrameDecoder按行分隔的文本协议msg\n或msg\r\nDelimiterBasedFrameDecoder自定义分隔符msg$$$FixedLengthFrameDecoder固定报文长度每条消息都是 16 字节LengthFieldBasedFrameDecoder二进制协议长度前缀[长度][类型][数据]如果协议是类似 Redis 那种以\r\n结尾的文本协议LineBasedFrameDecoder最省事。DelimiterBasedFrameDecoder更灵活可以用任意字节序列作为分隔符。FixedLengthFrameDecoder适合嵌入式设备那种规规矩矩的定长报文但业务扩展时比较痛苦。大部分互联网场景尤其是自定义二进制协议都会用LengthFieldBasedFrameDecoder因为它把长度信息放在头部解析效率高而且能天然规避分隔符转义问题——你的 payload 里就算出现了“分隔符”字样也不影响切割。选择拆包器时要时刻记着一句话拆包器只负责“把一条完整的消息切出来”不负责“把字节解析成 Java 对象”。切割之后的解析还需要你再写一个ByteToMessageDecoder或直接交给业务 handler 处理。4.3 LengthFieldBasedFrameDecoder 实战4 字节长度头协议我举一个很常见的自定义协议消息格式为len(4字节) type(1字节) payload(N字节)。其中 len 表示 typepayload 的总长度也就是“后面还有多少字节”。用 LengthFieldBasedFrameDecoder 时需要想清楚五个参数maxFrameLength最大帧长度超过会抛TooLongFrameException防止恶意大包。lengthFieldOffset长度字段偏移量我们这里长度字段在开头所以是 0。lengthFieldLength长度字段占几个字节这里 4。lengthAdjustment读完长度字段后跳到真正的数据开始处需要额外偏移多少字节。长度字段占 4 字节len 本身表示 typepayload 的长度读完后指针停在索引 4 的位置而真正的业务数据从索引 5 才开始中间还隔了 1 字节 type所以 lengthAdjustment 是 1。initialBytesToStrip解析后剥离掉前面几个字节。如果把长度头剥掉就设 4。如果你希望后面的 handler 连 type 一起收到就剥 4如果只想让 handler 收 payload就剥 5。ch.pipeline().addLast(new LengthFieldBasedFrameDecoder( 1024 * 1024, // maxFrameLength假设最大 1MB 0, // lengthFieldOffset 4, // lengthFieldLength 1, // lengthAdjustment 4 // initialBytesToStrip ));假设客户端发送的字节是00 00 00 05 01 68 65 6C 6C 6F其中00 00 00 05是长度01是 typehello是 payload。经过上面的 decoder 后业务 handler 收到的字节是01 68 65 6C 6C 6F也就是 type payload。如果配置initialBytesToStrip5收到的就是纯 payload68 65 6C 6C 6F。这里最大的坑是 lengthAdjustment 算错。很多人在协议里用“len 只表示 payload 长度后面还有 type 字段”时以为 lengthAdjustment 为 0结果解析出的数据永远多了或者少了几个字节。记住一个原则它表示的是“从长度字段结束的位置到真正的业务数据内容开始的位置还差多少字节”。长度字段结束在索引 4业务内容从索引 5 开始差 1就是 1。5. 从原理到实战WebSocket 鉴权和充电桩接入怎么落地5.1 WebSocket 鉴权的正确位置握手前而不是握手后“Netty WebSocket 怎么做鉴权”是很高频的搜索词。很多人的做法是先让 WebSocket 连接建立成功然后在业务层收到第一条消息时再校验 token不对就关连接。这样虽然能工作但代价是未经认证的连接已经建立了一些攻击者可以借此占住连接资源。更合理的做法是在握手阶段就做鉴权。WebSocket 的握手本质上是一个带Upgrade: websocket头的 HTTP 请求所以你必须让HttpServerCodec先处理握手再在它之后、WebSocketServerProtocolHandler之前插入一个鉴权 handler拦截握手阶段的HttpRequest。校验通过就fireChannelRead放行让握手流程继续校验失败就返回 401 并关闭连接。public class WsAuthHandler extends ChannelInboundHandlerAdapter { Override public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception { if (msg instanceof HttpRequest) { HttpRequest req (HttpRequest) msg; String token req.headers().get(X-Auth-Token); if (token null) { QueryStringDecoder decoder new QueryStringDecoder(req.uri()); token decoder.parameters().get(token) null ? null : decoder.parameters().get(token).get(0); } if (!checkToken(token)) { FullHttpResponse resp new DefaultFullHttpResponse( HTTP_1_1, HttpResponseStatus.UNAUTHORIZED, Unpooled.copiedBuffer(unauthorized, CharsetUtil.UTF_8)); ctx.writeAndFlush(resp).addListener(ChannelFutureListener.CLOSE); return; } } ctx.fireChannelRead(msg); } }Pipeline 配置顺序ch.pipeline().addLast(new HttpServerCodec()); ch.pipeline().addLast(new WsAuthHandler()); ch.pipeline().addLast(new WebSocketServerProtocolHandler(/ws)); ch.pipeline().addLast(new TextWebSocketFrameHandler());这里有个细节要提醒如果鉴权 handler 里要做 JWT 签名校验或者查 Redis不要在 EventLoop 线程里同步执行。握手阶段本来就会挤占 IO 线程你再去查一次 Redis整个 EventLoop 上的其他连接都会被拖慢。正确做法是做成异步校验或者把校验结果缓存起来提前把 token 对应的用户信息加载到本地缓存EventLoop 里只做纯内存判断。5.2 SpringBoot 3.x Netty MQTT智能充电桩接入的经典拆法物联网充电桩这类场景设备数量多、网络不稳定、数据上报频繁特别适合用 Netty 来做接入层。一个比较经典的架构是充电桩通过 TCP 长连接接入 Netty 服务端Netty 解析设备报文后转发给 MQTT BrokerSpringBoot 业务系统订阅 MQTT 主题处理计量、计费、告警等业务逻辑。也可以让 Netty 直接实现 MQTT 协议的解码器但工程上往往直接借助现成的 MQTT Broker自己只负责设备接入和协议翻译。为什么中间要加一个 MQTT Broker因为 Netty 适合维护海量长连接但它本身不擅长做“消息持久化”“发布订阅路由”“QoS 保证”这套事情。充电桩上报一条充电记录可能同时要被计费服务、监控服务、用户通知服务消费如果全在 Netty 里点对点转发代码会非常混乱。引入 MQTT 后Netty 把设备数据发布到指定主题多个业务服务各自订阅互不干扰扩展性会好很多。在一个快速开发平台里集成 Netty 时比如在 JeecgBoot 项目里加消息推送模块我的建议是不要把 Netty 代码直接塞进 Web 项目的 Controller 里而是单独开一个netty-server的模块或服务。Netty 连接维护和 Web 业务周期差异很大混在一起容易相互影响。用ChannelGroup统一管理在线连接业务侧需要推送时通过 Spring 事件或者 Redis 发布订阅触发 Netty 服务端的写入接口这样 Web 层和 Netty 层只通过消息解耦。public class PushServer { private final ChannelGroup clients new DefaultChannelGroup(GlobalEventExecutor.INSTANCE); public void sendToAll(String message) { clients.writeAndFlush(Unpooled.copiedBuffer(message, CharsetUtil.UTF_8)); } ChannelHandler.Sharable public class ServerHandler extends SimpleChannelInboundHandlerString { Override protected void channelRead0(ChannelHandlerContext ctx, String msg) { // 处理设备上报 } Override public void channelActive(ChannelHandlerContext ctx) { clients.add(ctx.channel()); } Override public void channelInactive(ChannelHandlerContext ctx) { clients.remove(ctx.channel()); } } }5.3 心跳、重连、幂等长连接系统绕不开的三个工程细节真正上线一套长连接系统不能只看能不能连上。我这几年最大的感受是连接建立只是开始连接能不能稳定保持、断开后能不能快速恢复、重复消息能不能正确处理才是线上稳定性的分水岭。心跳保活是第一个要做的。Netty 提供了IdleStateHandler可以定期检测连接的读写空闲情况。比如充电桩每 30 秒上报一次状态那就设置读空闲 60 秒判定为异常连接触发IdleStateEvent后主动关闭。配套的逻辑是服务端读空闲超时 close客户端如果 45 秒没收到服务端任何消息就主动发心跳两边配合才能把一半开着的死连接及时清掉。ch.pipeline().addLast(idle, new IdleStateHandler(60, 0, 0, TimeUnit.SECONDS)); public class HeartbeatHandler extends ChannelInboundHandlerAdapter { Override public void userEventTriggered(ChannelHandlerContext ctx, Object evt) throws Exception { if (evt instanceof IdleStateEvent) { ctx.close(); // 读空闲超时主动断开 } else { super.userEventTriggered(ctx, evt); } } }断线重连要做成指数退避。很多设备掉线后在同一时刻疯狂重连会造成“重连风暴”把服务端打挂。我常用的策略是 1 秒、2 秒、4 秒、8 秒……最大 60 秒每次重连间隔加一点随机抖动避免所有设备同步重连。服务端收到重连请求时通过设备 ID 找到旧连接并 close防止同一设备多连接造成状态错乱。幂等也必须在设计协议时就考虑好。充电桩因为网络抖动很可能把同一条充电记录上报了两次。业务侧要在消费 MQTT 消息时做去重最常用的方式是给每条消息一个唯一 ID消费时用 Redis SETNX 或者数据库唯一索引拦截重复消息。否则就会出现用户充一次电被扣两次费的事故这种问题一旦发生补救成本极高。6. 高频面试题与线上排查技巧实录6.1 面试被问“Netty 为什么快”用一条主线答完整Netty 面试题经常被问到一个开放性题目“说说 Netty 为什么性能这么高”很多人的回答是堆名词NIO、零拷贝、多路复用、内存池。但面试官想听到的是一条有逻辑的主线。我建议你用这条线来答首先是 IO 模型Netty 基于 NIO 和事件驱动一个线程通过 Selector 监听大量连接不用每个连接开一个线程其次是线程模型主从 Reactor 模型把 accept 和 IO 读写的线程分开管理避免了线程上下文切换和连接数对线程数的绑架再次是零拷贝通过 FileRegion、CompositeByteBuf、Direct Buffer 减少了数据复制然后是内存池Netty 用 PooledByteBufAllocator 复用缓冲区减少了 GC 压力和频繁分配内存的开销最后是 Pipeline把协议编解码和业务处理做成一条可插拔的流水线扩展性和可维护性都很强。如果面试官追问细节可以补充这几个点Netty 使用 FastThreadLocal 替代普通的 ThreadLocal减少了并发访问开销它的线程模型保证同一个 Channel 的事件都在同一个线程执行避免了锁竞争它还针对 Linux 做了很多 epoll 优化比如EpollEventLoopGroup、边缘触发等性能比 JDK NIO 原生实现更好。就怕你记住了一堆名词却答不出它们分别解决了什么问题。面试官连续追问“零拷贝到底是怎么实现的”“为什么要用堆外内存”时只有真正理解原理的人才能稳住。6.2 线上三类高频问题的排查手段线上用 Netty 最容易踩的坑其实比较集中我按出现频率排一下。第一类是内存泄漏尤其是堆外内存泄漏。现象是Direct buffer memoryOOM或者 Java 进程占用的系统内存持续上涨最后被操作系统杀掉。排障第一步是开启 Netty 的内存泄漏检测日志里会打印泄漏点的分配堆栈。另外可以通过jmap -histo:live看 DirectByteBuffer 的实例数量如果数量持续增长基本可以确定有 ByteBuf 没释放。这种问题在测试环境不出现是因为并发量低时泄漏速度慢内存还没被耗尽。第二类是 EventLoop 线程被阻塞。现象是某一个客户端请求很慢经过排查发现其他很多连接也一起变慢。用jstack看线程栈如果发现nioEventLoopGroup-3-1线程上出现了Socket.read之外的耗时调用、锁等待、Thread.sleep那就是在 handler 里写了阻塞逻辑。解法是把耗时操作移到独立线程池或者用异步 IO。Netty 日志里如果出现blocked-the-thread相关告警基本就是这个原因。第三类是“半开连接”太多也就是连接在操作系统层面还存在但设备其实已经断网了。现象是服务端连接数一直在涨但活跃用户没那么多。解法就是前面说的IdleStateHandler心跳检测配合netstat -an | grep ESTABLISHED看连接状态一旦发现大量空闲连接就要检查心跳周期和超时时间是否合理。6.3 快查表现象、原因、处理对照现象可能原因排查手段与处理方向客户端收到完整消息总是乱掉没有配置拆包器或拆包参数错误检查 Pipeline 中是否加了 FrameDecoder重点看 lengthAdjustment连接建立后收不到任何数据NIO 的读事件没被触发或 IdleStateHandler 误判抓包看 TCP 层是否有数据检查 pipeline 顺序一个慢请求拖垮其他连接EventLoop 被业务代码阻塞jstack 定位线程栈耗时逻辑移到业务线程池Direct buffer memory OOMByteBuf 未释放开启 leakDetection检查 ChannelInboundHandlerAdapter 中是否有 release连接数持续增长心跳检测缺失或超时过长配置 IdleStateHandler读空闲主动 close大量设备同时掉线后重连风暴重连间隔固定没有抖动指数退避 随机抖动服务端限制单设备连接数业务重复计费消息重复上报消息唯一 ID Redis SETNX 或数据库唯一索引去重大文件传输内存爆掉用 byte[] 读文件再发送改用 FileRegion 走 sendfile这张表是我在维护长连接服务时总结的每次线上出问题我都会先对着看一遍。绝大部分 Netty 相关的“疑难杂症”最后都能归到这几个根因。再说一个经验Netty 自带的内存泄漏检测在测试和压测环境一定要开到 paranoid 级别生产环境至少保持 simple。很多线上内存问题之所以难查就是因为没开检测等到 OOM 时日志已经被冲掉了。日志里能打印出泄漏的分配堆栈这个问题就能变成一个顺藤摸瓜的简单问题。我个人做长连接服务这几年的体会是Netty 的性能优势说白了来自两件事一是用事件驱动替代线程阻塞把“等”这种浪费 CPU 的行为去掉二是尽可能减少数据的无意义复制让内存和带宽都花在刀刃上。这两点想透了再看源码就不会晕。如果你正打算学别一上来就死磕源码建议先在本地把线程模型、Pipeline、拆包器这几个点跑通再回到原理部分对照着看。最后可以自己做一个带鉴权、心跳、粘包处理的 WebSocket 服务把内部机制真正用出来一次比什么都管用。
