1. 这个系列准备怎么读先说说我为什么决定啃Netty源码。工作里用Netty写RPC框架、网关、IM长连接都写过API层面已经挺熟但总有几件事解释不清楚为什么Netty的worker线程数是CPU核数的两倍就够用pipeline里到底是谁在调谁粘包半包的解码器凭什么能把字节流拆成一个个完整业务包这些问题不翻源码永远只能靠背结论。这个系列我打算按“运行主线”来推进不按类库顺序罗列。第一讲先把地图铺开Netty启动时发生了什么、一个连接进来后数据怎么流动、ChannelPipeline如何串联起所有处理器。后面几讲再逐个深入EventLoop、内存管理、编解码和可靠性机制。读源码前有几点先说明白。版本选择我基于Netty 4.1.x系列具体是4.1.90.Final。主分支和4.0系列在不少类上差异较大看4.1比较典型生产环境也大多是4.1。建议用IntelliJ IDEA打开源码工程直接点进类里看不要只看反编译出来的零碎片段。读代码顺序优先读“运行时被你触发的代码”也就是main线程、NIO线程、业务线程三者的调度逻辑。配置类、工具类的源码可以先跳过比如FastThreadLocal、时间轮这些等主线清晰了再回来补。抓大放小源码里有大量分支和兼容逻辑第一遍不要每个if都追问为什么。先锁定核心路径比如NioEventLoop的run方法、AbstractChannelHandlerContext的invoke方法这些是主干。2. 一张地图Netty究竟在解决什么问题读Netty源码前必须先理解它站在什么位置上解决问题。JDK从1.4开始提供NIONIO和传统BIO最大的差异是可以让一个线程同时管理成千上万条连接。但直接写NIO是很痛苦的ByteBuffer的flip、compact、remaining你得手动处理SelectionKey上的事件你得自己分发半包粘包你得自己从流里拼装连接断开和重连你得自己维护状态机。Netty做的事情是把NIO里这些繁琐且容易出错的部分统一封装好并且额外给出了两个关键设计。第一层线程模型的事件封装JDK的NIO底层是一个Selector线程不断查就绪事件查询到OP_ACCEPT就创建连接查询到OP_READ就在对应Channel上读数据。Netty把这件事抽象成了EventLoop事件到来后封装成任务投递给pipeline由ChannelHandler消费。第二层数据流动的管道抽象每个Channel对应一个ChannelPipelinepipeline里串了一串ChannelHandler。数据从网络读到之后按出站方向从头到尾经过入站处理器业务线程要写数据时从尾到头经过出站处理器。这其实是责任链模式。对于业务开发来说你根本不需要关心Socket细节只需要在pipeline上挂处理器处理读到的业务对象。用最简单的话总结Netty在Java NIO之上做了一层面向业务的编程模型把字节流、事件、连接生命周期全部编排好开发者只需要写纯业务逻辑。这个设计直接带来的好处业务代码和底层I/O完全解耦同一条连接上的读写事件天然串行不需要加锁线程模型清晰一个EventLoop负责多个Channel不跨线程调度数据。读源码时始终带着这些认知就能知道每个类是在承担哪一层职责。3. 启动链路源码ServerBootstrap到底做了什么启动代码大家都写过EventLoopGroup bossGroup new NioEventLoopGroup(1); EventLoopGroup workerGroup new NioEventLoopGroup(); ServerBootstrap bootstrap new ServerBootstrap(); bootstrap.group(bossGroup, workerGroup) .channel(NioServerSocketChannel.class) .childHandler(new ChannelInitializerSocketChannel() { Override protected void initChannel(SocketChannel ch) { ch.pipeline().addLast(new HeartbeatHandler()); } }) .bind(8080);你觉得这行.bind(8080)执行完之后底层做了什么源码里最重要的一个节点是AbstractBootstrap.doBind0。它向bossGroup注册了一个任务这个任务最终会走到NioServerSocketChannel.doBind方法通过JDK的ServerSocketChannel.bind真正绑定端口。注意一个细节bind是异步的。调用后立刻返回真正的端口监听是在某个EventLoop线程里执行注册任务时完成的。如果你需要确认绑定完成要使用ChannelFuture.addListener或.sync()。接下来是initAndRegister干了两件事创建Channel实例、完成pipeline初始化。创建Channel时通过ReflectiveChannelFactory反射构造NioServerSocketChannel。构造NioServerSocketChannel时底层会调用JDK的ServerSocketChannel.open()并设置非阻塞还会在构造内部就创建一个默认的ChannelPipeline。于是问题来了pipeline在channel构造时就存在了但ChannelHandler还没加。这些是在bind流程里由ServerBootstrap.init完成的。init方法里有一段很关键的代码p.addLast(new ChannelInitializerChannel() { Override public void initChannel(final Channel ch) { final ChannelPipeline pipeline ch.pipeline(); ChannelHandler handler config.handler(); if (handler ! null) { pipeline.addLast(handler); } ch.eventLoop().execute(new Runnable() { Override public void run() { pipeline.addLast(new ServerBootstrapAcceptor( childGroup, childHandler, childOptions, childAttrs)); } }); } });这里有一个容易让人困惑的设计为什么注册连接接入器要再包一层eventLoop.execute原因是ServerBootstrapAcceptor必须在EventLoop线程里加到pipeline才能保证pipeline不被并发修改。channel注册完成后这个initChannel才会回调。整个过程串下来顺序是反射创建NioServerSocketChannel内部创建pipeline将Channel注册到bossGroup的selector上注册后才执行initChannelinitChannel把ServerBootstrapAcceptor加到pipeline末尾绑定端口开始接受连接这个顺序非常重要。如果你在自定义Handler里想依赖bootStrap里的handler要清楚它是在注册完成后才进pipeline的。4. 连接接入源码ServerBootstrapAcceptor如何接收新连接bossGroup上的selector监听到OP_ACCEPT事件后会调用NioServerSocketChannel的unsafe.read()最终在NioMessageUnsafe.read()里循环读取新连接。真正处理接入逻辑的是pipeline里的ServerBootstrapAcceptor它的channelRead方法public void channelRead(ChannelHandlerContext ctx, Object msg) { final Channel child (Channel) msg; child.pipeline().addLast(childHandler); childGroup.register(child).addListener(...); }这里的msg是NioServerSocketChannel在读取接入事件时创建的NioSocketChannel实例。每个新连接都是一个独立的NioSocketChannel有自己独立的pipeline。ServerBootstrapAcceptor把业务侧的childHandler加进这个新连接的pipeline然后调用childGroup.register(child)把新连接注册到worker线程组。重点看这行注册MultithreadEventLoopGroup.register会从线程组里挑一个EventLoop然后执行channel.register(eventLoop)。所谓注册不是简单记录关系而是把Channel的OP_READ事件注册到该EventLoop的Selector上之后这个连接上的所有读写都由此EventLoop负责。这里解释了为什么worker线程数默认是CPU核数两倍也够用因为对一条连接来说其所有事件都只在同一个EventLoop线程上处理。IO线程和业务线程在单个Channel上不并发天然无锁。EventLoop处理连接是批量轮询一个线程管理几百上千个连接是常态。接入阶段有两个代码级别的小坑。一个是在pipeline里加了childHandler后再注册这样第一个OP_READ事件触发时处理器链已经完整不会丢最早的数据。另一个是FIXED_RATE心跳之类的定时任务不挂在bossGroup要挂在对应连接的EventLoop上否则新连接没有注册前定时任务可能找不到可执行的EventLoop。5. EventLoop和SelectorNetty的线程之魂刚才一直提到EventLoop这是Netty最核心的线程模型对象。每个EventLoop本质上是一个无限循环线程循环里做了三件事处理IO事件、执行普通任务队列、执行定时任务。代码入口在NioEventLoop.run()protected void run() { for (;;) { try { switch (strategy) { case SELECT: select(wakenUp.getAndSet(false)); ... default: } processSelectedKeys(); runAllTasks(); } } }strategy是从selectStrategy.calculateStrategy里算出来的核心逻辑是如果当前没有任务需要立刻执行就执行阻塞式select如果有任务就把select的超时时间设得很短甚至不阻塞防止任务被IO事件饿死。这就是Netty所谓的“IO任务和普通任务共享线程且不互等”。select过程里有个有意思的优化selectNowCnt超过阈值时会调用rebuildSelector。原因是JDK底层的Selector在某些平台下会有空轮询bugCPU会被打满。Netty检测到连续多次select返回0但也没有事件时会重建一个Selector把所有已注册的Channel重新注册进去。这段代码在NioEventLoop.select()方法里注解写得非常直白“prevent the epoll from spinning”。processSelectedKeys处理的是SelectedSelectionKeySet里面是当前就绪的SelectionKey集合。Netty没有像普通NIO写法那样在for循环里调用key.channel()然后自己判断类型而是按attachment分发。每个SelectionKey上都绑定了对应的AbstractNioChannel拿到key后直接调用unsafe.read()或unsafe.write()。事件分发到这里才真正进入Channel层面。runAllTasks处理的是非IO任务包括用户通过channel.eventLoop().execute提交的任务、bind注册任务、定时任务。这个队列的消费有一个时间预算默认最多跑100毫秒防止业务任务把IO线程占死。这就是为什么在Netty的EventLoop上跑耗时任务是非常危险的操作会把同一EventLoop上的所有连接都拖住。我自己踩过一次坑业务回调里做了个慢SQL查询300毫秒结果那段时间该EventLoop下所有连接的读写都出现明显抖动。后来把耗时操作挪到独立业务线程池EventLoop上只做数据转发问题就消失了。这就是EventLoop源码带给我的直接教训。6. ChannelPipeline责任链从哪来到哪去pipeline是Netty所有处理器编排的容器。每个Channel创建时都会new DefaultChannelPipeline里面有两个哨兵节点HeadContext和TailContext。HeadContext既是入站起点也是出站终点TailContext刚好相反。为什么要有两个哨兵因为责任链必须有一个确定的收口位置。数据从网络进来后NioByteUnsafe.read()会调用pipeline.fireChannelRead(buffer)从Head开始向后传播。如果你在Handler里调用了ctx.write(msg)这个出站消息从当前Handler开始往回走最终由HeadContext完成底层socket的写出。DefaultChannelPipeline的addLast实现有几个值得留意的细节。首先每个Handler会被包装成AbstractChannelHandlerContext这个context里记录了prev和next指针构成双向链表。然后addLast需要判断是否在EventLoop线程中如果不在会用PendingHandlerCallback队列缓存稍后由EventLoop线程真正执行插入。这样做的原因很简单pipeline的链表结构不允许并发修改。还有一个很容易看懵的地方fireChannelRead传的是Object不是ByteBuf。这意味着你在解码器里可以把ByteBuf转换成业务POJO再继续向下游传播。责任链上的每个handler都可以选择修改消息对象也可以选择终止传播比如未完成粘包时不调用fireChannelRead。Handler加入顺序决定了处理顺序。经典配置是先加decoder再加业务handler。如果你把业务handler放在decoder前面拿到的就是原始字节流而不是POJO类型转换直接炸。这事不读源码也能理解但读了源码你还会额外知道pipeline的传播顺序和Handler注解Sharable还有一个配合关系。带Sharable的Handler可以被多个pipeline共享但如果内部有非线程安全状态照样出问题。源码里其实还藏着一个容易忽略的入口channelRegistered、channelActive这些生命周期事件也是通过pipeline传播的。连接激活后每个Handler的channelActive方法依次执行。如果你在channelActive里做数据下发此时pipeline已经完整还没有任何数据读取过这个时机就很干净。7. 粘包半包源码解析ByteToMessageDecoder的累积逻辑粘包半包是所有TCP长连接应用绕不开的问题。TCP是流协议应用层写入的消息在传输层没有边界。Netty解决这个问题的核心类就是ByteToMessageDecoder。它的channelRead方法代码如下简化后public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception { if (msg instanceof ByteBuf) { CodecOutputList out CodecOutputList.newInstance(); try { ByteBuf data (ByteBuf) msg; cumulation cumulator.cumulate(ctx.alloc(), cumulation, data); callDecode(ctx, cumulation, out); } finally { if (cumulation ! null !cumulation.isReadable()) { cumulation.release(); cumulation null; } ... } } }要点在于cumulation。同一连接上每次读到的字节流会先累积到这个字段里。如果上次数据不够解析出一个完整业务包剩下来的部分会保留在cumulation里等待下一次读取再拼接。这个累积器就是解决半包的根因手段。callDecode方法里有一个死循环while (out.size() 0) { int oldInputLength cumulation.readableBytes(); decodeRemovalReentryProtection(ctx, cumulation, out); if (oldInputLength cumulation.readableBytes()) { break; } }每次decode后如果out里没有产出同时累积的字节数也没减少那就说明当前数据不够解码直接break等待下个包。如果decode出了业务对象但读完了所有可读字节也会退出循环不再空转。这套设计非常稳健解码器不会因为数据不够而丢数据也不会在没有数据时死循环。自定义解码器时你一般继承ByteToMessageDecoder重写decode方法。如果解析到一个完整的协议包就调用out.add(对象)。如果字节不够什么都不做。Netty推断“还需要更多数据”靠的就是in可读字节数未被消耗配合上面那个循环判定。我实际写TCP自定义协议时header定长最省事比如前4字节是包长度字段读够长度再解析业务体。解码器里判断可读字节不足4就先return够4就读长度再判断body长度是否满足。这样每一轮都能精确推进。粘包场景下decode一次可能解析出多个业务对象out.add会加入多个。这些对象会随后依次沿着pipeline向下传播业务handler的channelRead会被调用多次。你不需要在处理时手动拆包了。另外要注意ByteToMessageDecoder并不是所有协议都适合。如果你的协议需要依赖“连接断开”来判定消息结束比如某些流式协议没有长度前缀那就不能单纯靠累积器得在解码器里维护更多状态。Netty还有DelimiterBasedFrameDecoder和FixedLengthFrameDecoder源码逻辑都是基于同一个累积机制原理理解了看它们就一目了然。8. ByteBuf源码为什么它比ByteBuffer好用Netty发送和接收的数据载体是ByteBuf。它和JDK ByteBuffer最核心的差异是读写指针分离。JDK的Buffer用position和limit管理数据读写状态切换时需要flip非常容易搞错。ByteBuf用readerIndex和writerIndex分别记录读写位置读完一个字节readerIndex往后移动写完一个字节writerIndex往后移动clear只是重置索引不真正清空内容。看源码里ByteBuf继承体系最常用的是PooledUnsafeDirectBuffer和PooledHeapByteBuffer。Pooled前缀表示从内存池里分配。Netty默认使用池化分配器PooledByteBufAllocator大对象走PageCache小对象按规格从池里复用。这块逻辑在PoolArena、PoolChunk里第一遍读不追求完全吃透你只需要知道频繁创建ByteBuf再丢弃GC压力是很大的Netty用内存池大幅降低这个压力。ByteBuf的引用计数也是源码里必须看的部分。每个ByteBuf都继承ReferenceCounted初始refCnt为1。每被一个使用者引用一次需要调用retain让计数加一。release让计数减一减到0时内存归还池子。如果在pipeline里某段代码忘了release内存泄漏如果多release了可能把别人还在用的buffer放回池子导致数据被覆盖。翻源码时我自己理清了一条经验的来源AbstractChannelHandlerContext.write方法内部做了一个非常重要的动作它产出的ByteBuf会在HeadContext的write方法里被最终flush后回调一个Promise由Netty统一release。但如果你是手动向EventLoop提交一个写任务或者你在 handler 里把读到的ByteBuf转发给另一个Channel那么什么时候release就要自己操心没有Netty兜底。还有一个实用接口ByteBufAllocator。建议在Handler里定义private ByteBufAllocator alloc ctx.alloc()创建响应时用alloc.buffer不要自己new。这样可以保证Buffer是从当前EventLoop关联的池里分配性能更好。自定义编解码返回的ByteBuf也要通过alloc创建直接new UnpooledHeapByteBuf不会导致功能错误但会绕过内存池在高并发下明显增加GC。9. 动手实测从零搭一个可观察的Netty服务端纸上谈兵不如跑起来断点观察。这里我给出一套我实际验证过的做法能让你把前面几个源码概念串起来。我先写一个极简的Netty服务端功能是接收数据并原样返回同时在关键位置打印线程名。代码public class SourceServer { static final int PORT 8080; public static void main(String[] args) throws Exception { EventLoopGroup boss new NioEventLoopGroup(1); EventLoopGroup worker new NioEventLoopGroup(4); ServerBootstrap b new ServerBootstrap(); b.group(boss, worker) .channel(NioServerSocketChannel.class) .childHandler(new ChannelInitializerSocketChannel() { Override protected void initChannel(SocketChannel ch) { ch.pipeline().addLast(new LoggingHandler(LogLevel.INFO)); ch.pipeline().addLast(new SimpleChannelInboundHandlerByteBuf() { Override protected void channelRead0(ChannelHandlerContext ctx, ByteBuf msg) { System.out.println([ Thread.currentThread().getName() ] recv: msg.toString(CharsetUtil.UTF_8)); ctx.writeAndFlush(Unpooled.copiedBuffer(pong, CharsetUtil.UTF_8)); } }); } }); ChannelFuture f b.bind(PORT).sync(); f.channel().closeFuture().sync(); } }日志用Netty自带的LoggingHandler看事件顺序。启动后用nc或写一个简单的socket客户端发送数据。你会发现server accept事件逻辑在boss线程的NioEventLoop里数据读取和业务handler打印都在worker线程里而且同一个连接上的所有消息都由同一个worker线程处理。这个现象就是源码里EventLoop与Channel一对一绑定关系的外部可见表现。为了观察pipeline传播可以在自定义handler里故意多挂几个Hander每个handler打印自己的名字然后发送数据观察打印顺序第一个handler先看到原始ByteBuf后面handler拿到的可能是别的对象。把SimpleChannelInboundHandler替换成普通ChannelInboundHandlerAdapter并手动做一次丢包模拟读了一点字节不推进readerIndex不调用fireChannelRead你会发现后面的handler再也不会收到消息这正好对应了责任链可以中间断掉的机制。我最推荐的观察方式还有在NioEventLoop.run()的processSelectedKeys处打断点当网络事件进来时IDEA的debugger可以看到底层的SelectedSelectionKeySet、NioSocketChannel的unsafe对象以及当前调用栈。这个调用栈会把从Selector唤醒到处理器消费的整条路径展现在眼前比只看源码高效得多。10. 看Netty源码的几个高频误区围绕源码阅读我总结过几个高频率翻车点提出来帮你少走弯路。第一个误区是直接在IDE里把Netty当成jar包反编译。反编译代码缺注释、缺泛型信息读起来极其痛苦。正确做法是从GitHub clone netty源码工程构建好之后直接关联源码。maven中央仓库发布的源码jar也够用关键是有完整的注释和常量定义。第二个误区是上来就读NioEventLoop的selector轮询细节。这一块虽然核心但对初学者来说没有上下文时看select相关的几十个重载和优化分支很容易被绕晕。我建议先看AbstractBootstrap和ChannelInitializer把“你写的代码驱动源码跑到哪里”这件事搞清楚再深入EventLoop。第三个误区是忽略版本差异。网上不少老文章讲的是3.x或4.0早期代码和4.1差别不小。比如3.x的pipeline已经是符号链了,但handler回调方式、线程模型细节完全不同。所以读源码之前确认自己依赖的netty版本依照该版本去查资料否则会得到误导性结论。第四个误区是只看方法名、不看调用方。源码里的方法名很多有迷惑性。比如channelReadComplete这个名字容易让人以为和字节数据有关但实际它是读事件处理完成的回调常用来写回剩余buffer或提交flush。判断一个方法的真实职责正确动作是找到它在哪里被调用以及谁在调用它。第五个要提防的是线程切换的界面。看过源码你会发现Netty里大量的操作用eventLoop.execute包了一层。不是这些操作本身慢而是要保证“同一Channel的所有操作都在同一线程串行执行”。阅读时看到execute就应该停下来想一下代码是运行在哪个线程如果换线程了对数据有什么影响这是理解Netty并发模型的关键。11. 下一步从哪继续深挖这个系列第一篇的主要目标是建立Netty源码的主干认知。看懂了ServerBootstrap、NioEventLoop、ChannelPipeline、ByteToMessageDecoder这几个核心链路之后Netty对你就不再有黑盒感了。我建议的下一步按以下顺序走深入学习NioEventLoop的任务队列与定时任务实现HashedWheelTimer或优先级队列搞清楚“定时任务与IO事件共享线程”的具体调度策略深入ByteBuf的内存分配与池化机制重点看PoolArena维护的cache和arena结构深入写路径从ctx.write到最终socket写出之间发生了什么注意writeAndFlush和write加flush的差异自己尝试写一个自定义协议解码器然后对比Netty内置的LengthFieldBasedFrameDecoder找出边界情况下会不会有漏洞我个人的切身体会是Netty的源码质量非常高注释里有大量“为什么不这样设计”的讨论这些讨论是网上很多教程不会讲的但恰恰是最提高功力的部分。你读源码不光是为了应付面试更多的是为了建立对事件驱动、内存管理和并发模型的系统认知。回到开头那个问题——为什么Netty的线程模型能支撑百万连接现在你应该有了答案。百万连接不是靠百万线程而是靠极少数EventLoop线程不断轮询事件、批量处理任务、精心管理内存。源码里每一步设计都在围绕这个核心运转。下一篇我会继续拆NioEventLoop的实现细节包括Selector优化、任务队列的时间预算、以及定时任务如何运作。如果你在我说的那几条链路上有自己的疑问和发现欢迎带着具体场景来对比。Netty源码不是背出来的是一行一行“跑”出来的。