EventLoopGroup 是 Netty 的线程调度骨架，负责为 Channel 分配绑定固定线程的 EventLoop；Boss 专管连接建立，Worker 专管 I/O 处理，二者职责隔离以避免相互阻塞，需正确配置线程数并避免在 Boss 线程执行耗时操作。
EventLoopGroup 是 Netty 的线程调度骨架
它不直接处理 I/O，而是为 Channel 分配 EventLoop——每个 EventLoop 绑定一个线程，负责该线程上所有 Channel 的生命周期、事件轮询和任务执行。你可以把它理解成“线程池 + 事件循环管理器”的组合体，但比普通线程池更重：线程不能被随意替换，Channel 一旦注册，就永远归属那个 EventLoop。
为什么必须分 Boss 和 Worker 两个 EventLoopGroup
这是 Netty 对“连接建立”和“连接数据读写”做职责隔离的关键设计。Boss 只干一件事：接受新连接；Worker 只干另一件事：处理已建立连接的读、写、异常、超时等 I/O 事件。混在一起会导致 accept 阻塞或被长耗时业务拖慢，进而影响新连接接入。
-
bossGroup通常只需 1 个线程（NioEventLoopGroup(1)），因为 accept 操作本身轻量，且 Linux 的epoll_wait在多线程调用时有额外开销 -
workerGroup线程数默认是Runtime.getRuntime().availableProcessors() * 2，适合 CPU 密集型 I/O 处理；若业务逻辑大量阻塞（如同步 DB 调用），需额外增加线程，但要小心上下文切换成本 - 两者都必须是
NioEventLoopGroup（或EpollEventLoopGroup等），不能混用不同类型，否则启动时报UnsupportedOperationException
常见错误：把业务逻辑扔进 Boss 线程
典型现象是服务启动后无法接收新连接，或者 accept 延迟飙升。这是因为你在 ChannelInitializer.initChannel() 里写了耗时操作（比如加载配置文件、初始化数据库连接池），而这个方法是在 Boss 线程中调用的。
- 所有与 Channel 初始化无关的耗时操作，必须移到
workerGroup所在的EventLoop中执行，例如：channel.eventLoop().submit(() -> { /* 加载配置 */ }) - 不要在
channelRead()回调里直接调用阻塞方法；如果必须，用eventLoop().execute()切到其他线程池，而不是让 Worker 线程卡住 - 检查日志里是否出现
io.netty.channel.ChannelException: Unable to create Channel from class class xxx——这往往是initChannel()抛异常导致 Boss 线程退出，整个bossGroup失效
线程模型不是越复杂越好，别盲目套用默认配置
很多项目照搬官方示例写 new NioEventLoopGroup(1) 和 new NioEventLoopGroup()，但没考虑实际场景。比如部署在容器里，availableProcessors() 返回的是宿主机核数，而非容器限制后的值；又比如只跑 HTTPS，SSL 握手本身就很耗 CPU，Worker 线程数可能需要上调。
- 可通过 JVM 参数
-Dio.netty.eventLoopThreads=8全局调整默认线程数，避免硬编码 - 监控
EventLoop的任务队列长度（pendingTasks()）和执行延迟，比看 CPU 使用率更能反映线程是否过载 - 关闭连接时记得调用
bossGroup.shutdownGracefully()和workerGroup.shutdownGracefully()，否则 JVM 可能无法退出——这是最容易被忽略的资源泄漏点
