有次服务滚动发布，监控里出现一小撮 499 和 5xx。代码没改，数据库也正常，最后查到原因很朴素：实例收到 SIGTERM 后 Web 容器确实开始优雅停机，但异步线程池还在接新任务，MQ 消费也没暂停。流量还没完全摘掉，实例已经开始退出，边界乱了。
Spring Boot 官方支持 graceful shutdown，常见配置是 server.shutdown=graceful 和 spring.lifecycle.timeout-per-shutdown-phase。但生产里别误会：Web 容器优雅停机只是入口，业务线程池、定时任务、消息消费、连接池释放，都要进入同一套停机剧本。
第一步不是停服务，而是摘流量
在容器或 Kubernetes 环境里，我会先让 readiness 变成 DOWN，让负载均衡不再把新请求打进来。然后等待一小段传播时间，再进入真正的停机。否则你以为服务在优雅退出，外部还在持续发新请求。
这个等待时间不是拍脑袋，要看网关、注册中心、LB 的刷新周期。很多偶发 5xx，本质就是摘流量传播还没完成。
Web graceful 只保护正在处理的 HTTP 请求
server.shutdown=graceful 会让 Web 服务器停止接新请求，并等待正在处理的请求完成。这个能力很有用，但它不会自动理解你的业务异步任务，也不会替你暂停 MQ consumer。
server:
shutdown: graceful
spring:
lifecycle:
timeout-per-shutdown-phase: 30s
线程池要明确拒绝新任务并等待旧任务
如果项目里用了 ThreadPoolTaskExecutor，我会显式配置等待任务完成和等待时间。否则发布时可能出现任务提交成功但还没执行完，JVM 就开始退出。
更重要的是任务本身要支持幂等和可中断。优雅停机不是无限等待，超过窗口就要失败、重试或交给补偿任务处理。没有幂等，停机窗口越长，风险越隐蔽。
MQ、定时任务和批处理要单独设计
消息消费最好在停机早期暂停拉取新消息，已经拿到的消息处理完成后再 ack。定时任务要避免停机期间又触发一轮长任务。批处理任务要能记录 checkpoint，退出后可以从断点继续。
上线检查清单
- readiness 下线到停止进程之间，是否留足 LB/网关传播时间？
- server.shutdown 和 spring.lifecycle.timeout-per-shutdown-phase 是否配置？
- ThreadPoolTaskExecutor 是否等待任务完成，等待时间是否小于整体停机窗口？
- MQ consumer 是否先暂停拉取，再等待已拉取消息处理完成？
- @Scheduled 和批处理任务是否支持中断、幂等和断点续跑？
- 是否用真实 SIGTERM 压测过滚动发布，而不是只在本地点停止按钮？
最后聊两句
优雅停机不是一个配置项，而是一组退出协议。入口不再接流量，正在处理的请求有窗口，后台任务有收口，资源释放有顺序，这四件事合在一起才叫真正优雅。
我的建议很简单：把停机当成一次正常业务流程来设计和压测。服务能优雅启动只是基本功，能优雅退出才说明它真的适合生产滚动发布。
Resilience4j 超时重试熔断实战：别把慢接口重试成雪崩 
