Netty的EventLoop是单线程绑定执行单元，所有I/O事件和用户任务均在固定线程内串行执行，避免线程切换开销；一个Channel终身绑定一个EventLoop，多Channel可共享同一EventLoop，任务队列采用无锁MpscQueue，确保高效、线程安全的本地调度。
Netty 的 EventLoop 是单线程模型，但“多线程切换零开销”不是指跨线程调度无成本，而是指在 同一个 EventLoop 内避免线程上下文切换 —— 它根本不需要切换线程，自然没有开销。
EventLoop 本质是单线程绑定的执行单元
每个 EventLoop 实例在启动时就固定绑定一个 Java 线程（通常由 EventLoopGroup 中的线程池分配），之后所有注册到它的 Channel 的 I/O 事件（读、写、连接）和用户任务（如 channel.eventLoop().execute()）都严格在这个线程内串行执行。没有线程迁移，就没有栈保存/恢复、CPU 缓存失效、TLB 刷新等传统线程切换代价。
- 一个 Channel 只属于一个 EventLoop，生命周期内不会换线程
- 多个 Channel 可共享同一个 EventLoop（常见于高吞吐小连接场景）
- 不同 EventLoop 之间完全隔离，不共享状态，也无需同步
“零开销”体现在任务调度而非并发执行
所谓“多线程切换零开销”，实际是指：当业务逻辑被提交到当前 Channel 所属的 EventLoop 时，它不会触发线程切换 —— 即使调用方来自其他线程（比如 HTTP 请求由 Boss 线程接收后，将 Channel 注册到 Worker EventLoop），只要后续操作（如解码、业务处理）通过 eventLoop().execute() 或 writeAndFlush() 提交，就直接入队、由该 EventLoop 线程在下一次轮询中顺序执行。
- 避免了
ExecutorService.submit()那种跨线程投递带来的锁竞争与队列同步开销 - 任务队列是无锁的 MpscQueue（Multi-Producer Single-Consumer），生产者可来自任意线程，消费者仅 EventLoop 自身线程
- 内存可见性靠 volatile + happens-before 保证，不依赖 synchronized 或 CAS 重试
真正要规避的是跨 EventLoop 的线程跳转
如果业务代码误用了其他线程（如 new Thread()、公共线程池）去操作 Channel 或其 pipeline，就会引发非法状态异常（IllegalStateException: channel not registered）或并发修改风险。Netty 要求所有 Channel 相关操作必须在所属 EventLoop 线程执行。
立即学习“Java免费学习笔记（深入）”；
- 正确做法：用
channel.eventLoop().execute(Runnable)把任务“投递回”本 EventLoop - 阻塞操作（如 DB 查询、文件读写）必须卸载到独立的业务线程池，再用
channel.writeAndFlush()回写结果 —— 此时写操作仍发生在 EventLoop 线程，只是数据准备在线程外 - 切勿在 Handler 中直接调用
Thread.sleep()或同步 IO，否则会阻塞整个 EventLoop，影响所有关联 Channel
对比传统线程池模型更易理解优势所在
假设用 Tomcat 的每个请求分配新线程：1000 并发 ≈ 1000 线程，频繁创建/销毁、上下文切换、栈内存占用；而 Netty 的 Worker EventLoop 数量通常为 CPU 核数 × 2，1000 连接可能只跑在 8~16 个线程上，每个线程通过事件循环+非阻塞 IO 复用处理数百连接 —— “零开销”本质是用更少线程做更多事，且每个任务都在原线程完成，不跳转。
- 没有线程切换 → 没有调度延迟、没有缓存抖动
- 数据局部性好：Channel、Pipeline、ByteBuf 等对象常驻同一 CPU 缓存行
- 编程模型清晰：开发者只需关注“是否在正确的 EventLoop 上”，而非“如何安全地跨线程传递状态”
