Netty自学实战：从NIO到WebSocket推送的完整进阶指南

Netty这个词在我这两年自学Java后端的过程中属于绕不开的一座山。第一次认真接触它不是在实际项目里而是在准备面试的时候——满屏都是“Netty面试必问”“深度剖析Netty源码”看标题就觉得头皮发麻。但光看不练没用直到我照着公开课动手写了一个WebSocket推送服务又把它塞进一个真实的IM模块里跑起来才真正理解了为什么Netty能成为网络编程领域绕不开的框架它不只是NIO的封装更是一套覆盖了线程模型、协议处理、异常补偿的完整解决方案。这篇文章就把我自学Netty的完整思路串一遍——核心组件怎么理解、工作过程怎么拆解、WebSocket怎么落代码、面试题怎么答才不虚以及我踩过的几个坑。适合刚学完Java基础、想往网络编程深水区走一步的同学也适合那些Netty面试题背了几十遍但一追问就卡壳的朋友。1. 为什么是Netty从BIO到NIO再到Netty的演进1.1 传统BIO的网络编程到底卡在哪很多初学Java的人第一次写网络程序用的都是最传统的BIO。一个ServerSocket一个while循环每来一个连接就new一个线程去处理。代码写起来确实爽逻辑顺着写就行但并发稍微上来就崩。我当初在学校写课程设计时用BIO做了一个文件传输工具单机扛五个连接没问题到五十个连接的时候线程数直接爆掉CPU频繁切换上下文响应越来越慢最后直接OutOfMemory。问题本质在于BIO是“一连接一线程”的模型每个线程默认分配1MB左右的栈空间就算连接什么都不干线程资源也在那儿干等着。而且阻塞调用会让线程在read的时候挂起调用方根本没法控制这个连接什么时候有数据进来。这在连接数少的时候没事一旦连接数变成上千上万操作系统光管理线程就崩溃了。1.2 NIO的三板斧Channel、Buffer、SelectorJava在1.4版本引入了NIO也就是Non-blocking IO核心思路和BIO完全不一样。它用Channel替代了Stream用Buffer承载数据最关键的是引入了Selector多路复用器。Selector的作用往通俗了说就像一个前台分诊台。原来每个连接都需要一个专职服务员站在门口等消息现在一个前台可以同时盯着几百个窗口哪个窗口有人来了就去处理哪个没人来就继续等着。一个线程通过Selector可以管理成千上万个连接这就解决了BIO最致命的线程资源问题。NIO本身是能用的但工程代码写起来极其别扭。比如ByteBuffer的position、limit、flip、compact这一套状态切换稍不注意就写出难察觉的bug。再加上要自己处理半包、粘包、断线重连、线程切换这些问题纯手写NIO做生产级服务工作量和出错率都非常惊人。1.3 Netty到底多做了什么Netty正是在NIO之上建立的框架。但如果你理解成“Netty就是封装了一下NIO”那就太浅了。Netty真正的价值是把Reactor线程模型、事件驱动机制、责任链式的Handler编排、内存池化管理、超时重连机制、协议编解码等等这些工程上极其头疼的问题全部做成了开箱即用的组件。我当初用原生NIO写一个最简单的Echo服务光处理accept、read、write、异常断开就花了两天代码堆了三百多行测试时还会偶发触发重复读的bug。换Netty之后同样的功能几十行代码搞定而且模型清晰得多后期要加协议、加心跳、加鉴权都是在Pipeline里加一个Handler的事。另外Netty不是Java独有的概念很多语言都有同类框架。比如.NET里的DotNetty就是微软社区对Netty的移植版API设计基本一致用于在C#体系下实现高性能网络通信。Python那侧的Twisted、Go语言内置的net包配合goroutine模型也是解决同一个问题。理解了Netty的设计思想换语言去做网络编程很多思路都是相通的。1.4 自学时首先要建立的认知我自己学Netty最大的一个弯路是刚开始就扎进源码细节里出不来。看EventLoop源码、看ChannelOutboundBuffer源码看了三天脑子里只有一堆类名和调用链合上电脑什么都说不出来。后来我才调整策略先去通过官方文档和公开课把这几个组件的“定位和责任”搞清楚再去看源码实现细节。弄懂NIO为什么重要、Netty在NIO之上加了什么这比记住某个方法的源码实现重要得多。有了这个大方向的认知后面学什么组件都能往这个框架里塞。2. Netty核心组件拆解从类名到职责2.1 EventLoopGroup线程池的代言人EventLoopGroup字面意思是事件循环组本质上就是一组线程的集合。每一个EventLoop都对应一个线程负责处理注册到它上面的所有Channel的IO事件。我一开始特别困惑一个问题为什么叫EventLoop不直接叫WorkThread后来动手做实验才明白这个线程不是传统意义上的“处理完一个任务就退出”而是启动后进入一个无限循环反复执行三个动作从任务队列里取任务、执行IO事件、处理定时任务。这个循环在Netty中就是整个系统的动力源。默认情况下如果不指定线程数Netty会根据CPU核数自动计算通常为CPU核数的两倍。服务端的workerGroup我习惯显式指定一般压测几次后看CPU和延迟表现再定。EventLoopGroup bossGroup new NioEventLoopGroup(1); EventLoopGroup workerGroup new NioEventLoopGroup(4);这里有一个很容易被忽略的点同一个EventLoop线程会绑定了多个Channel所以EventLoop里的Handler绝对不能做耗时太久的操作。一旦阻塞所有绑定在这个EventLoop上的Channel都会被拖慢这也是Netty高性能模型中最需要注意的约束。2.2 Channel和ChannelFuture异步操作的锚点Channel在Netty里代表一个网络连接可以理解为BIO里的Socket的增强版但它不是简单的封装而是实实在在提供了读写、绑定、连接等异步操作。Netty里几乎所有的IO操作都是异步的这意味着调用返回的不是结果本身而是一个ChannelFuture对象。比如ChannelFuture f bootstrap.connect(127.0.0.1, 8080); f.addListener((ChannelFutureListener) future - { if (future.isSuccess()) { System.out.println(连接成功); } else { System.out.println(连接失败); future.cause().printStackTrace(); } });我刚开始学异步的时候最大的不适点是思维习惯。传统的写法是“调用—等待—拿到结果”Netty是“调用—注册监听—结果出来通知我”。想明白这个模式之后再看Netty的其他异步方法就顺了。顺便说一下如果你不想用Listener也可以调用f.sync()把异步转同步但实际生产中我很少用sync因为那就把整个异步模型的意义给抹掉了。2.3 ChannelPipeline与ChannelHandler处理管道的积木ChannelPipeline是Netty最核心的设计之一它把一条连接上的数据处理流程拆成了一串有序的ChannelHandler对象。数据从网络进来会依次经过Pipeline上的每个入站Handler要发出的数据则会从尾部逆向往头部经过所有出站Handler。我特别喜欢的类比是流水线作业。汽车在生产线上经过装配、喷漆、检测多个工位每个工位只负责自己的事。Netty的Pipeline也是一样解码器负责把字节流变成Java对象业务Handler负责处理对象编码器负责把输出对象变成字节流。这种设计让每个Handler都保持简单也让代码可以自由插拔。Pipeline里的两个核心方法一个是read操作产生的入站流程一个是从write开始的出站流程。入站由HeadContext往TailContext方向传递出站正好相反。如果中间某个Handler不调用fireChannelRead或write方法事件流就会中断这个特性可以用在鉴权Handler里拦截非法的请求。2.4 ByteBuf比ByteBuffer好用一百倍的缓冲区刚接触Netty的时候我花了不少时间适应ByteBuf。它和NIO里的ByteBuffer相比最大的改进是内部同时维护了readerIndex和writerIndex两个指针。读和写不用来回切换flip读写操作直接往里干就行。实际使用中我总结出几个高频方法byteBuf.readableBytes()判断可读字节数用于半包判断。byteBuf.readBytes(byte[])按指定长度读取数据。byteBuf.writeBytes(byte[])写入数据。byteBuf.release()释放引用计数显式释放避免内存泄漏。ByteBuf还分堆内缓冲和直接缓冲。直接缓冲用的是堆外内存在进行IO读写时可以减少一次内存拷贝能提升一些性能但分配和回收成本比堆内高。Netty默认用的是池化的直接缓冲工程上一般不需要你手动选除非你对内存管理非常了解。2.5 Bootstrap和ServerBootstrap启动引导器客户端用Bootstrap服务端用ServerBootstrap这俩名字很像但职责有区别。Bootstrap负责连接远端并初始化客户端Channel它只有一组EventLoopGroupServerBootstrap负责监听端口有两组EventLoopGroup一组处理新的连接接入另一组处理已经建立的连接的IO。ServerBootstrap b new ServerBootstrap(); b.group(bossGroup, workerGroup) .channel(NioServerSocketChannel.class) .option(ChannelOption.SO_BACKLOG, 128) .childOption(ChannelOption.SO_KEEPALIVE, true) .childHandler(new ChannelInitializerSocketChannel() { Override protected void initChannel(SocketChannel ch) { ch.pipeline().addLast(new MyHandler()); } });这里要特别说明一下option和childOption的区别。option是应用在服务端ServerSocketChannel上的比如SO_BACKLOG它决定的是操作系统返回给还没被accept的连接队列的最大长度childOption是应用在每个新建立的SocketChannel上的比如SO_KEEPALIVE、TCP_NODELAY。这个区别我踩过坑开始搞混的时候设置了childOption却发现在服务端channel上不生效排查了半天。3. Netty工作过程拆解从连接到数据的完整链路3.1 服务端启动时Netty做了什么面试时被问到“Netty服务端启动流程”很多人只会背“创建bossGroup和workerGroupbind端口”。但如果你真的跑过调试会发现启动阶段Netty有条不紊地做了这些事情第一步创建ServerSocketChannel用它监听指定端口。第二步把ServerSocketChannel注册到bossGroup里的某个EventLoop注册的是OP_ACCEPT事件。第三步调用bind方法完成端口绑定。第四步bossGroup里的EventLoop进入循环开始等待新的连接到来。这个过程用动画来理解更形象bossGroup相当于大门口的门卫它的工作是盯着大门——也就是服务端Channel。当有新访客到来时门卫不亲自接待而是把访客带进来交给workerGroup里的某个员工去负责后续所有的互动。我刚学的时候就把这个动画在脑子里过了一遍后面再看到源码调用点基本都能对上。3.2 新连接接入时一系列精妙的分发过程当客户端发起连接操作系统完成三次握手后serverChannel上会产生OP_ACCEPT事件。Netty的boss EventLoop读取到这个事件调用ServerSocketChannel的accept方法得到一个NioSocketChannel。这个新连接不会被bossEventLoop继续处理而是会被注册到workerGroup的某一个EventLoop上。这里的注册过程很关键新Channel会绑定到一个EventLoop之后该连接上的所有IO事件和Handler执行都发生在同一个线程里。这种设计避免了多线程并发访问同一个Channel时的锁竞争也是Netty高性能的重要保障。我在这里做实验的时候发现一个坑如果你在childHandler里用的是延时加载的handler但handler本身不是线程安全的并且Channel被分到了多个EventLoop上那这些handler就会被多个线程访问。所以写Handler时要么不存有状态要么用线程安全的数据结构要么用EventExecutor隔离。3.3 数据读取和解码一次请求在Pipeline中的游历假设客户端发来一段文本数据Netty的数据流会是这样首先EventLoop检测到某个Channel上有OP_READ事件调用NIO的read方法把内核缓冲区的数据读到ByteBuf中。然后Netty封装一个ChannelRead事件从Pipeline的头部开始传播。解码器Handler读取ByteBuf里的字节按照协议转换成对象比如StringDecoder会把字节序列转成字符串。转换完之后调用fireChannelRead由下一个Handler继续处理。依次经过多个Handler最后到达业务Handler完成业务逻辑处理。如果协议比较复杂比如自定义二进制协议就需要在Handler里仔细分帧。这就是面试中常说的“粘包和拆包”问题。TCP是流式协议它不保证一次read能读到完整的一帧数据可能一次性读到多个消息也可能一个消息分两次才读完。Netty提供了LineBasedFrameDecoder、DelimiterBasedFrameDecoder、LengthFieldBasedFrameDecoder等解码器来解决这个问题其中LengthFieldBasedFrameDecoder在自定义协议中最常用。字段说明 - maxFrameLength单帧最大长度 - lengthFieldOffset长度字段偏移量 - lengthFieldLength长度字段字节数 - lengthAdjustment长度字段后需要跳过的字节数 - initialBytesToStrip从帧头开始跳过的字节数这几个参数我第一次看的时候一脸懵后来自己抓包验证才完全明白。举个最简单的场景协议是“2字节长度 2字节消息类型 N字节正文”那么配置就是new LengthFieldBasedFrameDecoder( 1024, // maxFrameLength单帧最大1024字节 0, // lengthFieldOffset长度字段从0开始 2, // lengthFieldLength长度字段占2字节 0, // lengthAdjustment长度字段后面没有额外头 4 // initialBytesToStrip整个帧头共4字节交给业务前去掉 )这个解码器帮我解决了大量协议处理问题。我一开始没有用它自己手工攒buffer代码写得又乱又有边缘bug后来换上去之后一个类搞定。3.4 写出数据时反向流经Pipeline输出数据的路径和读取正好相反。业务Handler调用ctx.writeAndFlush(Object msg)之后对象会从Pipeline的尾部向头部传播经过编码器转换成ByteBuf最终到达HeadContext写入SocketChannel。有一点需要注意write方法只是把对象放入了事件流真正写出去要执行flush。Netty的writeAndFlush是write加flush的快捷方式。如果只write不flush数据会积攒在缓冲区直到缓冲区满了才发送这在有些场景可以提升性能减少IP包数量但控制不好就会出现数据延迟送达的问题。我在做实时推送时明确走writeAndFlush保证每条消息尽快到达客户端。4. 用Netty实现WebSocket推送服务的完整实操4.1 为什么WebSocket场景特别适合NettyWebSocket是一种在TCP之上实现全双工通信的协议一次握手建立长连接后服务端可以主动向客户端推送数据。传统HTTP轮询要么延迟高要么浪费带宽WebSocket天然适合IM、实时通知、协同编辑这类场景。Netty对WebSocket提供了非常完整的支持从HTTP升级握手到帧解析都有现成的Handler。我当时做IM模块核心诉求就是一个服务端要能扛住几千个WebSocket长连接并且支持频繁的心跳和消息推送。Netty的EventLoop模型天然擅长处理大量空闲连接因为一个线程可以同时盯很多连接的事件真正空闲的连接不需要独占线程。4.2 服务端核心代码四条Handler搞定协议层直接用Netty搭建WebSocket服务端代码量不大关键在Pipeline的配置顺序。EventLoopGroup bossGroup new NioEventLoopGroup(1); EventLoopGroup workerGroup new NioEventLoopGroup(Runtime.getRuntime().availableProcessors() * 2); try { ServerBootstrap bootstrap new ServerBootstrap(); bootstrap.group(bossGroup, workerGroup) .channel(NioServerSocketChannel.class) .option(ChannelOption.SO_BACKLOG, 128) .childOption(ChannelOption.TCP_NODELAY, true) .childOption(ChannelOption.SO_KEEPALIVE, true) .childHandler(new ChannelInitializerSocketChannel() { Override protected void initChannel(SocketChannel ch) { ChannelPipeline pipeline ch.pipeline(); // HTTP编解码器用于处理WebSocket握手时的HTTP请求 pipeline.addLast(new HttpServerCodec()); // 聚合HTTP请求避免分片导致握手中断 pipeline.addLast(new HttpObjectAggregator(64 * 1024)); // WebSocket协议处理器负责升级连接、帧解析、关闭等 pipeline.addLast(new WebSocketServerProtocolHandler(/ws)); // 自己的业务处理器 pipeline.addLast(new MyWebSocketHandler()); } }); ChannelFuture future bootstrap.bind(8080).sync(); future.channel().closeFuture().sync(); } finally { bossGroup.shutdownGracefully(); workerGroup.shutdownGracefully(); }这里顺序不能乱。HttpServerCodec必须放在前面因为客户端第一次发过来的是HTTP格式的握手请求。HttpObjectAggregator的作用是把分片到达的消息拼成完整请求少了他有些浏览器的握手请求会解析失败。WebSocketServerProtocolHandler负责处理升级逻辑以及之后的WebSocket帧解析。最后才是业务逻辑。4.3 业务Handler消息分组与推送MyWebSocketHandler的核心逻辑是维护一个连接池比如按用户ID分组然后支持向指定用户推送。public class MyWebSocketHandler extends SimpleChannelInboundHandlerTextWebSocketFrame { // 全局在线用户映射key为用户IDvalue为Channel private static final ConcurrentHashMapString, Channel ONLINE_USER new ConcurrentHashMap(); Override public void handlerAdded(ChannelHandlerContext ctx) throws Exception { System.out.println(新连接接入 ctx.channel().remoteAddress()); } Override public void channelActive(ChannelHandlerContext ctx) throws Exception { // 客户端连接建立后在这里可以发一条欢迎消息 ctx.channel().writeAndFlush(new TextWebSocketFrame(连接成功)); } Override protected void channelRead0(ChannelHandlerContext ctx, TextWebSocketFrame msg) throws Exception { String text msg.text(); System.out.println(收到消息 text); // 简单回显实际项目中可以按业务逻辑处理 ctx.channel().writeAndFlush(new TextWebSocketFrame(服务端收到 text)); } Override public void channelInactive(ChannelHandlerContext ctx) throws Exception { // 连接关闭时从在线用户表移除 ONLINE_USER.values().remove(ctx.channel()); System.out.println(连接关闭 ctx.channel().remoteAddress()); } Override public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception { cause.printStackTrace(); ctx.close(); } }SimpleChannelInboundHandler会自动释放引用计数如果是直接用ChannelInboundHandler读到的消息用完以后必须手动release不然内存泄漏。我在早期写代码时直接用了ChannelInboundHandler漏了release跑了一天后堆外内存一直涨最后通过Netty自带的内存泄漏检测日志才发现问题。4.4 心跳保活与空闲检测WebSocket长连接最怕的就是连接其实已经断了但两端都不知道导致服务端维护了一堆死连接。我实际测试时手机切后台一会儿TCP连接可能就被运营商或代理设备悄悄断掉了此时服务端没有收到任何FIN包。Netty提供了一个现成的IdleStateHandler可以定时触发空闲事件配合心跳包来自动踢掉假死连接。pipeline.addLast(new IdleStateHandler(60, 0, 0, TimeUnit.SECONDS));这段代码表示如果客户端60秒内没有读事件就触发一个IdleStateEvent。然后在Handler里重写userEventTriggered方法Override public void userEventTriggered(ChannelHandlerContext ctx, Object evt) throws Exception { if (evt instanceof IdleStateEvent) { IdleStateEvent event (IdleStateEvent) evt; if (event.state() IdleState.READER_IDLE) { System.out.println(60秒没读到数据主动关闭连接); ctx.close(); } } super.userEventTriggered(ctx, evt); }实际玩过一圈之后我发现60秒的阈值太小了。有用户挂着页面看文章超过60秒不动就连接被切断了。后来我把读空闲时间调到了120秒客户端每30秒发一次心跳这样即使偶尔有网络抖动也不容易把正常用户误踢。4.5 性能调优的几个真实参数在压测阶段我记录了几个对性能影响很大的参数配置之后效果立竿见影ChannelOption.SO_BACKLOG服务端可接受未处理连接队列的长度。默认128并发高但连接建立慢时可以提高这个值比如配置成1024。ChannelOption.TCP_NODELAY设为true禁用Nagle算法。Nagle算法会把小包合并发送追求网络吞吐但会增大延迟做实时推送必须关闭它。ChannelOption.SO_KEEPALIVE开启TCP层的keepalive探测。不过它默认探测周期很长应用层心跳仍然是必要的。ChannelOption.ALLOCATOR换成池化的ByteBufAllocator可以通过参数指定PalAgedByteBufAllocator.DEFAULT。在大量消息频繁创建缓冲区的场景池化能明显减少GC压力。这些参数不是每种场景都适合照搬。如果是做文件传输注重吞吐TCP_NODELAY可能就不一定划算如果做小消息高频写入TCP_NODELAY一定要打开。5. 面试中被反复拷打的Netty问题5.1 高频题目清单网上流传的Netty面试题很多但翻来覆去就那几个核心问题。我整理了一份自测清单准备面试时逐条过BIO、NIO、AIO模型的区别是什么什么是Reactor模型Netty属于哪种Netty的线程模型是怎么设计的为什么说Netty的Handler中不能有阻塞操作粘包和拆包是什么Netty里怎么解决如何实现客户端断线重连ChannelHandler的Sharable注解是干什么的ByteBuf和ByteBuffer的区别是什么Netty如何检测内存泄漏每道题都不是孤立知识点答题时能串起来讲才是面试官想听的。5.2 核心问题的答题思路“Netty为什么性能高”是最高频的问题我的回答套路是分三层第一层IO模型上用了NIO多路复用一个线程可以管理成千上万连接而不是一连接一线程。第二层线程模型上用了主从ReactorbossGroup只管acceptworkerGroup只管IO读写分工明确。第三层工程优化上做了零拷贝、池化内存、无锁串行设计减少了不必要的内存复制和锁竞争。“粘包拆包怎么解决”这个题先要解释现象TCP是流协议消息没有边界。然后说两种常见做法固定长度解码器、分隔符解码器以及最常用的LengthFieldBasedFrameDecoder。再补充一句设计自定义协议时一定要把长度字段设计好避免歧义。“客户端怎么重连”这个问题我的答案是重写handler的channelInactive方法在里面用EventLoop的schedule方法延迟重连。Override public void channelInactive(ChannelHandlerContext ctx) throws Exception { System.out.println(连接断开3秒后重连...); ctx.channel().eventLoop().schedule(() - { // 在这里重新initialize并connect }, 3, TimeUnit.SECONDS); super.channelInactive(ctx); }关键点是重连逻辑要放在eventLoop里执行不要另起线程否则会打乱Netty的线程模型。同时要加入重试次数限制避免服务端宕机时客户端无限重连刷日志。5.3 面试时容易翻车的细节我见过不少候选人在面试时把NIO和AIO的概念搞混。AIO是异步非阻塞IO但在Linux上的实现其实并不成熟Netty本身的NIO模型已经能覆盖大多数场景所以Netty默认也没有采用AIO。提到这一点说明你对生态有认知。另一个容易翻车的点是很多人说不清EventLoop和线程的关系。记住一句话一个EventLoop维护且只维护一个线程同一条Channel上的所有任务都在这个线程内执行不存在锁竞争。只要把这句话吃透面试官深挖的时候你都能稳住。第三个点是FastThreadLocal和jdkThreadLocal的区别。Netty自己实现了FastThreadLocal通过数组索引替代了ThreadLocal的哈希查找性能更高。但使用它有个前提就是线程最好是Netty的FastThreadLocalThread。面试中能提到这个会给人一种你有深入研究过的印象。6. 自学Netty的路线与踩坑记录6.1 学习路线怎么排如果你现在是零基础我的建议是不要一上来就看源码。我走的路线比较顺供参考第一步掌握Java NIO的基础知识重点理解Channel、Buffer、Selector三件套。这一步不需要太深能理解Selector的工作原理就行。第二步找一套完整的视频课程或文档跟着做一个服务端Demo先不管原理直接把代码敲出来跑通。第三步动手改代码试着加一个解码器、加一个心跳、开两个客户端测试把Pipeline的每条路径都实际走一遍。第四步再回头看书和源码这时候再看EventLoop、ChannelPipeline、内存管理每个概念都有了抓手不会再迷路。6.2 我使用过的学习资源公开课方面尚硅谷那套Netty课程我认为是最适合入门的讲解节奏和项目实践都比较扎实。文档方面Netty官方GitHub上的User Guide非常值得精读篇幅不长但把核心概念讲得清楚。进阶阶段可以去看Netty in Action这本书虽然部分例子老了些但对模型的讲解依然是最好的。最后强烈建议打开IDE对着源码调试尤其是服务端启动流程和一条消息从网络到业务Handler的完整调用链调试一遍比看书十遍都管用。6.3 踩过的一些坑第一个坑是Handler里做了耗时的数据库操作导致所有连接卡顿。原因就在EventLoop模型一个阻塞操作会让当前线程卡住而其他多个Channel都绑定在这个线程上跟着一起卡顿。解决办法是使用独立的业务线程池在Handler里提交异步任务。这里要注意handler里做完异步操作后如果要继续写数据需要把写操作切换回原EventLoop执行否则会有并发问题。第二个坑是自定义解码器写得太随意出现了粘包。我用的是每次read就往List里塞字节然后手动判断长度结果在高并发下数据错位排查了两天才发现是两个连接的消息混在一起了。后来换成LengthFieldBasedFrameDecoder问题直接消失。第三个坑是内存泄漏。有一次写了一个不断创建ByteBuf然后忘记release的Handler压测跑了一会儿后堆外内存飙升操作系统开始频繁swap。Netty在这方面提供了检测机制启动参数加上-Dio.netty.leakDetection.levelparanoid就能在日志中定位到具体的泄漏点和分配点。线上环境如果追求性能可以不开这个参数但测试环境建议一直开着。6.4 从“能用”到“能讲”的最后一公里写完WebSocket服务后再回头整理笔记我发现一个很神奇的现象很多之前背不下来的面试题在动手实现过一遍之后全部变得很自然。因为你不只是记住了结论而是理解了结论背后的问题。比如“为什么Netty要做内存池”如果你自己遇到过Buffer频繁new导致的GC压力这个问题不需要背也能答出来。所以我在笔记里给每个核心概念都配了一个“我遇到的问题”标签。EventLoop对应的是连接变多CPU飙升问题ByteBuf对应的是内存增长问题Pipeline对应的是代码如何组织更优雅的问题。知识一旦有了场景关联记忆就会深很多。自学Netty的路走到这里说不上精通但至少从“看到八股就慌”变成了“知道怎么回事”。后面再进一步可以去看它的源码实现细节、写协议模块、或者看zookeeper、RocketMQ这些项目里Netty是怎么用的。这条路还很长但第一步迈出来之后后面会越走越清晰。