Spring Boot 定时任务需配置优雅关闭：ThreadPoolTaskScheduler 必须设 setWaitForTasksToCompleteOnShutdown(true) 和 setAwaitTerminationSeconds(60)；自定义线程池应通过 destroyMethod="shutdown" 或 @PreDestroy 调用 shutdown() 与 awaitTermination()；配合 server.shutdown: graceful 及 spring.lifecycle.timeout-per-shutdown-phase 配置，确保容器停机时任务完整执行。
核心问题在于：spring boot 默认的定时任务线程池（threadpooltaskscheduler）和自定义线程池（如 threadpooltaskexecutor）在容器关闭时若未显式配置等待策略，会直接终止正在运行的任务，导致数据不完整、事务中断、消息丢失等严重后果。
确保定时任务线程池支持优雅关闭
Spring Boot 的 @Scheduled 默认使用单线程调度器，但生产环境通常需自定义线程池。关键不是“有没有线程池”，而是“关的时候等不等任务完成”：
- 必须启用
setWaitForTasksToCompleteOnShutdown(true)，否则 shutdown 时直接中断执行中任务 - 必须设置合理超时时间
setAwaitTerminationSeconds(60)，避免无限阻塞导致 JVM 挂住 - 线程池大小建议与业务负载匹配，避免因队列积压过长而超时失败
示例配置：
@Bean
public ThreadPoolTaskScheduler taskScheduler() {
ThreadPoolTaskScheduler scheduler = new ThreadPoolTaskScheduler();
scheduler.setPoolSize(8);
scheduler.setThreadNamePrefix("scheduled-");
scheduler.setWaitForTasksToCompleteOnShutdown(true);
scheduler.setAwaitTerminationSeconds(60);
return scheduler;
}
手动管理自定义线程池的生命周期
如果你在代码中 new 出了 ThreadPoolTaskExecutor 或其他线程池（比如用于异步日志、批量处理、MQ 消费），Spring 不会自动关闭它——@PreDestroy 必须由你显式编写，并调用 shutdown() + awaitTermination()：
- 仅调用
shutdown()：拒绝新任务，但允许已提交任务继续执行（推荐） - 避免
shutdownNow()：它会尝试中断所有线程，对未响应InterruptedException的任务无效，且易引发状态混乱 - 务必捕获
awaitTermination超时并记录告警，便于定位卡死任务
正确写法示例：
@Component
public class AsyncTaskExecutorConfig {
@Bean(destroyMethod = "shutdown")
public ThreadPoolTaskExecutor asyncTaskExecutor() {
ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
executor.setCorePoolSize(4);
executor.setMaxPoolSize(16);
executor.setQueueCapacity(100);
executor.setThreadNamePrefix("async-");
executor.initialize();
return executor;
}
}
注意：destroyMethod = "shutdown" 是声明式关闭，比 @PreDestroy 更简洁可靠；若需更精细控制（如超时后强制清理），再配合 @PreDestroy 手动 await。
配合全局优雅停机机制协同工作
单靠线程池自身配置还不够——得让整个 Spring Boot 容器有足够时间执行这些关闭逻辑：
- 在
application.yml中开启内置优雅停机：server.shutdown: graceful - 设置 Bean 销毁总时限：
spring.lifecycle.timeout-per-shutdown-phase: 45s（应 ≥ 线程池 await 时间） - 禁用暴力信号：永远不用
kill -9，统一使用kill -15或docker stop（默认发 SIGTERM） - 若集成 Actuator，可通过
POST /actuator/shutdown触发标准关闭流程，确保事件顺序可控
验证是否真正生效
不能只看日志有没有 “Shutting down” ——要确认关键行为发生：
- 容器收到 SIGTERM 后，立即停止接收新 HTTP 请求（可通过健康检查/负载均衡摘流验证）
- 线程池日志中出现类似 “Shutting down ExecutorService 'xxx'” 且后续有 “awaiting termination…”
- 应用进程在设定超时时间内自然退出，而非被系统强制 kill
- 数据库事务、MQ 消息消费等最终一致性操作能完整落库（建议加幂等+补偿机制兜底）
