不能直接用 threadpoolexecutor 替代 nioeventloopgroup，因其无法保证i/o事件串行执行，违反netty“一channel一eventloop”契约，导致channelhandler、pipeline等并发访问引发竞态与状态错乱。
为什么不能直接用 ThreadPoolExecutor 替代 NioEventLoopGroup
因为 ThreadPoolExecutor 无法保证 I/O 事件的串行执行，而 Netty 的核心契约是「一个 Channel 绑定到且仅绑定到一个 EventLoop」。一旦用标准线程池处理 Channel 的读写、编解码、用户逻辑，就会出现多线程并发访问同一 Channel 的 pipeline、unsafe 或自定义 ChannelHandler 实例——这会直接触发竞态，比如 ReferenceCountException、ConcurrentModificationException，或更隐蔽的状态错乱（如解码器中 decodeBuf 被两个线程同时调用）。
常见错误现象：
- 自定义
ChannelHandler中使用了非线程安全的集合（如ArrayList）缓存临时数据，偶发IndexOutOfBoundsException -
ByteBuf在多个线程间被重复release()，抛出IllegalReferenceCountException - 连接刚建立就断开，日志里出现
java.nio.channels.ClosedChannelException但无明确 close 调用
NioEventLoop 的单线程模型如何实现无锁
关键不在于“不用锁”，而在于“根本不需要锁”：每个 NioEventLoop 是一个被严格限定为单线程驱动的事件循环，所有属于该 Loop 的任务（I/O 事件、定时任务、用户提交的 execute() 任务）都排队进入其内部的 taskQueue，由同一个线程按 FIFO 顺序串行执行。
这意味着：
- 对 Channel 状态的修改（如
channel.read()、ctx.write()）不会并发发生 -
ChannelPipeline中 handler 的channelRead()和write()调用天然串行，无需synchronized或ReentrantLock - 用户在 handler 中操作成员变量（如计数器、缓存 buffer）时，默认就是线程安全的
注意：taskQueue 本身是线程安全的（底层用 MpscLinkedQueue），但它只承担“入队”和“本线程出队”的职责；真正的无锁收益来自“执行上下文唯一”，而非队列实现。
什么时候会破坏这个无锁优势
只要让非所属 EventLoop 的线程直接操作 Channel 或其 pipeline，就立刻打破模型。典型踩坑点：
- 在 handler 中启动新线程（如
new Thread(() -> ctx.write(...)).start()）并调用write() - 将
ChannelHandlerContext保存到全局 map，之后从其他线程调用ctx.fireChannelRead() - 使用
ctx.executor().submit()提交任务，却误以为它会自动切换回本 EventLoop（实际是交给外部线程池） - 配置了
childOption(ChannelOption.SO_KEEPALIVE, true)后，在非 EventLoop 线程里调用channel.close()，导致 close 事件未被正确调度
正确做法：跨线程操作必须显式调度回所属 EventLoop，用 channel.eventLoop().execute(() -> { ... }) 或 ctx.writeAndFlush(...)（后者自动确保在所属 Loop 执行）。
NioEventLoopGroup 的线程数设置不是越多越好
NioEventLoopGroup 的构造参数 nThreads 决定了底层 Selector 的数量（Linux 下对应 epoll fd），而非 CPU 核心数。默认值 0 表示 2 * Runtime.getRuntime().availableProcessors()，但这只是经验值。
影响因素包括：
- I/O 密集型场景（如代理、转发）：适当增加线程数可提升并发连接处理能力，但超过系统文件描述符上限或 selector 轮询开销反而下降
- CPU 密集型业务逻辑（如加解密、序列化）：应拆离到
EventExecutorGroup，避免阻塞 EventLoop，否则整个 Loop 下所有 Channel 都卡住 - Netty 4.1+ 对单个
NioEventLoop的selectNow()和任务批量处理做了优化，线程数过多反而增加上下文切换和内存占用
真正容易被忽略的是：NioEventLoop 不仅处理 I/O，还负责执行所有绑定到它的异步任务。一旦某个 handler 里写了 Thread.sleep(1000) 或调用了同步阻塞 IO（如 FileInputStream.read()），整个 Loop 就停摆——这不是锁的问题，是模型被人为阻塞了。
