netty中channelHandler实现原理及最佳实践

为持续夯实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<SocketChannel>() {    @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<Object> out) throws Exception;}

我们查看 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<Object> out) {    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<Object> out)    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<Object> out) throws Exception {        Object decoded = decode(ctx, in);        if (decoded != null) {            out.add(decoded);        }    }        protected Object decode(            @SuppressWarnings("UnusedParameters") ChannelHandlerContext ctx, ByteBuf in) throws Exception {        if (in.readableBytes() < frameLength) {            return null;        } else {            return in.readRetainedSlice(frameLength);        }    }}

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 EchoServerHandlerextends 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;    // ....  }