优雅停机需分阶段协同：先监听sigterm信号触发流程，再拒绝新连接并放行存量请求，接着调用shutdowngracefully()逐级关闭eventloopgroup并等待任务完成，最后通过shutdownhook兜底清理资源。

在 NIO 框架（尤其是 Netty）中实现优雅停机，核心是让通信层“有感知、有缓冲、有收尾”——不丢请求、不丢消息、不漏资源。它不是简单调用 shutdown()，而是一套分阶段协同的退出流程。

明确触发入口：接收并响应系统信号

Java 进程无法自动感知外部停止指令，必须显式监听操作系统信号（如 Linux 的 SIGTERM）。Netty 本身不绑定信号处理，需由应用层注册：

• 使用 Signal.handle(new Signal("TERM"), new SignalHandler()) 捕获 kill -15 <pid></pid>
• Windows 下可监听 SIGINT（对应 Ctrl+C），但生产环境以 SIGTERM 为准
• 收到信号后，**不立即退出 JVM**，而是启动优雅退出流程，例如标记服务为“只读”或关闭新连接接入

控制流量入口：拒绝新请求，放行存量请求

对 Web 或 RPC 场景，停机第一要务是切断新流量，避免雪上加霜：

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• 如果是 Spring Boot + Netty（如 WebFlux），启用 server.shutdown=graceful，容器会自动暂停接受新连接，但已建立的连接仍可完成当前请求
• 纯 Netty 场景，可在 ChannelInboundHandler 中拦截新连接（如重写 channelActive 逻辑），或直接调用 ServerBootstrap.config().group().shutdownGracefully() 让 Boss 线程组停止 accept
• 配合反向代理或注册中心（如 Nacos、Eureka），提前触发服务下线通知，引导流量绕行

释放通信资源：逐级关闭 EventLoopGroup

Netty 的资源核心在 EventLoopGroup（如 NioEventLoopGroup），其优雅关闭必须调用 shutdownGracefully()，而非 shutdown()：

• shutdownGracefully() 会将所有 EventLoop 状态置为 ST_SHUTTING_DOWN，不再调度新任务
• 继续执行队列中已提交的任务（包括未 flush 的 write、pending 的定时任务、正在 read 的数据包）
• 支持超时控制：shutdownGracefully(quietPeriod, timeout, unit) —— quietPeriod 是等待无新任务的静默期，timeout 是强制终止上限
• 务必 await 终止完成：group.shutdownGracefully().awaitUninterruptibly(30, TimeUnit.SECONDS)，否则 JVM 可能提前退出

兜底与协作：ShutdownHook + 资源清理链

信号处理可能失效（如容器未透传 SIGTERM、JVM 崩溃），因此需双重保障：

• 注册 JVM ShutdownHook：Runtime.getRuntime().addShutdownHook(new Thread(this::doGracefulShutdown))
• 在钩子中复用同套逻辑：先关业务线程池、再关 Netty、最后关数据库连接池等外部资源
• 注意：ShutdownHook 不保证一定执行（kill -9、OOM crash 等场景会跳过），所以关键状态持久化、幂等设计不能依赖它
• @PreDestroy（Spring 环境）可作为补充，用于 Bean 级别清理，但不能替代 Netty 层的 shutdownGracefully

整个过程不是单点操作，而是信号 → 流量拦截 → 任务 draining → 资源释放 → JVM 退出的链式反应。只要任一环节阻塞（比如某个 handler 死循环、DB 事务卡住），都会拖垮整个停机流程。所以实际落地时，每个环节都要设超时、加日志、留 traceID，方便定位卡点。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南