设计模式与Netty框架：ChannelPipeline中的责任链、EventLoop中的命令、ByteBuf中的享元
Netty这个框架，我用了快十年了。说实话，每次看它的源码，都能学到新东西。今天咱们就聊聊Netty里藏着的三个经典设计模式——责任链、命令、享元。这三个模式在Netty里不是生搬硬套，而是融进了骨子里。
一、ChannelPipeline：责任链模式的教科书级实现
先说说ChannelPipeline。你想想看，一个网络请求进来，要经过编码、解码、业务处理、异常处理……这一串操作怎么组织？最直观的想法就是搞个链表，每个节点干自己的活，干完了传给下一个。
Netty就是这么干的。ChannelPipeline本质上就是一个双向链表，每个节点是ChannelHandler。我当年第一次看这个设计时，心里就一个想法：这不就是责任链模式吗？
核心要点：责任链模式让多个对象都有机会处理同一个请求。Netty的ChannelPipeline把这种模式发挥到了极致——每个Handler只关心自己该做的事，处理完就往后传，或者干脆不传（比如异常处理器）。
来看个简单的例子：
// 服务端初始化时，往Pipeline里加Handler
bootstrap.childHandler(new ChannelInitializer<SocketChannel>() {
@Override
protected void initChannel(SocketChannel ch) {
ChannelPipeline p = ch.pipeline();
p.addLast(new LoggingHandler(LogLevel.INFO));
p.addLast(new StringDecoder());
p.addLast(new StringEncoder());
p.addLast(new BusinessHandler());
}
});这段代码看着简单，但背后有讲究。每个Handler的添加顺序决定了处理链路。我踩过一个坑：有一次把编码器加在了业务处理器后面，结果业务处理完的数据根本出不去。嗯，这个顺序问题，大家一定要留意。
我的习惯：写Netty应用时，我会把日志Handler放在最前面，这样能清楚看到原始数据。调试阶段特别有用。
二、EventLoop：命令模式让异步变得优雅
Netty的EventLoop，说白了就是一个永不停止的线程，不断从任务队列里取任务执行。这个设计模式是什么？命令模式。
命令模式的核心思想：把请求封装成对象。Netty里，每个I/O操作、每个定时任务，都被封装成一个Runnable或ChannelFuture，丢进EventLoop的任务队列。EventLoop不关心任务是谁发的，只管执行。
我画了一张图，帮你理解这个流程：
你看这个图，任务队列里攒了一堆任务，EventLoop一个个取出来执行。每个任务就是一个命令对象。这种设计的好处是什么？解耦。任务的提交者和执行者互不依赖。
// 提交一个任务到EventLoop
channel.eventLoop().execute(() -> {
System.out.println("这个任务会在I/O线程执行");
// 这里可以安全地操作Channel
});我曾经踩过的坑：在业务线程里直接调用Channel.writeAndFlush()，没有通过EventLoop提交。结果出现了并发问题，数据乱序了。后来我养成了习惯：所有Channel操作都通过EventLoop提交，哪怕只是简单的写数据。
三、ByteBuf：享元模式的内存管理艺术
ByteBuf是Netty里最让我佩服的设计之一。它用享元模式解决了网络编程中最头疼的问题——内存分配和回收。
享元模式的核心思想：共享对象，避免重复创建。ByteBuf里有个东西叫PooledByteBufAllocator，它维护了一个内存池。需要ByteBuf时，从池子里拿；用完了，还回去。而不是每次都new一个。
我举个例子你就明白了：
// 使用池化的ByteBuf
ByteBufAllocator alloc = PooledByteBufAllocator.DEFAULT;
ByteBuf buf = alloc.buffer(256);
// 用buf读写数据...
buf.release(); // 归还到池中，不是真的销毁这段代码看着简单，但背后大有文章。PooledByteBufAllocator内部维护了多个内存块，每个块又分成更小的子块。分配时，根据请求大小找到合适的子块。这就是享元模式——内存块被反复重用。
| 分配器类型 | 内存管理方式 | 适用场景 |
|---|---|---|
| PooledByteBufAllocator | 内存池，享元模式 | 高并发、频繁分配释放 |
| UnpooledByteBufAllocator | 每次分配新内存 | 低并发、少量数据 |
我的建议：生产环境一定要用PooledByteBufAllocator。我见过一个项目，默认用了Unpooled，压测时GC频繁到每秒几十次。换成池化后，GC次数降到了个位数。
ByteBuf的享元模式还体现在一个细节上：CompositeByteBuf。它可以把多个ByteBuf组合成一个逻辑上的ByteBuf，而不需要拷贝数据。这其实就是享元模式的一种变体——共享底层的数据块。
// CompositeByteBuf：零拷贝组合
CompositeByteBuf composite = Unpooled.compositeBuffer();
ByteBuf header = alloc.buffer(10);
ByteBuf body = alloc.buffer(100);
composite.addComponents(true, header, body);
// 现在composite看起来就像一个完整的ByteBuf四、三个模式的协同工作
这三个模式在Netty里不是孤立的。它们配合得天衣无缝：
- EventLoop 从任务队列取出命令（命令模式），执行过程中会触发 ChannelPipeline 里的Handler（责任链模式）
- Handler处理数据时，使用 ByteBuf 读写（享元模式），用完归还到池中
- 整个流程是异步的，EventLoop不断循环，Pipeline不断流转，ByteBuf不断复用
我当年调试一个高并发网关时，就是顺着这个思路定位性能瓶颈的。先看EventLoop的任务积压情况，再看Pipeline里哪个Handler耗时最长，最后检查ByteBuf有没有正确释放。这三个模式，就是Netty性能的三根支柱。
总结一下：ChannelPipeline是责任链，让处理逻辑灵活可配；EventLoop是命令模式，让异步执行干净利落；ByteBuf是享元模式，让内存管理高效省心。这三个模式，你吃透了，Netty就算入门了。
嗯，今天就聊到这儿。这些模式看着简单，但真正用好，还得在项目里多磨。下次咱们聊聊Netty里其他有意思的设计。
公众号:蓝海资料掘金营，微信deep3321