必须将线程池声明为spring管理的bean并指定销毁方法，否则应用关闭时线程池无法自动关闭，导致请求中断、资源泄漏、数据不一致等严重问题。
因为直接使用原生线程池（如 new ThreadPoolExecutor(...)）会绕过 Spring 容器生命周期管理，导致应用关闭时线程池无法被自动感知和关闭，进而引发请求中断、资源泄漏、数据不一致等严重线上问题。
原生线程池不参与 Spring 关闭流程
Spring 的优雅停机依赖容器对 Bean 的统一销毁调度。只有被 Spring 管理的 Bean（如通过 @Bean 或 @Component 声明）才能触发 @PreDestroy、DisposableBean.destroy() 或 Shutdown Hook 中的清理逻辑。而手动 new 出来的线程池完全游离于容器之外——Spring 启动时不注册它，关闭时也不通知它，更不会等待其任务完成或调用 shutdown()。
未关闭的线程池会阻塞优雅停机全过程
当 Spring Boot 启用 server.shutdown=graceful 后，Web 服务器会停止接收新请求，并等待活跃请求结束。但若这些请求内部提交了任务到未受管的线程池，而该线程池又未显式关闭：
- 线程池中的工作线程可能仍在执行中，JVM 不会自然退出；
- Spring 的 shutdown phase 会在超时（默认 30 秒）后强行终止上下文，此时线程池仍在运行，但其关联的数据库连接、MQ 消费者等资源可能已被提前释放；
- 结果是：正在处理的任务突然丢失上下文、连接失效、事务回滚失败、消息重复消费或丢失。
大厂生产环境的典型连锁故障
在高并发、强一致要求的场景下，这类问题极易放大：
- 订单支付回调失败：异步回调任务提交至原生线程池，关机时任务被丢弃，用户支付成功但订单状态未更新；
- 批量报表导出中断：耗时 2 分钟的导出任务刚跑一半，进程被强制终止，下游系统收不到完成通知；
- K8s 缩容雪崩：Pod 收到 SIGTERM 后因线程池未响应，30 秒内未退出，K8s 触发 SIGKILL，同时新 Pod 尚未就绪，流量短暂断流或打到异常实例；
- 连接池泄漏+线程堆积：每次重启都残留数个未 shutdown 的线程池，数天后节点内存耗尽、GC 频繁、Full GC 卡顿。
正确做法：让线程池成为 Spring 管理的可销毁 Bean
必须将线程池声明为 Spring Bean，并主动实现资源释放逻辑：
- 用
@Bean(destroyMethod = "shutdown")显式指定销毁方法； - 或实现
DisposableBean接口，在destroy()中调用shutdownNow()并 awaitTermination； - 配合
@PreDestroy做前置清理（如取消定时任务、注销监听器）； - 关键点：确保
awaitTermination超时时间 ≤spring.lifecycle.timeout-per-shutdown-phase，避免拖垮整体关机流程。
