为持续夯实MobTech袤博科技的数智技术创新能力和技术布道能力，本期极客星球邀请了企业服务研发部工程师梁立从 TCP 的粘包/半包、 Netty 处理粘包/半包及源码分析、 开源项目对 channelHandler最佳实践三方面对《netty 中channelHandler的原理与最佳实践》进行了全面的技术分享。
版本信息
本次分析版本基于netty 4.1.40.Final
TCP 的粘包/半包问题
在TCP/IP 协议传输网络数据包时，用户发送消息ABCD，服务端可能收到是ABCD. AB？CD？等。对于粘包问题，主要原因是发送方每次写入数据小于套接字缓冲区大小， 以及接受方读取消息不及时。对于半包问题， 主要原因是发送方每次写入数据大于套接字缓冲区大小，以及发送数据大于协议最大传输单位，底层需要拆包。那么针对此类问题，应当如何解决呢 ？常见的方式解码方式有三种：固定长度，使用固定分隔符来分割消息，以及固网长度字段存放内容长度信息。
解码实现思考
在分析之前，我们可以思考一下，如果是我们来实现上面三种编解码会如何实现 ？
我们可以整理如下需求：
1.我们需要存放我们解码好的消息；
2.我们需要提供一个解码方法来让不同子类实现， 例如固定长度，分隔符，以及固定长度字段解码的方式肯定有差别；
3.我们从套接字读取消息后就可以让我们解码器去处理了。
针对上述需求，我们还需要带着三个问题，查看源码看下是否和我们猜想的类似：
问题1：我们需要一个集合存放我们解码的消息；
问题2：我们需要不同子类对解码细节做不同实现，所以我们需要有一个父类；ByteToMessageDecoder， 可以在父类实现公共逻辑，提供给子类一个decode(List out,ByteBuf in); 方法；
问题3 ：我们从套接字读取数据之后，发送一个读事件(fireChannelRead)让我们解码器去处理。
Netty 处理粘包/半包及源码分析
封帧方式
解码
固定长度
FixedLengthFrameDecoder
分隔符
DelimiterBasedFrameDecoder
固定长度字段存内容长度信息
LengthFieldBasedFrameDecoder
我们以固定长度解码器为例：
ServerBootstrap b = new ServerBootstrap();
// ....
b..childHandler(new ChannelInitializer
@Override
public void initChannel(SocketChannel ch) throws Exception {
ChannelPipeline p = ch.pipeline();
p.addLast(new FixedLengthFrameDecoder(2));
//.... 后续业务处理handler
}});
public class FixedLengthFrameDecoder extends ByteToMessageDecoder {
//....}
public class ByteToMessageDecoder {
// ....
protected abstract void decode(ChannelHandlerContext ctx, ByteBuf in, List}
我们查看 FixedLengthFrameDecoder ，发现果然继承父类ByteToMessageDecoder，然后父类也有一个channelRead方法处理消息，并提供一个decode抽象方法让子类实现。
channelRead
假设我们发送端发送ABCD消息，从套节字读取之后，后续会调用channelRead 方法进行解码。
我们看到获取一个集合实例CodecOutputList， 该类实现List接口。如果是首次调用，会把当前ByteBuf 赋值给cumulation，并调用callDecode(ctx, cumulation, out)。
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
if (msg instanceof ByteBuf) {
CodecOutputList out = CodecOutputList.newInstance();
try {
ByteBuf data = (ByteBuf) msg;
first = cumulation == null;
if (first) {
cumulation = data;
} else {
cumulation = cumulator.cumulate(ctx.alloc(), cumulation, data);
}
callDecode(ctx, cumulation, out);
} catch (DecoderException e) {
throw e;
} catch (Exception e) {
throw new DecoderException(e);
} finally {
//.....
}
} else {
ctx.fireChannelRead(msg);
}
}callDecode
通过字面意思就知道这个方法会做和解码相关操作。首先会判断in.isReadable() 是否可读，然后我们的outSize 目前是空， 进入到 decodeRemovalReentryProtection , 该方法会调用子类FixedLengthFrameDecoder的decode方法进行具体解码，该decode 方法比较简单就是当从ByteBuf 读取到指定长度就添加到out 中。我们读取完成后， outSize == out.size() 和 oldInputLength == in.readableBytes()都不满足，进入下一次循环， 我们outSize 大于0， 发送fireChannelRead。到此消息就被解码，并发送给我们业务channelHandler 。
protected void callDecode(ChannelHandlerContext ctx, ByteBuf in, List
try {
while (in.isReadable()) {
int outSize = out.size();
if (outSize > 0) {
fireChannelRead(ctx, out, outSize);
out.clear();
// Check if this handler was removed before continuing with decoding.
// If it was removed, it is not safe to continue to operate on the buffer.
//
// See:
// - https://github.com/netty/netty/issues/4635
if (ctx.isRemoved()) {
break;
}
outSize = 0;
}
int oldInputLength = in.readableBytes();
//decode中时，不能执行完handler remove清理操作。
//那decode完之后需要清理数据。
decodeRemovalReentryProtection(ctx, in, out);
// Check if this handler was removed before continuing the loop.
// If it was removed, it is not safe to continue to operate on the buffer.
//
// See https://github.com/netty/netty/issues/1664
if (ctx.isRemoved()) {
break;
}
if (outSize == out.size()) {
if (oldInputLength == in.readableBytes()) {
break;
} else {
continue;
}
}
if (oldInputLength == in.readableBytes()) {
throw new DecoderException(
StringUtil.simpleClassName(getClass()) +
".decode() did not read anything but decoded a message.");
}
if (isSingleDecode()) {
break;
}
}
} catch (DecoderException e) {
throw e;
} catch (Exception cause) {
throw new DecoderException(cause);
}}
final void decodeRemovalReentryProtection(ChannelHandlerContext ctx, ByteBuf in, List
throws Exception {
decodeState = STATE_CALLING_CHILD_DECODE;
try {
decode(ctx, in, out);
} finally {
boolean removePending = decodeState == STATE_HANDLER_REMOVED_PENDING;
decodeState = STATE_INIT;
if (removePending) {
handlerRemoved(ctx);
}
}}
public class FixedLengthFrameDecoder extends ByteToMessageDecoder {
@Override
protected final void decode(ChannelHandlerContext ctx, ByteBuf in, List}
channelHandler 的最佳实践
了解Netty 的小伙伴都知道channelHandler 分为ChannelInboundHandler 和 ChannelOutboundHandler， 分别用来处理inbound 和 outbound。
channelHandler 的最佳实践本质就是inbound 和outbound 的最佳实践。
下面列举了三种具有代表性的场景
• 按照职责划分channelHandler，例如有处理编解码，有处理心跳的，有专门处理业务的；
• 因为channel和eventLoop 线程绑定，然后一个evnetLoop 可能服务多个channel，所以我们不要在channelHandler 做耗时操作；
• outbound 我们可以优化写，减少系统调用。
按照职责划分channelHandler
rocketMq
我们可以查看rocketMq 是如何划分channelHandler ， 比如具有专门处理编/解码的NettyEncoder/NettyDecoder，通过IdleStatHandler 发现不活跃连接，管理连接handlerNettyConnectManageHandler 进行处理，
业务处理 NettyServerHandler 。
dubbo
处理编解码，检查不活跃channel，以及业务处理handler。
不在channelHandler 做耗时操作
之前介绍过一个eventLoop 线程服务多个channel，假设某个channelHandler处理耗时的任务，会影响其他channel，所以我们不要在channelHandler 执行耗时操作。
如果确实需要执行耗时操作，我们可以给channelHandler 添加一个线程池处理
final DefaultEventLoopGroup defaultEventLoopGroup = new DefaultEventLoopGroup();
// 为我们的serverHandler 添加单独的线程池处理事件。
pipeline.addLast(defaultEventLoopGroup,serverHandler)；
outbound 优化写
writeAndFlush存在的问题
我们来看一下下面代码有什么问题？
public class EchoServerHandler
extends ChannelInboundHandlerAdapter {
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) {
ctx.writeAndFlush(msg);
}}
代码的问题在于ctx.writeAndFlush 每次调用都会触发一次系统调用。然后channelRead 在一次业务处理中可能被调用多次，问题就变为一次业务请求，执行多次系统调用。
优化writeAndFlush
怎么优化？
我们可以重写channelRead 和 channelReadComplete，在channelRead 中调用write 方法，
在channelReadComplete中调用flush 方法 。
public class EchoServerHandler extends ChannelInboundHandlerAdapter {
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) {
ctx.write(msg);
}
@Override
public void channelReadComplete(ChannelHandlerContext ctx) {
ctx.flush();
}}
上面的实现方式确实减少系统调用，但是在netty 内部当有数据可读，会默认会连续16次，最后在调用channelReadComplete() 方法。
默认的行为存在两个问题：
1.写出数据到对端的时间被延迟了；
2.默认16 次这个数据不一定适合所有业务场景（不够灵活）。
我们需要结合业务的特性，例如业务如果关注吞吐量，可以适当把读取几次后刷新设置的大一些。如果业务关注及时性，读取几次后刷新就适当设置小一点。基于上述需求，FlushConsolidationHandler 就诞生了， 可以指定读取几次后刷新一次。
FlushConsolidationHandler 优化写
使用在pipeline中添加FlushConsolidationHandler，读取几次刷新一次可以根据业务设置，例如这里设置5次，我们是优化 EchoServerHandler的写，就放在它的前面。
// 每5次就触发一次flush
// ....
p.addLast(new FlushConsolidationHandler(5));
p.addLast(new EchoServerHandler());
// ....
public class EchoServerHandler extends ChannelInboundHandlerAdapter {
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) {
ctx.writeAndFlush(msg);
}}
原理分析：
首先FlushConsolidationHandler 继承 ChannelDuplexHandler，能同时处理入站和出站消息，
入站我们查看 channelRead 和 channelReadComplete 实现，出站我们查看 flush 方法 （没有对write方法进行重写）。
channelRead
• 设置readInProgress 就把事件向下传递
• 我们的EchoServerHandler 会channelRead 会被调用,我们在channelRead 中调用ctx.writeAndFlush。
• 触发write 和 flush 的出站消息， FlushConsolidationHandler的flush进行处理
• 先判断readInProgress， ++flushPendingCount == explicitFlushAfterFlushes 判断是否达到期望刷新次数，我们设置为5 ，不执行刷新。
• 接着channelReadComplete 被调用，会重置准备刷新次数，并执行刷新。
关键就在channelRead 和 channelReadComplete
假设我们channelRead 读取了多次， 当读取次数大于等于5次就会刷新，小于5次时由channelReadComplete 刷新。
这样就达到了减少系统调用并且每读取几次在刷新也可以配置
public class FlushConsolidationHandler extends ChannelDuplexHandler {
// explicitFlushAfterFlushes 表示几次flush后，才真正调用flush 方法
// consolidateWhenNoReadInProgress 支持异步的情况，当readInProgress不为true 也可以支持flush
public FlushConsolidationHandler(int explicitFlushAfterFlushes, boolean consolidateWhenNoReadInProgress){
//....
}
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
readInProgress = true;
ctx.fireChannelRead(msg);
}
@Override
public void channelReadComplete(ChannelHandlerContext ctx) throws Exception {
// This may be the last event in the read loop, so flush now!
// 内部就是将 readInProgress = false; 当flushPendingCount 就调用flush
resetReadAndFlushIfNeeded(ctx);
ctx.fireChannelReadComplete();
}
@Override
public void flush(ChannelHandlerContext ctx) throws Exception {
//根据业务线程是否复用IO线程两种情况来考虑：
//复用情况
if (readInProgress) { //正在读的时候
// If there is still a read in progress we are sure we will see a channelReadComplete(...) call. Thus
// we only need to flush if we reach the explicitFlushAfterFlushes limit.
//每explicitFlushAfterFlushes个“批量”写（flush）一次
//不足怎么办？channelReadComplete会flush掉后面的
if (++flushPendingCount == explicitFlushAfterFlushes) {
flushNow(ctx);
}
//以下是非复用情况：异步情况
} else if (consolidateWhenNoReadInProgress) {
//（业务异步化情况下）开启consolidateWhenNoReadInProgress时，优化flush
//（比如没有读请求了，但是内部还是忙的团团转，没有消化的时候，所以还是会写响应）
// Flush immediately if we reach the threshold, otherwise schedule
if (++flushPendingCount == explicitFlushAfterFlushes) {
flushNow(ctx);
} else {
scheduleFlush(ctx);
}
} else {
//（业务异步化情况下）没有开启consolidateWhenNoReadInProgress时，直接flush
// Always flush directly
flushNow(ctx);
}
}}
附录
默认读取16次设置入口源码分析
默认创建DefaultChannelConfig ，会接着调用重载的构造函数。
在setRecvByteBufAllocator可以看到获取metadata.defaultMaxMessagesPerRead()。
而ChannelMetadata 默认构造为 16次 new ChannelMetadata(false, 16)。
public abstract class AbstractNioByteChannel extends AbstractNioChannel {
private static final ChannelMetadata METADATA = new ChannelMetadata(false, 16);
//.....}
// 默认选择自适应接受缓存分配器,然后在调用setRecvByteBufAllocator。
// setRecvByteBufAllocator就是指定最大读取多少次的入口 ，默认为16次
public class DefaultChannelConfig implements ChannelConfig {
public DefaultChannelConfig(Channel channel) {
//除UDP外都默认选择自适应接受缓存分配器
this(channel, new AdaptiveRecvByteBufAllocator());
}
protected DefaultChannelConfig(Channel channel, RecvByteBufAllocator allocator) {
//UDP的使用固定SIZE的接受缓存分配器：FixedRecvByteBufAllocator
setRecvByteBufAllocator(allocator, channel.metadata());
this.channel = channel;
}}
private void setRecvByteBufAllocator(RecvByteBufAllocator allocator, ChannelMetadata metadata) {
if (allocator instanceof MaxMessagesRecvByteBufAllocator) {
((MaxMessagesRecvByteBufAllocator) allocator).maxMessagesPerRead(metadata.defaultMaxMessagesPerRead());
} else if (allocator == null) {
throw new NullPointerException("allocator");
}
setRecvByteBufAllocator(allocator);}
public final class ChannelMetadata {
private final boolean hasDisconnect;
private final int defaultMaxMessagesPerRead;
// ....
}