1. 这个项目到底在解决什么问题先把话说在前面凡是做过物联网设备接入、IM即时通讯、游戏服务端、金融行情推送这类业务的兄弟大概率都绕不开一个东西——TCP长连接。TCP本身是个面向连接的协议三次握手之后服务端和客户端之间就建立了一条可靠的字节流通道问题在于这条通道该怎么维护、断了怎么处理、连接多了怎么撑住、服务重启会不会全部掉线。这四件事如果靠原生Socket去写不是说写不出来而是等到你要处理几千个连接、几万个心跳包、各种半包粘包、GC停顿导致的假死连接时会写得很痛苦还容易写出隐蔽的Bug。我用Netty做这个高可用TCP长连接服务核心目标只有三个一是扛得住大规模并发连接二是能在网络异常时自动识别并剔除“僵尸连接”三是服务端重启或者发布时能让客户端无感重连整个服务对外表现为稳定可靠。这个项目适合正在做物联网接入服务、游戏网关、IM服务、或者任何形态的长连接服务的同学参考如果你只是在学Netty怎么用也能从这套代码里找到完整的落地思路而不是只会看官方Demo。我一直觉得Netty是Java后端开发者必学的框架之一不是因为它的抽象有多炫酷而是因为它是为数不多的“把极端复杂的网络编程封装成能上手的API”的框架。选择Netty而不是其他的NIO框架最大的原因在于它的线程模型非常成熟——Reactor线程模型经过大量验证EventLoop的调度机制、ByteBuf池化、编解码器链式编排都帮你把底层那堆脏活累活处理掉了。但是框架替你搞定底层不代表你可以躺着写业务代码恰恰相反如果你不理解它的线程模型、不了解Handler链路的执行机制写出来的服务照样会在高并发下表现拉胯。下面就把我是怎么设计这个服务、代码怎么组织、踩过哪些坑一次性讲透。2. 整体设计从连接接入到业务处理的全链路拆解2.1 长连接服务最核心的四个设计难点我觉得在动手写代码之前得先把问题拆清楚一下否则很容易写着写着就跑偏。长连接和普通HTTP短连接最大的不同在于连接数量是海量的、连接存活时间是按小时甚至按天算的、单个连接上会有频繁的心跳和业务数据交织。这里的第一个难点是连接管理。一个TCP连接建立起来之后服务端需要保存连接对应的Channel对象同时还要能快速找到某个用户的连接并推送消息。连接多了以后内存占用、查找效率、连接断开时的清理动作都会成为问题。第二个难点是状态维护。TCP连接本身是无状态的但在业务层连接通常对应着一个登录用户或者一台设备。登录态过期了连接要不要断开设备升级重启了旧连接怎么处理这些都需要在连接的生命周期里做状态管理。第三个难点是网络异常识别。拔网线、断电、设备休眠这些情况下操作系统不会立刻告诉你的进程连接断了。如果没有心跳机制服务端会一直保留着“半开”的连接占着资源不干活时间长了连接池就满了新连接进不来服务就挂了。第四个难点是优雅发布。服务不可能永远不更新代码。Java应用发布免不了要重启进程如果重启直接kill -9几万个连接瞬间断开客户端那边会疯掉各种重连风暴打到新的服务实例上直接把服务打垮。以上这四个问题我都会在这套实现里逐一解决。2.2 技术选型为什么是Netty Protobuf Redis现在说下这套服务的技术栈。网络层我用的是Netty 4.1.x这是目前最稳定的版本线。协议层没有跟着网上很多教程去自定义TCP报文格式而是选了Protobuf做消息体的序列化主要原因是长连接服务尤其讲究“协议自描述”和“跨语言互通”。比如我们的客户端可能是Java、可能是Android、可能是嵌入式设备上的C程序如果用Java自带的ObjectOutputStream做对象序列化别的语言根本没法解析而且序列化后的体积很大、有安全漏洞。Protobuf在这几方面都均衡编解码性能好、体积小、有跨语言代码生成工具、向后兼容做得好。你要是现在手里没有Protobuf的环境也可以先换成JSON字符串等后面有需求再迁移Netty这边的Handler链路基本不用动。状态管理这块我用了Redis。每个连接建立后把用户ID和ChannelID的绑定关系、最近一次心跳时间存到Redis里服务重启后可以从Redis恢复“这个用户应该重新路由到哪个节点”。如果只是单机部署那直接用本地ConcurrentHashMap就够了但为了后面能水平扩展建议一开始就往Redis这种集中式存储上靠省得到时候架构演进推倒重来。2.3 连接接入链路从Boss线程到Worker线程下面是核心代码部分。先看服务端的启动类这段代码就是在做“怎么把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) .option(ChannelOption.SO_REUSEADDR, true) .childOption(ChannelOption.TCP_NODELAY, true) .childOption(ChannelOption.SO_KEEPALIVE, true) .childOption(ChannelOption.ALLOCATOR, PooledByteBufAllocator.DEFAULT) .childHandler(new ChannelInitializerSocketChannel() { Override protected void initChannel(SocketChannel ch) { ChannelPipeline pipeline ch.pipeline(); pipeline.addLast(new IdleStateHandler(60, 0, 0)); pipeline.addLast(new ProtobufVarint32FrameDecoder()); pipeline.addLast(new ProtobufDecoder(MessageBase.Message.getDefaultInstance())); pipeline.addLast(new ProtobufVarint32LengthFieldPrepender()); pipeline.addLast(new ProtobufEncoder()); pipeline.addLast(new AuthHandler()); pipeline.addLast(new HeartbeatHandler()); pipeline.addLast(new BusinessHandler()); } }); ChannelFuture future bootstrap.bind(8080).sync(); future.channel().closeFuture().sync();这段代码里有几个细节我得单独拎出来强调一下。bossGroup和workerGroup的分配是有讲究的。Boss线程只有一个它的职责就是不停地调用Selector.select()发现新的TCP连接进来后把这个连接注册到Worker线程上。真正处理每条连接上的读写事件的是Worker线程。如果你把Boss线程数开多了反而会因为多个线程同时抢占accept事件导致性能下降。Worker线程数默认是CPU核心数的两倍对于IO密集型的服务来说这个默认值通常是合理的。SO_BACKLOG设置的是TCP三次握手完成后、应用层还未accept时内核中连接队列的长度。设成1024对于大部分场景都够了设太大没有意义因为每个等待accept的连接都要占内核内存。TCP_NODELAY这个参数很关键。它关闭了Nagle算法。Nagle算法是为了减少网络上微小数据包的数量会把小的数据包合并后再发送。但在长连接场景下我们发的是心跳包、业务消息数据包都很小开启Nagle算法会导致消息被延迟发送客户端那边就会觉得服务响应变慢了所以一定要把TCP_NODELAY设为true。SO_KEEPALIVE设置为true之后TCP协议栈会每隔一段时间默认是2小时自动探测一下连接是否还活着。但是注意这个参数只能检测物理网络层面的断线应用层卡死或者设备断电导致的假死它是检测不出来的。所以就算设置了SO_KEEPALIVE我们仍然要在应用层做心跳监测这就是后面要讲的IdleStateHandler。PooledByteBufAllocator用的池化字节缓冲分配器。Netty 4.0时代默认是未池化的每次读写都要从JVM堆里分配新的字节数组高并发下GC压力非常大。4.1版本虽然默认池化了但这里显式写出来是一种习惯也是给后来的维护者一个明确信号这个服务是面向高并发场景的。再说ChannelInitializer里的Handler编排顺序。Netty的Pipeline是一个双向链表入站事件从上往下传播出站事件从下往上传播。IdleStateHandler放在最前面能第一时间捕获到链路空闲事件然后是解码器和编码器这是因为业务Handler里只应该处理Java对象不应该碰原始字节流加密认证的Handler要放在编解码器的后面因为只有先解出消息内容才能判断这个连接有没有权限最后才是业务Handler处理实际的数据。3. 核心细节解析心跳检测、重连机制与可扩展设计3.1 心跳机制从UserEventTriggered入手心跳检测这个话题是每个长连接服务开发者都绕不开的坎。我见过很多新手项目的通病是——服务端只设置了一个IdleStateHandler超过指定时间没收到数据就关闭连接但是客户端没有对应的重连机制结果服务端一断客户端就永远“静默死亡”了。所以心跳机制一定是“检测”和“恢复”两个动作成对出现的。Netty提供的IdleStateHandler帮我们解决的是“检测”部分。它内部会起一个定时任务在指定时间内没有读事件、没有写事件、或者读写都没有时触发对应的IdleStateEvent。事件会沿着Pipeline往下传最终由我们自己的Handler通过userEventTriggered方法接收并处理。来看这段代码Override public void userEventTriggered(ChannelHandlerContext ctx, Object evt) throws Exception { if (evt instanceof IdleStateEvent) { IdleStateEvent event (IdleStateEvent) evt; if (event.state() IdleState.ALL_IDLE) { // 超过指定时间既没读到数据也没写出数据判定为半开连接 log.info([心跳检测] 连接空闲超时关闭连接, channelId: {}, ctx.channel().id()); ctx.close(); } else if (event.state() IdleState.READER_IDLE) { // 服务端连续N秒没收到客户端数据主动断开 log.info([心跳检测] {} 秒未收到客户端消息关闭连接, readerIdleTimeSeconds); ctx.close(); } } else { super.userEventTriggered(ctx, evt); } }上面这段代码里IdleStateHandler在初始化时传的参数是new IdleStateHandler(60, 0, 0)意思是读空闲60秒、写空闲不检测、读写全空闲不检测。这里的业务逻辑是服务端只需关心“我有没有收到客户端的数据”只要客户端一直在发心跳服务端就不会触发READER_IDLE事件连接也就不会被误杀。这里有一个坑是万一客户端逻辑写错了导致服务端一直收到数据但从来不给客户端回数据那客户端那边的READER_IDLE就会触发它会主动断开重连。所以心跳协议的设计要尽量简单直接客户端发Ping服务端回Pong谁收不到对端的消息超过一定时间谁就主动断开。实际生产中心跳间隔和超时阈值是有讲究的不能拍脑袋。如果心跳太频繁浪费带宽和CPU尤其是几万个连接时每秒光心跳包就有大几千个心跳太稀疏断线检测就不及时连接池可能被僵尸连接占满。一般建议心跳间隔在30到60秒之间超时阈值设为心跳间隔的2到3倍。比如客户端30秒发一次Ping服务端90秒没收到任何数据就把连接断开。这样设计的原因是TCP的丢包和网络抖动在正常网络环境下很少会持续超过90秒如果这么长时间都没数据基本可以断定这个连接已经不可用了。3.2 客户端如何配合自动重连与重试风暴防御服务端做得再好如果客户端没有自动重连整个高可用架构就缺了一条腿。下面这段代码是Netty客户端的核心逻辑我在几个线上项目里都验证过稳定性很好public class NettyClient { private EventLoopGroup group new NioEventLoopGroup(); private Bootstrap bootstrap; public void connect() throws InterruptedException { bootstrap new Bootstrap(); bootstrap.group(group) .channel(NioSocketChannel.class) .option(ChannelOption.TCP_NODELAY, true) .handler(new ChannelInitializerSocketChannel() { Override protected void initChannel(SocketChannel ch) { ChannelPipeline pipeline ch.pipeline(); pipeline.addLast(new IdleStateHandler(0, 25, 0)); pipeline.addLast(new ProtobufVarint32FrameDecoder()); pipeline.addLast(new ProtobufDecoder(MessageBase.Message.getDefaultInstance())); pipeline.addLast(new ProtobufVarint32LengthFieldPrepender()); pipeline.addLast(new ProtobufEncoder()); pipeline.addLast(new HeartbeatHandler()); pipeline.addLast(new BusinessHandler()); } }); doConnect(); } private void doConnect() { ChannelFuture future bootstrap.connect(host, port); future.addListener((ChannelFutureListener) f - { if (!f.isSuccess()) { // 连接失败3秒后重新尝试 f.channel().eventLoop().schedule(this::doConnect, 3, TimeUnit.SECONDS); } }); } }这段代码有两个地方值得展开讲讲。第一IdleStateHandler(0, 25, 0)意思是写空闲25秒就触发WRITER_IDLE事件。客户端只需要在写空闲触发时发一个Ping包不需要关心服务端有没有回包。为什么要以写空闲作为心跳触发的条件因为如果采用定时发送万一当前连接上有频繁的业务数据在交互再额外发心跳就是浪费。而以写空闲作为触发条件可以保证只有在一个时间段内没有任何数据发出的情况下才发送Ping这样就自然地把心跳和业务数据交织起来了。第二重连用的是f.channel().eventLoop().schedule(...)这就保证了重连成功之后新连接会注册在同一个EventLoop上这个链路是线程安全的。而且通过事件循环自身的调度器来发起重连不会出现多个线程并发重连的问题。但是重连也存在一个隐患如果服务端真的挂了客户端每3秒尝试重连一次成千上万个客户端同时发起重连就形成了“重连风暴”很可能把刚恢复的服务再次打挂。防御这个问题的常见做法是在重连的nextAttemptDelay上做指数退避并加上一个随机抖动。比如第一次失败等1秒第二次等2秒第三次等4秒……封顶60秒再加上一个0到1000毫秒的随机数让所有客户端的重连请求分布在不同的时间点上。下面这段代码可以直接用private void doConnect() { ChannelFuture future bootstrap.connect(host, port); future.addListener((ChannelFutureListener) f - { if (!f.isSuccess()) { long nextDelay Math.min(retryCount * 1000L ThreadLocalRandom.current().nextInt(1000), 60000L); f.channel().eventLoop().schedule(this::doConnect, nextDelay, TimeUnit.MILLISECONDS); } }); }3.3 扩展思考这层架构还可以怎么长如果你只做单机版的TCP长连接服务到这里核心代码已经完整了。但在一开始我就说了高可用不只是单机层面的事情。把眼光放到集群层面这套设计还需要考虑几件事。第一如果服务有多个节点一个客户端连接到了节点A下一次重连却连到了节点B节点B怎么知道这个客户端之前的状态这就需要在握手认证时让客户端带上用户ID或者设备ID节点B去Redis或者数据库里查一下这个用户的登录态校验通过后重建状态。这也是为什么我在ChannelInitializer里加了一个AuthHandler的原因它就是在做身份校验和状态重建。第二消息推送怎么做比如服务端要主动向某个用户推送一条消息但这个用户连接在节点A上推送服务怎么找到节点A常见方案是建立一个路由表也就是用用户ID做key、节点地址加ChannelID做value存在Redis里。每次连接建立、断开时更新这张表推送时先查表再转发。第三这个连接管理模块和业务系统怎么解耦实际项目中业务逻辑一般不会直接写在Netty的Handler里而是通过消息队列、RPC调用等方式转发给后端的业务服务。Netty这一层只负责保持连接、处理协议、做心跳检测业务数据到达后解码成业务消息投递到MQ或者通过HTTP调用业务接口然后异步把结果写回客户端。这样一来长连接网关可以独立扩缩容业务服务也可以独立部署。4. 高可用构建优雅停机、全链路监控与性能调优4.1 优雅停机发布一次不能把线上连接全部搞断如果说心跳机制解决的是“连接坏了怎么发现”那优雅停机解决的就是“主动断开时怎么让客户端无感”。每次服务端发布新版本如果直接kill进程所有TCP连接会立刻断开客户端会疯狂重连新启动的服务节点一瞬间被连接风暴打垮。这是很多长连接服务的故障高发场景。优雅停机的思路很简单进程准备退出前先停掉接收新连接的端口然后给所有现存连接发一个“服务端即将下线”的消息等客户端收到消息后主动断开或者等待客户端自己检测到断线后重连到其他节点最后再真正退出进程。在Netty里实现优雅停机分两步。首先是JVM层面的ShutdownHookRuntime.getRuntime().addShutdownHook(new Thread(() - { log.info(收到停机信号开始优雅停机); bossGroup.shutdownGracefully(); workerGroup.shutdownGracefully(); // 等待所有连接处理完当前请求 try { bossGroup.terminationFuture().sync(); workerGroup.terminationFuture().sync(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } log.info(优雅停机完成); }));ShutdownHook里的shutdownGracefully会先停止接受新连接然后等待已经注册的Channel把当前正在处理的读写事件执行完再关闭所有连接。但是这里有个隐藏的问题如果有一些连接长期没有事件发生也就是空闲连接shutdownGracefully可能会一直等下去。所以真要实现优雅停机还需要一个主动通知客户端的动作让客户端收到通知后主动断开。这个通知消息可以通过现有的Channel直接写出去// 停机前给所有连接发送下线通知 for (Channel channel : channelGroup) { MessageBase.Message message MessageBase.Message.newBuilder() .setCmd(MessageBase.CommandType.SHUTDOWN_NOTICE) .setContent(服务端即将重启请重新连接) .build(); channel.writeAndFlush(message); }这里的channelGroup是Netty提供的ChannelGroup它是一个线程安全的连接集合可以在ChannelActive时添加ChannelChannelInactive时移除Channel。用ChannelGroup的好处是你可以一次性给所有连接广播消息不用自己维护一个ConcurrentHashMap再手动遍历。等到客户端收到SHUTDOWN_NOTICE消息后主动发起重连逻辑尽量不用等TCP超时这样整个切换过程对用户来说基本是无感的。4.2 监控与可观测性高可用服务必须有的“仪表盘”服务启动起来谁都会写但线上出了问题能不能快速定位才是高可用的分水岭。我强烈建议把以下几项指标从最开始就埋好。第一项是连接数统计。每增加一个活跃连接就加一每断开一个就减一同时单独统计当前处于空闲状态的连接数和已认证连接数。连接数异常上涨或者下跌往往是故障的最早信号。第二项是消息吞吐量和延迟。每秒钟处理的入站消息数和出站消息数、单条消息从入站到出站的平均耗时这两个指标能直接反映服务的健康程度。如果消息量没变但处理耗时明显上升大概率是线程池阻塞或者GC变频繁了。第三项是心跳成功率。统计每次发送Ping后收到Pong的比例如果成功率突然下降说明网络链路或对端服务出现了问题。埋点的方式可以直接在Handler里加计数器简单的可以用AtomicLong量大了可以接入Micrometer把指标暴露给Prometheus。我个人的习惯是核心指标一定用Micrometer做全局统一管理日志只记录关键事件比如连接异常断开、服务端主动关闭、认证失败等避免每条心跳都打日志把磁盘刷爆。4.3 性能调优从两万连接到十万连接服务上线初期两万连接跑着没问题等到用户量起来后连接数涨到十万你可能会发现GC时间变长、CPU飙高、心跳延迟变大。这个时候需要从几个方面去排查。线程数是最容易想到的但也很容易调错。如果你发现Worker线程频繁在Netty的任务队列里堆积任务可以观察是否有业务逻辑里做了同步的数据库查询或者第三方RPC调用。解决的方向不是调大线程数而是把耗时操作移出IO线程。比如把业务处理扔进独立的业务线程池或者用异步方式转发到MQNetty线程只干网络读写和协议编解码从源头保证IO线程不被阻塞。内存方面Netty的池化内存默认使用堆外内存默认情况下Netty会按照可用的堆内存的2/3来作为最大堆外内存大小但这会受JVM参数配置影响。线上遇到内存问题主要还是先看堆内存的GC表现再看堆外内存是否泄漏。Netty自带了NettyRuntime.availableProcessors()来探测可用CPU适合大多数场景。另外大流量场景下可以开启ChannelOption.WRITE_BUFFER_WATER_MARK来控制写缓冲防止某个慢消费者把服务端内存耗尽。一般设置成low32KB、high64KB如果单个连键的写缓冲达到high水位说明这个客户端消费不过来了服务端可以做限流或者直接断开连接。5. 常见问题与避坑指南这些坑我都是真金白银踩出来的5.1 粘包/拆包问题为什么服务端收到了乱码TCP是流式协议没有消息边界。你发送的包可能会被合并成一个包发送粘包也可能被拆成多个包发送拆包。如果不对消息做帧界定服务端收到的数据就会出现错乱。很多新手第一次写完Netty服务用固定长度的消息测试一切正常一旦做压力测试数据就变得支离破碎。解决办法就是在Pipeline里加入FrameDecoder。我上面用的是ProtobufVarint32FrameDecoder它的原理是在每个消息前加一个Varint32类型的数据头用来声明消息长度。解决粘包拆包的问题一定要放在解码器的第一层也就是Pipeline的最前面然后在这个基础上再做业务的字节解码。如果你用的是文本协议那就用LineBasedFrameDecoder按换行符分割或者用DelimiterBasedFrameDecoder按自定义分隔符分割。注意HTTP协议实际上是基于行分隔的文本协议所以HttpServerCodec内部就是组合了HttpRequestDecoder和HttpResponseEncoder底层也处理了帧。5.2 直接在Handler里做耗时操作把事件循环卡死了我见过一个非常典型的线上事故某个团队在Netty的Handler里直接调用某个后端的同步HTTP接口这个接口偶尔超时最坏情况要等几十秒。结果就是一旦有连接触发了这个Handler处理它的Work线程就被卡住几十秒而这个Work线程同时要负责几百个连接的读写其他所有连接都被拖慢了。Netty官方文档强调的三条铁律是不能在EventLoop里做阻塞操作、不能直接在线程里调用Channel方法、不能没有边界地使用线程池。如果你确实要把业务逻辑放在Handler里做一定要把耗时操作丢到独立的业务线程池处理private final ExecutorService businessExecutor Executors.newFixedThreadPool(16); Override protected void channelRead0(ChannelHandlerContext ctx, MessageBase.Message msg) { businessExecutor.submit(() - { // 耗时业务处理 Object result heavyBusiness(msg); // 处理完成后把结果写回 ctx.channel().writeAndFlush(result); }); }注意这里有个细节从业务线程池里写回数据时writeAndFlush是线程安全的因为Netty的Channel内部会把写操作封装成任务丢回EventLoop执行所以你可以放心地在任意线程里调用channel.writeAndFlush不需要担心线程安全问题。5.3 ByteBuf的释放问题内存泄漏排查实录Netty使用引用计数器来管理ByteBuf的内存默认情况下解码后的ByteBuf在Handler链路上传递时使用完就会被自动释放但你如果尝试在业务里保存这个ByteBuf引用稍不注意就会造成内存泄漏。我遇到过一次堆外内存泄漏事故是业务代码把收到的ByteBuf对象存在了一个静态Map里传给后面的线程处理结果下游处理失败后一直没有释放。排查这种问题最快的方式是开启Netty的内存泄漏检测设置JVM参数-Dio.netty.leakDetection.levelparanoid然后观察日志里是否有LEAK提示。如果是使用了ByteBuf但没释放日志里会明确告诉你是在哪个Handler、哪行代码创建了这个ByteBuf。当然最简单的规避方式是尽量使用字符串或者Protobuf对象作为Handler之间传递的消息载体只有在你确实需要操作二进制协议时再去碰ByteBuf。SimpleChannelInboundHandler的channelRead0方法设计成自动释放消息也是这个原因——它会在回调里面帮你把消息的引用计数减掉。5.4 连接数上来了但内存暴涨Channel和缓冲区被谁占了正常情况下一万个TCP连接所占的内存并不高因为每个空闲连接占用的资源很少。但如果你发现服务内存很高优先排查三个方向一是每个连接是否注册了多个HandlerHandler里的实例字段是否存了不该存的业务数据二是写缓冲区是否被某些慢客户端拖住了三是ChannelGroup里是否保存了已经关闭的Channel引用导致无法回收。有一种常见场景是客户端断线后TCP四次挥手没有正常完成连接处于CLOSE_WAIT状态服务端的Channel对象也就一直存在。解决办法有两个层面操作系统层面调小tcp_keepalive_time和tcp_fin_timeout应用层面临结合我们之前说的心跳检测机制让服务端在空闲超时后主动关闭这些连接。5.5 笔记一套可以直接用的学习调试方法最后再说个调试上的小技巧。我在本地开发Netty服务时从来不用肉眼去看到底收到了什么字节。配置好Wireshark或者直接用TCP客户端工具先测试连接再用Netty日志看调试输出。Netty自带的日志Factory支持动态调整级别把io.netty.handler.logging.LoggingHandler加到Pipeline里pipeline.addLast(new LoggingHandler(LogLevel.DEBUG));这个Handler会把你经过它的每个ByteBuf的十六进制内容、读写方向、字节数全部打印出来。写编解码器时这个日志非常有用基本能把80%以上的协议解析问题定位出来。注意生产环境一定要关掉这个Handler否则日志量能把磁盘写满。6. 总结一下这套方案的完整链路写到这里从最开始说“为什么要做长连接”到启动Netty服务、心跳检测、自动重连、优雅停机再到常见的粘包拆包、内存泄漏排查基本把一条完整的生产链路串起来了。总结下来就三句话连接管理要用好Pipeline的Handler职责边界心跳机制一定要服务端和客户端成对配合高可用是靠优雅停机和自动重连一层一层堆出来的。我在实际项目中把这套方案部署上线后最明显的一个变化是线上基本再也没出现过“连接池被打满”这种告警。以前排查问题总是被各种奇奇怪怪的网络异常牵着鼻子走现在有了心跳兜底、有了状态监控、有了重连的退避策略就算是凌晨两点被叫起来处理故障也能很快定位到是物理链路问题还是服务本身的问题。留给你的建议是不要把这套代码原样搬到生产就完事一定要根据自己的协议、业务场景做调整。比如物联网设备的电量限制可能要求心跳间隔放到120秒金融行情场景可能要求消息的可靠性达到不丢包的程度这些都需要你对Netty的机制有足够深的理解后再做针对性优化。先把框架跑通再深入原理最后再改造成适合自己业务的样子这是我眼中最稳的一条学习路径。 Netty高可用TCP长连接服务核心设计与实践
1. 这个项目到底在解决什么问题先把话说在前面凡是做过物联网设备接入、IM即时通讯、游戏服务端、金融行情推送这类业务的兄弟大概率都绕不开一个东西——TCP长连接。TCP本身是个面向连接的协议三次握手之后服务端和客户端之间就建立了一条可靠的字节流通道问题在于这条通道该怎么维护、断了怎么处理、连接多了怎么撑住、服务重启会不会全部掉线。这四件事如果靠原生Socket去写不是说写不出来而是等到你要处理几千个连接、几万个心跳包、各种半包粘包、GC停顿导致的假死连接时会写得很痛苦还容易写出隐蔽的Bug。我用Netty做这个高可用TCP长连接服务核心目标只有三个一是扛得住大规模并发连接二是能在网络异常时自动识别并剔除“僵尸连接”三是服务端重启或者发布时能让客户端无感重连整个服务对外表现为稳定可靠。这个项目适合正在做物联网接入服务、游戏网关、IM服务、或者任何形态的长连接服务的同学参考如果你只是在学Netty怎么用也能从这套代码里找到完整的落地思路而不是只会看官方Demo。我一直觉得Netty是Java后端开发者必学的框架之一不是因为它的抽象有多炫酷而是因为它是为数不多的“把极端复杂的网络编程封装成能上手的API”的框架。选择Netty而不是其他的NIO框架最大的原因在于它的线程模型非常成熟——Reactor线程模型经过大量验证EventLoop的调度机制、ByteBuf池化、编解码器链式编排都帮你把底层那堆脏活累活处理掉了。但是框架替你搞定底层不代表你可以躺着写业务代码恰恰相反如果你不理解它的线程模型、不了解Handler链路的执行机制写出来的服务照样会在高并发下表现拉胯。下面就把我是怎么设计这个服务、代码怎么组织、踩过哪些坑一次性讲透。2. 整体设计从连接接入到业务处理的全链路拆解2.1 长连接服务最核心的四个设计难点我觉得在动手写代码之前得先把问题拆清楚一下否则很容易写着写着就跑偏。长连接和普通HTTP短连接最大的不同在于连接数量是海量的、连接存活时间是按小时甚至按天算的、单个连接上会有频繁的心跳和业务数据交织。这里的第一个难点是连接管理。一个TCP连接建立起来之后服务端需要保存连接对应的Channel对象同时还要能快速找到某个用户的连接并推送消息。连接多了以后内存占用、查找效率、连接断开时的清理动作都会成为问题。第二个难点是状态维护。TCP连接本身是无状态的但在业务层连接通常对应着一个登录用户或者一台设备。登录态过期了连接要不要断开设备升级重启了旧连接怎么处理这些都需要在连接的生命周期里做状态管理。第三个难点是网络异常识别。拔网线、断电、设备休眠这些情况下操作系统不会立刻告诉你的进程连接断了。如果没有心跳机制服务端会一直保留着“半开”的连接占着资源不干活时间长了连接池就满了新连接进不来服务就挂了。第四个难点是优雅发布。服务不可能永远不更新代码。Java应用发布免不了要重启进程如果重启直接kill -9几万个连接瞬间断开客户端那边会疯掉各种重连风暴打到新的服务实例上直接把服务打垮。以上这四个问题我都会在这套实现里逐一解决。2.2 技术选型为什么是Netty Protobuf Redis现在说下这套服务的技术栈。网络层我用的是Netty 4.1.x这是目前最稳定的版本线。协议层没有跟着网上很多教程去自定义TCP报文格式而是选了Protobuf做消息体的序列化主要原因是长连接服务尤其讲究“协议自描述”和“跨语言互通”。比如我们的客户端可能是Java、可能是Android、可能是嵌入式设备上的C程序如果用Java自带的ObjectOutputStream做对象序列化别的语言根本没法解析而且序列化后的体积很大、有安全漏洞。Protobuf在这几方面都均衡编解码性能好、体积小、有跨语言代码生成工具、向后兼容做得好。你要是现在手里没有Protobuf的环境也可以先换成JSON字符串等后面有需求再迁移Netty这边的Handler链路基本不用动。状态管理这块我用了Redis。每个连接建立后把用户ID和ChannelID的绑定关系、最近一次心跳时间存到Redis里服务重启后可以从Redis恢复“这个用户应该重新路由到哪个节点”。如果只是单机部署那直接用本地ConcurrentHashMap就够了但为了后面能水平扩展建议一开始就往Redis这种集中式存储上靠省得到时候架构演进推倒重来。2.3 连接接入链路从Boss线程到Worker线程下面是核心代码部分。先看服务端的启动类这段代码就是在做“怎么把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) .option(ChannelOption.SO_REUSEADDR, true) .childOption(ChannelOption.TCP_NODELAY, true) .childOption(ChannelOption.SO_KEEPALIVE, true) .childOption(ChannelOption.ALLOCATOR, PooledByteBufAllocator.DEFAULT) .childHandler(new ChannelInitializerSocketChannel() { Override protected void initChannel(SocketChannel ch) { ChannelPipeline pipeline ch.pipeline(); pipeline.addLast(new IdleStateHandler(60, 0, 0)); pipeline.addLast(new ProtobufVarint32FrameDecoder()); pipeline.addLast(new ProtobufDecoder(MessageBase.Message.getDefaultInstance())); pipeline.addLast(new ProtobufVarint32LengthFieldPrepender()); pipeline.addLast(new ProtobufEncoder()); pipeline.addLast(new AuthHandler()); pipeline.addLast(new HeartbeatHandler()); pipeline.addLast(new BusinessHandler()); } }); ChannelFuture future bootstrap.bind(8080).sync(); future.channel().closeFuture().sync();这段代码里有几个细节我得单独拎出来强调一下。bossGroup和workerGroup的分配是有讲究的。Boss线程只有一个它的职责就是不停地调用Selector.select()发现新的TCP连接进来后把这个连接注册到Worker线程上。真正处理每条连接上的读写事件的是Worker线程。如果你把Boss线程数开多了反而会因为多个线程同时抢占accept事件导致性能下降。Worker线程数默认是CPU核心数的两倍对于IO密集型的服务来说这个默认值通常是合理的。SO_BACKLOG设置的是TCP三次握手完成后、应用层还未accept时内核中连接队列的长度。设成1024对于大部分场景都够了设太大没有意义因为每个等待accept的连接都要占内核内存。TCP_NODELAY这个参数很关键。它关闭了Nagle算法。Nagle算法是为了减少网络上微小数据包的数量会把小的数据包合并后再发送。但在长连接场景下我们发的是心跳包、业务消息数据包都很小开启Nagle算法会导致消息被延迟发送客户端那边就会觉得服务响应变慢了所以一定要把TCP_NODELAY设为true。SO_KEEPALIVE设置为true之后TCP协议栈会每隔一段时间默认是2小时自动探测一下连接是否还活着。但是注意这个参数只能检测物理网络层面的断线应用层卡死或者设备断电导致的假死它是检测不出来的。所以就算设置了SO_KEEPALIVE我们仍然要在应用层做心跳监测这就是后面要讲的IdleStateHandler。PooledByteBufAllocator用的池化字节缓冲分配器。Netty 4.0时代默认是未池化的每次读写都要从JVM堆里分配新的字节数组高并发下GC压力非常大。4.1版本虽然默认池化了但这里显式写出来是一种习惯也是给后来的维护者一个明确信号这个服务是面向高并发场景的。再说ChannelInitializer里的Handler编排顺序。Netty的Pipeline是一个双向链表入站事件从上往下传播出站事件从下往上传播。IdleStateHandler放在最前面能第一时间捕获到链路空闲事件然后是解码器和编码器这是因为业务Handler里只应该处理Java对象不应该碰原始字节流加密认证的Handler要放在编解码器的后面因为只有先解出消息内容才能判断这个连接有没有权限最后才是业务Handler处理实际的数据。3. 核心细节解析心跳检测、重连机制与可扩展设计3.1 心跳机制从UserEventTriggered入手心跳检测这个话题是每个长连接服务开发者都绕不开的坎。我见过很多新手项目的通病是——服务端只设置了一个IdleStateHandler超过指定时间没收到数据就关闭连接但是客户端没有对应的重连机制结果服务端一断客户端就永远“静默死亡”了。所以心跳机制一定是“检测”和“恢复”两个动作成对出现的。Netty提供的IdleStateHandler帮我们解决的是“检测”部分。它内部会起一个定时任务在指定时间内没有读事件、没有写事件、或者读写都没有时触发对应的IdleStateEvent。事件会沿着Pipeline往下传最终由我们自己的Handler通过userEventTriggered方法接收并处理。来看这段代码Override public void userEventTriggered(ChannelHandlerContext ctx, Object evt) throws Exception { if (evt instanceof IdleStateEvent) { IdleStateEvent event (IdleStateEvent) evt; if (event.state() IdleState.ALL_IDLE) { // 超过指定时间既没读到数据也没写出数据判定为半开连接 log.info([心跳检测] 连接空闲超时关闭连接, channelId: {}, ctx.channel().id()); ctx.close(); } else if (event.state() IdleState.READER_IDLE) { // 服务端连续N秒没收到客户端数据主动断开 log.info([心跳检测] {} 秒未收到客户端消息关闭连接, readerIdleTimeSeconds); ctx.close(); } } else { super.userEventTriggered(ctx, evt); } }上面这段代码里IdleStateHandler在初始化时传的参数是new IdleStateHandler(60, 0, 0)意思是读空闲60秒、写空闲不检测、读写全空闲不检测。这里的业务逻辑是服务端只需关心“我有没有收到客户端的数据”只要客户端一直在发心跳服务端就不会触发READER_IDLE事件连接也就不会被误杀。这里有一个坑是万一客户端逻辑写错了导致服务端一直收到数据但从来不给客户端回数据那客户端那边的READER_IDLE就会触发它会主动断开重连。所以心跳协议的设计要尽量简单直接客户端发Ping服务端回Pong谁收不到对端的消息超过一定时间谁就主动断开。实际生产中心跳间隔和超时阈值是有讲究的不能拍脑袋。如果心跳太频繁浪费带宽和CPU尤其是几万个连接时每秒光心跳包就有大几千个心跳太稀疏断线检测就不及时连接池可能被僵尸连接占满。一般建议心跳间隔在30到60秒之间超时阈值设为心跳间隔的2到3倍。比如客户端30秒发一次Ping服务端90秒没收到任何数据就把连接断开。这样设计的原因是TCP的丢包和网络抖动在正常网络环境下很少会持续超过90秒如果这么长时间都没数据基本可以断定这个连接已经不可用了。3.2 客户端如何配合自动重连与重试风暴防御服务端做得再好如果客户端没有自动重连整个高可用架构就缺了一条腿。下面这段代码是Netty客户端的核心逻辑我在几个线上项目里都验证过稳定性很好public class NettyClient { private EventLoopGroup group new NioEventLoopGroup(); private Bootstrap bootstrap; public void connect() throws InterruptedException { bootstrap new Bootstrap(); bootstrap.group(group) .channel(NioSocketChannel.class) .option(ChannelOption.TCP_NODELAY, true) .handler(new ChannelInitializerSocketChannel() { Override protected void initChannel(SocketChannel ch) { ChannelPipeline pipeline ch.pipeline(); pipeline.addLast(new IdleStateHandler(0, 25, 0)); pipeline.addLast(new ProtobufVarint32FrameDecoder()); pipeline.addLast(new ProtobufDecoder(MessageBase.Message.getDefaultInstance())); pipeline.addLast(new ProtobufVarint32LengthFieldPrepender()); pipeline.addLast(new ProtobufEncoder()); pipeline.addLast(new HeartbeatHandler()); pipeline.addLast(new BusinessHandler()); } }); doConnect(); } private void doConnect() { ChannelFuture future bootstrap.connect(host, port); future.addListener((ChannelFutureListener) f - { if (!f.isSuccess()) { // 连接失败3秒后重新尝试 f.channel().eventLoop().schedule(this::doConnect, 3, TimeUnit.SECONDS); } }); } }这段代码有两个地方值得展开讲讲。第一IdleStateHandler(0, 25, 0)意思是写空闲25秒就触发WRITER_IDLE事件。客户端只需要在写空闲触发时发一个Ping包不需要关心服务端有没有回包。为什么要以写空闲作为心跳触发的条件因为如果采用定时发送万一当前连接上有频繁的业务数据在交互再额外发心跳就是浪费。而以写空闲作为触发条件可以保证只有在一个时间段内没有任何数据发出的情况下才发送Ping这样就自然地把心跳和业务数据交织起来了。第二重连用的是f.channel().eventLoop().schedule(...)这就保证了重连成功之后新连接会注册在同一个EventLoop上这个链路是线程安全的。而且通过事件循环自身的调度器来发起重连不会出现多个线程并发重连的问题。但是重连也存在一个隐患如果服务端真的挂了客户端每3秒尝试重连一次成千上万个客户端同时发起重连就形成了“重连风暴”很可能把刚恢复的服务再次打挂。防御这个问题的常见做法是在重连的nextAttemptDelay上做指数退避并加上一个随机抖动。比如第一次失败等1秒第二次等2秒第三次等4秒……封顶60秒再加上一个0到1000毫秒的随机数让所有客户端的重连请求分布在不同的时间点上。下面这段代码可以直接用private void doConnect() { ChannelFuture future bootstrap.connect(host, port); future.addListener((ChannelFutureListener) f - { if (!f.isSuccess()) { long nextDelay Math.min(retryCount * 1000L ThreadLocalRandom.current().nextInt(1000), 60000L); f.channel().eventLoop().schedule(this::doConnect, nextDelay, TimeUnit.MILLISECONDS); } }); }3.3 扩展思考这层架构还可以怎么长如果你只做单机版的TCP长连接服务到这里核心代码已经完整了。但在一开始我就说了高可用不只是单机层面的事情。把眼光放到集群层面这套设计还需要考虑几件事。第一如果服务有多个节点一个客户端连接到了节点A下一次重连却连到了节点B节点B怎么知道这个客户端之前的状态这就需要在握手认证时让客户端带上用户ID或者设备ID节点B去Redis或者数据库里查一下这个用户的登录态校验通过后重建状态。这也是为什么我在ChannelInitializer里加了一个AuthHandler的原因它就是在做身份校验和状态重建。第二消息推送怎么做比如服务端要主动向某个用户推送一条消息但这个用户连接在节点A上推送服务怎么找到节点A常见方案是建立一个路由表也就是用用户ID做key、节点地址加ChannelID做value存在Redis里。每次连接建立、断开时更新这张表推送时先查表再转发。第三这个连接管理模块和业务系统怎么解耦实际项目中业务逻辑一般不会直接写在Netty的Handler里而是通过消息队列、RPC调用等方式转发给后端的业务服务。Netty这一层只负责保持连接、处理协议、做心跳检测业务数据到达后解码成业务消息投递到MQ或者通过HTTP调用业务接口然后异步把结果写回客户端。这样一来长连接网关可以独立扩缩容业务服务也可以独立部署。4. 高可用构建优雅停机、全链路监控与性能调优4.1 优雅停机发布一次不能把线上连接全部搞断如果说心跳机制解决的是“连接坏了怎么发现”那优雅停机解决的就是“主动断开时怎么让客户端无感”。每次服务端发布新版本如果直接kill进程所有TCP连接会立刻断开客户端会疯狂重连新启动的服务节点一瞬间被连接风暴打垮。这是很多长连接服务的故障高发场景。优雅停机的思路很简单进程准备退出前先停掉接收新连接的端口然后给所有现存连接发一个“服务端即将下线”的消息等客户端收到消息后主动断开或者等待客户端自己检测到断线后重连到其他节点最后再真正退出进程。在Netty里实现优雅停机分两步。首先是JVM层面的ShutdownHookRuntime.getRuntime().addShutdownHook(new Thread(() - { log.info(收到停机信号开始优雅停机); bossGroup.shutdownGracefully(); workerGroup.shutdownGracefully(); // 等待所有连接处理完当前请求 try { bossGroup.terminationFuture().sync(); workerGroup.terminationFuture().sync(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } log.info(优雅停机完成); }));ShutdownHook里的shutdownGracefully会先停止接受新连接然后等待已经注册的Channel把当前正在处理的读写事件执行完再关闭所有连接。但是这里有个隐藏的问题如果有一些连接长期没有事件发生也就是空闲连接shutdownGracefully可能会一直等下去。所以真要实现优雅停机还需要一个主动通知客户端的动作让客户端收到通知后主动断开。这个通知消息可以通过现有的Channel直接写出去// 停机前给所有连接发送下线通知 for (Channel channel : channelGroup) { MessageBase.Message message MessageBase.Message.newBuilder() .setCmd(MessageBase.CommandType.SHUTDOWN_NOTICE) .setContent(服务端即将重启请重新连接) .build(); channel.writeAndFlush(message); }这里的channelGroup是Netty提供的ChannelGroup它是一个线程安全的连接集合可以在ChannelActive时添加ChannelChannelInactive时移除Channel。用ChannelGroup的好处是你可以一次性给所有连接广播消息不用自己维护一个ConcurrentHashMap再手动遍历。等到客户端收到SHUTDOWN_NOTICE消息后主动发起重连逻辑尽量不用等TCP超时这样整个切换过程对用户来说基本是无感的。4.2 监控与可观测性高可用服务必须有的“仪表盘”服务启动起来谁都会写但线上出了问题能不能快速定位才是高可用的分水岭。我强烈建议把以下几项指标从最开始就埋好。第一项是连接数统计。每增加一个活跃连接就加一每断开一个就减一同时单独统计当前处于空闲状态的连接数和已认证连接数。连接数异常上涨或者下跌往往是故障的最早信号。第二项是消息吞吐量和延迟。每秒钟处理的入站消息数和出站消息数、单条消息从入站到出站的平均耗时这两个指标能直接反映服务的健康程度。如果消息量没变但处理耗时明显上升大概率是线程池阻塞或者GC变频繁了。第三项是心跳成功率。统计每次发送Ping后收到Pong的比例如果成功率突然下降说明网络链路或对端服务出现了问题。埋点的方式可以直接在Handler里加计数器简单的可以用AtomicLong量大了可以接入Micrometer把指标暴露给Prometheus。我个人的习惯是核心指标一定用Micrometer做全局统一管理日志只记录关键事件比如连接异常断开、服务端主动关闭、认证失败等避免每条心跳都打日志把磁盘刷爆。4.3 性能调优从两万连接到十万连接服务上线初期两万连接跑着没问题等到用户量起来后连接数涨到十万你可能会发现GC时间变长、CPU飙高、心跳延迟变大。这个时候需要从几个方面去排查。线程数是最容易想到的但也很容易调错。如果你发现Worker线程频繁在Netty的任务队列里堆积任务可以观察是否有业务逻辑里做了同步的数据库查询或者第三方RPC调用。解决的方向不是调大线程数而是把耗时操作移出IO线程。比如把业务处理扔进独立的业务线程池或者用异步方式转发到MQNetty线程只干网络读写和协议编解码从源头保证IO线程不被阻塞。内存方面Netty的池化内存默认使用堆外内存默认情况下Netty会按照可用的堆内存的2/3来作为最大堆外内存大小但这会受JVM参数配置影响。线上遇到内存问题主要还是先看堆内存的GC表现再看堆外内存是否泄漏。Netty自带了NettyRuntime.availableProcessors()来探测可用CPU适合大多数场景。另外大流量场景下可以开启ChannelOption.WRITE_BUFFER_WATER_MARK来控制写缓冲防止某个慢消费者把服务端内存耗尽。一般设置成low32KB、high64KB如果单个连键的写缓冲达到high水位说明这个客户端消费不过来了服务端可以做限流或者直接断开连接。5. 常见问题与避坑指南这些坑我都是真金白银踩出来的5.1 粘包/拆包问题为什么服务端收到了乱码TCP是流式协议没有消息边界。你发送的包可能会被合并成一个包发送粘包也可能被拆成多个包发送拆包。如果不对消息做帧界定服务端收到的数据就会出现错乱。很多新手第一次写完Netty服务用固定长度的消息测试一切正常一旦做压力测试数据就变得支离破碎。解决办法就是在Pipeline里加入FrameDecoder。我上面用的是ProtobufVarint32FrameDecoder它的原理是在每个消息前加一个Varint32类型的数据头用来声明消息长度。解决粘包拆包的问题一定要放在解码器的第一层也就是Pipeline的最前面然后在这个基础上再做业务的字节解码。如果你用的是文本协议那就用LineBasedFrameDecoder按换行符分割或者用DelimiterBasedFrameDecoder按自定义分隔符分割。注意HTTP协议实际上是基于行分隔的文本协议所以HttpServerCodec内部就是组合了HttpRequestDecoder和HttpResponseEncoder底层也处理了帧。5.2 直接在Handler里做耗时操作把事件循环卡死了我见过一个非常典型的线上事故某个团队在Netty的Handler里直接调用某个后端的同步HTTP接口这个接口偶尔超时最坏情况要等几十秒。结果就是一旦有连接触发了这个Handler处理它的Work线程就被卡住几十秒而这个Work线程同时要负责几百个连接的读写其他所有连接都被拖慢了。Netty官方文档强调的三条铁律是不能在EventLoop里做阻塞操作、不能直接在线程里调用Channel方法、不能没有边界地使用线程池。如果你确实要把业务逻辑放在Handler里做一定要把耗时操作丢到独立的业务线程池处理private final ExecutorService businessExecutor Executors.newFixedThreadPool(16); Override protected void channelRead0(ChannelHandlerContext ctx, MessageBase.Message msg) { businessExecutor.submit(() - { // 耗时业务处理 Object result heavyBusiness(msg); // 处理完成后把结果写回 ctx.channel().writeAndFlush(result); }); }注意这里有个细节从业务线程池里写回数据时writeAndFlush是线程安全的因为Netty的Channel内部会把写操作封装成任务丢回EventLoop执行所以你可以放心地在任意线程里调用channel.writeAndFlush不需要担心线程安全问题。5.3 ByteBuf的释放问题内存泄漏排查实录Netty使用引用计数器来管理ByteBuf的内存默认情况下解码后的ByteBuf在Handler链路上传递时使用完就会被自动释放但你如果尝试在业务里保存这个ByteBuf引用稍不注意就会造成内存泄漏。我遇到过一次堆外内存泄漏事故是业务代码把收到的ByteBuf对象存在了一个静态Map里传给后面的线程处理结果下游处理失败后一直没有释放。排查这种问题最快的方式是开启Netty的内存泄漏检测设置JVM参数-Dio.netty.leakDetection.levelparanoid然后观察日志里是否有LEAK提示。如果是使用了ByteBuf但没释放日志里会明确告诉你是在哪个Handler、哪行代码创建了这个ByteBuf。当然最简单的规避方式是尽量使用字符串或者Protobuf对象作为Handler之间传递的消息载体只有在你确实需要操作二进制协议时再去碰ByteBuf。SimpleChannelInboundHandler的channelRead0方法设计成自动释放消息也是这个原因——它会在回调里面帮你把消息的引用计数减掉。5.4 连接数上来了但内存暴涨Channel和缓冲区被谁占了正常情况下一万个TCP连接所占的内存并不高因为每个空闲连接占用的资源很少。但如果你发现服务内存很高优先排查三个方向一是每个连接是否注册了多个HandlerHandler里的实例字段是否存了不该存的业务数据二是写缓冲区是否被某些慢客户端拖住了三是ChannelGroup里是否保存了已经关闭的Channel引用导致无法回收。有一种常见场景是客户端断线后TCP四次挥手没有正常完成连接处于CLOSE_WAIT状态服务端的Channel对象也就一直存在。解决办法有两个层面操作系统层面调小tcp_keepalive_time和tcp_fin_timeout应用层面临结合我们之前说的心跳检测机制让服务端在空闲超时后主动关闭这些连接。5.5 笔记一套可以直接用的学习调试方法最后再说个调试上的小技巧。我在本地开发Netty服务时从来不用肉眼去看到底收到了什么字节。配置好Wireshark或者直接用TCP客户端工具先测试连接再用Netty日志看调试输出。Netty自带的日志Factory支持动态调整级别把io.netty.handler.logging.LoggingHandler加到Pipeline里pipeline.addLast(new LoggingHandler(LogLevel.DEBUG));这个Handler会把你经过它的每个ByteBuf的十六进制内容、读写方向、字节数全部打印出来。写编解码器时这个日志非常有用基本能把80%以上的协议解析问题定位出来。注意生产环境一定要关掉这个Handler否则日志量能把磁盘写满。6. 总结一下这套方案的完整链路写到这里从最开始说“为什么要做长连接”到启动Netty服务、心跳检测、自动重连、优雅停机再到常见的粘包拆包、内存泄漏排查基本把一条完整的生产链路串起来了。总结下来就三句话连接管理要用好Pipeline的Handler职责边界心跳机制一定要服务端和客户端成对配合高可用是靠优雅停机和自动重连一层一层堆出来的。我在实际项目中把这套方案部署上线后最明显的一个变化是线上基本再也没出现过“连接池被打满”这种告警。以前排查问题总是被各种奇奇怪怪的网络异常牵着鼻子走现在有了心跳兜底、有了状态监控、有了重连的退避策略就算是凌晨两点被叫起来处理故障也能很快定位到是物理链路问题还是服务本身的问题。留给你的建议是不要把这套代码原样搬到生产就完事一定要根据自己的协议、业务场景做调整。比如物联网设备的电量限制可能要求心跳间隔放到120秒金融行情场景可能要求消息的可靠性达到不丢包的程度这些都需要你对Netty的机制有足够深的理解后再做针对性优化。先把框架跑通再深入原理最后再改造成适合自己业务的样子这是我眼中最稳的一条学习路径。