如何降低Netty线程唤醒导致的CPU资源消耗？

• 实现批量Flush聚合，减少主动唤醒次数
  不要每次发送数据包都独立调用flush()，改为批量触发flush：

  可以通过自定义入站/出站Handler实现攒包逻辑，设置两个触发条件：累计攒够指定大小/数量的数据包、或者距离上次flush达到固定超时阈值（比如5ms），满足任意条件再统一调用flush。
  同时配合Netty自带的WriteBufferWaterMark配置，调整高低水位线，避免缓冲过多导致内存溢出，也能自动控制flush频率。

• 自定义SelectStrategy实现延迟唤醒
  放弃SelectStrategy.BUSY_WAIT策略，改为自定义选择策略，核心逻辑是：当EventLoop收到新的写入任务时，不立刻调用wakeup()唤醒Selector，而是先标记有待处理任务，等待Selector本次阻塞的超时周期结束后统一处理，也可以设置1~2ms的极短等待窗口，合并短时间内的多次写入唤醒请求，实测可以降低30%以上的Selector唤醒频率，同时不会明显增加请求延迟。
  配置示例：

  SelectStrategyFactory selectStrategyFactory = new DefaultSelectStrategyFactory() {
      @Override
      public SelectStrategy newSelectStrategy() {
          return (selectSupplier, hasTasks) -> {
              // 有任务时也先执行一次select，带极短超时，合并更多任务
              if (hasTasks) {
                  return selectSupplier.get(1);
              }
              return super.newSelectStrategy().calculateStrategy(selectSupplier, hasTasks);
          };
      }
  };
  // 初始化NioEventLoopGroup时传入自定义策略
  NioEventLoopGroup workerGroup = new NioEventLoopGroup(workerThreads, threadFactory, selectStrategyFactory);
  

• 修正EventLoop复用逻辑
  Netty默认会将多个Channel绑定到同一个EventLoop上，你之前复用失败大概率是用法错误：不要为每个Channel单独创建EventLoopGroup实例，全局共用同一个Worker EventLoopGroup即可，同一个EventLoop上所有Channel的写入操作触发一次唤醒即可批量处理，不需要单独唤醒多次。
• 补充优化手段
  1. Linux环境优先使用Epoll模式代替NIO模式，Epoll的Selector唤醒开销远低于JDK NIO实现
  2. 合理设置EventLoop线程数，建议设置为CPU核心数的1~1.5倍，减少多线程上下文切换开销
  3. 关闭Selector.autoWakeup配置，避免不必要的自动唤醒

内容的提问来源于stack exchange，提问作者andreasdc