netty DefaultEventLoopGroup踩坑

踩坑过程

大家都知道使用netty时应该尽量不要阻塞i/o线程，而应该把耗时的业务逻辑放在其他线程中等计算出结果后再通过i/o线程提交给请求者，netty 为了隔离这些处理耗时业务的ChannelHandler，在向pipline中添加ChannelHandler时提供了可以同时指定ChannelHandler执行业务线程的api

  /**
   * Inserts {@link ChannelHandler}s at the first position of this pipeline.
   *
   * @param group     the {@link EventExecutorGroup} which will be used to execute the {@link ChannelHandler}s
   *                  methods.
   * @param handlers  the handlers to insert first
   *
   */
  ChannelPipeline addFirst(EventExecutorGroup group, ChannelHandler... handlers);

于是我开心的在应用b的netty引导程序中创建了一个100大小的业务DefaultEventLoop，并指定我处理耗时业务逻辑的ChannelHandler在这个线程池中运行

businessGroup = new DefaultEventLoopGroup(100);
...
addLast(businessGroup, new SlaveXhakaHttpServletHandler())

而应用a与应用b之间通过一条channel通信，开发完成部署测试，结果发现当我逐渐提升SlaveXhakaHttpServletHandler中的逻辑耗时，应用并发性能也成正比的断崖式下降，看上去就和i/o线程被阻塞了没有什么区别。
怀着被欺骗的心情，我在SlaveXhakaHttpServletHandler中打印出了当前线程信息，再次压测，发现所有的执行线程都是defaultEventLoopGroup-4-1，netty doc并没有欺骗我们，并没有执行在i/o线程中，但是如果业务线程只有一个和直接在i/o线程中执行耗时逻辑也没什么区别，而我们明明设置了100个线程，熟悉netty的大佬此时心在应该已经有答案了，还不清楚的，我们通过读源码慢慢找答案。

---

源码解谜

首先我们需要了解netty的一些与这个问题相关的基本架构，首先netty中一条Channel与一条ChannelPipline绑定，ChannelPipline由ChannelHandlerContext节点组成，而向Pipline中添加ChannelHandler的过程，其实就是在Pipline中组织，添加ChannelHanlderContext的过程，我们首先看下netty中的ChannelHandlerContext接口：

public interface ChannelHandlerContext extends AttributeMap, ChannelInboundInvoker, ChannelOutboundInvoker {
   

    /**
     * Return the {@link Channel} which is bound to the {@link ChannelHandlerContext}.
     */
    Channel channel();

    /**
     * Returns the {@link EventExecutor} which is used to execute an arbitrary task.
     */
    EventExecutor executor();

    /**
     * The unique name of the {@link ChannelHandlerContext}.The name was used when then {@link ChannelHandler}
     * was added to the {@link ChannelPipeline}. This name can also be used to access the registered
     * {@link ChannelHandler} from the {@link ChannelPipeline}.
     */
    String name();

    /**
     * The {@link ChannelHandler} that is bound this {@link ChannelHandlerContext}.
     */
    ChannelHandler handler();

    /**
     * Return {@code true} if the {@link ChannelHandler} which belongs to this context was removed
     * from the {@link ChannelPipeline}. Note that this method is only meant to be called from with in the
     * {@link EventLoop}.
     */
    boolean isRemoved();

    @Override
    ChannelHandlerContext fireChannelRegistered();

    @Override
    ChannelHandlerContext fireChannelUnregistered();

    @Override
    ChannelHandlerContext fireChannelActive();

    @Override
    ChannelHandlerContext fireChannelInactive();

    @Override
    ChannelHandlerContext fireExceptionCaught(Throwable cause);

    @Override
    ChannelHandlerContext fireUserEventTriggered(Object evt);

    @Override
    ChannelHandlerContext fireChannelRead(Object msg);

    @Override
    ChannelHandlerContext fireChannelReadComplete();

    @Override
    ChannelHandlerContext fireChannelWritabilityChanged();

    @Override
    ChannelHandlerContext read();

    @Override
    ChannelHandlerContext flush();

    /**
     * Return the assigned {@link ChannelPipeline}
     */
    ChannelPipeline pipeline();

    /**
     * Return the assigned {@link ByteBufAllocator} which will be used to allocate {@link ByteBuf}s.
     */
    ByteBufAllocator alloc();

    /**
     * @deprecated Use {@link Channel#attr(AttributeKey)}
     */
    @Deprecated
    @Override
    <T> Attribute<T> attr(AttributeKey<T> key);

    /**
     * @deprecated Use {@link Channel#hasAttr(AttributeKey)}
     */
    @Deprecated
    @Override
    <T