shutdowngracefully() 需显式配置静默期和超时，并依次关闭channel、workergroup、bossgroup；禁用shutdownhook中sync调用，须检查selector注销与handler引用泄漏。

shutdownGracefully() 不是“调了就完事”，它有静默期和超时控制

直接调用 bossGroup.shutdownGracefully() 只是发出了关闭信号，Netty 并不会立刻释放线程、关闭 Selector 或回收 Channel。它会先进入 ST_SHUTTING_DOWN 状态，并启动两个关键时间窗口：quietPeriod（静默期）和 timeout（总超时）。静默期内若仍有新任务提交（比如某个 Channel 还在 flush 未发完的消息），静默期会重置；超时一到，不管是否还有任务，强制进入终止流程。

常见错误是只传一个参数或全用默认值，导致： - 静默期太短（如 0 秒），积压的响应没发出去，客户端收不到 ACK，重试引发重复请求 - 超时太长（如 60 秒），进程卡住不退出，K8s readiness probe 失败、滚动更新阻塞 - 忘记 await（即没等 terminationFuture().sync()），主线程提前退出，NIO 线程被强制中断，资源泄漏

实操建议： - 生产环境推荐显式指定参数，例如 bossGroup.shutdownGracefully(2, 15, TimeUnit.SECONDS)（2 秒静默 + 15 秒兜底） - workerGroup 同样要调用，且通常比 bossGroup 更关键（承载实际 IO 和业务逻辑） - 必须链式等待：bossGroup.shutdownGracefully(...).terminationFuture().sync()

只关 bossGroup 是假优雅，workerGroup 和 Channel 必须同步处理

bossGroup 只负责 accept 新连接，真正干活的是 workerGroup 和每个活跃的 Channel。如果只 shutdown bossGroup，已建立的连接还在读写、定时任务照常调度、发送队列里的消息可能永远发不出去——这不是优雅停机，是“假装关了”。

典型现象： - 日志里看到 “Shutting down” 但进程 CPU 仍高，jstack 显示 NioEventLoop 线程仍在 RUNNABLE - 客户端收到 RST，而非 FIN，说明底层 Channel 被强制 close - 内存缓慢上涨后 OOM，因 Channel 的 pipeline 没清理，引用未释放

实操建议： - shutdown 顺序应为：先通知业务层停止接收新请求 → 关闭所有活跃 Channel（遍历 channel.close() 或 closeFuture().sync()）→ 再调用 workerGroup.shutdownGracefully() → 最后 bossGroup.shutdownGracefully() - 若使用 ServerBootstrap.bind() 返回的 ChannelFuture，记得先 channel.closeFuture().sync() 等监听端口真正释放 - 所有自定义的 EventExecutor 或定时任务（如 eventLoop.schedule()）也需主动 cancel

JVM ShutdownHook 里调 shutdownGracefully 很危险

很多人把 shutdownGracefully() 塞进 Runtime.getRuntime().addShutdownHook()，以为万事大吉。但 ShutdownHook 是 JVM 最后一道防线，运行在单线程、无超时保障、不可中断的上下文中。一旦 Netty 内部某步卡住（如某个 Channel 的 closeFuture 死锁、第三方 handler 阻塞），整个 JVM 就 hang 住，kill -15 变成无效操作。

更糟的是： - ShutdownHook 中无法捕获 InterruptedException，sync() 可能永久阻塞 - Spring Boot 的 Actuator /health 端点此时已下线，运维无法感知进程状态 - Windows 下 Ctrl+C 触发的 ShutdownHook，quietPeriod 行为与 Linux 有细微差异，测试容易漏掉

实操建议： - 优先用信号量方式（Signal.handle(new Signal("TERM"), ...)），在收到 SIGTERM 时启动独立线程执行 shutdown 流程，可加超时控制和日志追踪 - 若必须用 ShutdownHook，只做标记（如设 volatile boolean isShuttingDown = true），让主业务线程轮询该标志并自行触发 shutdown，避免在 Hook 里调 sync 方法 - 总是设置 JVM 参数 -XX:+UseParallelOldGC 或 -XX:+UseG1GC，避免 CMS GC 在 shutdown 阶段触发 Full GC 导致卡顿

资源没完全释放？检查 Selector 注销和 Channel 引用链

即使 shutdownGracefully() 返回成功，也可能残留资源：Selector 里还挂着已关闭 Channel 的 key、ByteBuf 池未清空、自定义 ChannelHandler 持有外部对象引用。这类问题不会报错，但会导致句柄数（lsof -p PID | wc -l）居高不下，重启几次后端口 bind 失败。

关键检查点： - Channel 关闭后，确保其 pipeline 中所有 ChannelHandler 的 handlerRemoved() 被调用（可打日志验证） - 使用 ResourceLeakDetector.setLevel(Level.PARANOID) 开启内存泄漏检测，尤其关注 PooledByteBufAllocator - 调用 workerGroup.terminationFuture().sync() 后，再确认 workerGroup.isTerminated() 和 workerGroup.isShutdown() 均返回 true，而非仅 isShuttingDown()

容易被忽略的一点：如果你在 ChannelInitializer 里向 Channel 添加了非共享的 ChannelHandler（如带状态的编解码器），而该 handler 又被其他地方强引用，那么 Channel 关闭时 handler 不会被 GC，间接拖慢整个 EventLoopGroup 的终止。