Spring Boot中线程池应作为IoC容器管理的Bean，使用@Bean(destroyMethod="shutdown")确保生命周期与应用一致；禁用Executors工厂类，改用ThreadPoolExecutor显式构造并配置合理队列容量与拒绝策略（如CallerRunsPolicy），配合超时控制、异常兜底和监控告警，防止逻辑假性关闭导致网关502。
Java线程池意外关闭本身不会直接返回502，但会引发下游响应超时或中断，最终被网关（如Nginx）判定为上游不可用，从而返回502 Bad Gateway。关键不在于“线程池是否关了”，而在于它是否导致请求无法在网关超时窗口内完成响应。
确保线程池生命周期与应用容器一致
Spring Boot应用中，线程池应作为Bean托管给IoC容器管理，避免手动new或静态单例初始化。容器启动时创建，关闭时自动销毁，防止JVM仍在运行但线程池已shutdown的“半死”状态。
- 使用
@Bean(destroyMethod = "shutdown")声明销毁方法，让Spring在上下文关闭时调用 - 禁用
Executors工厂类（如newFixedThreadPool），改用ThreadPoolExecutor显式构造，控制队列容量和拒绝策略 - 若线程池用于异步导出等长耗时任务，建议单独隔离，不复用Web请求线程池（如Tomcat线程池）
避免任务阻塞导致线程池“假性关闭”
线程池未关闭，但所有线程都卡在IO等待、无响应的第三方调用或无限重试上，等效于“逻辑关闭”——新请求进不来，旧请求不出去，网关超时后报502。
- 对所有外部调用（HTTP、DB、MQ）设置明确超时：HTTP Client启用连接/读取超时；JDBC配置
socketTimeout；Redis设timeout - 禁止在任务中使用无界阻塞操作（如
LinkedBlockingQueue.put()、无超时的CountDownLatch.await()） - 批量导出类任务，应拆分批次+限流，而非单次提交万级数据到线程池
配置合理拒绝策略并监控告警
当线程池饱和或队列满时，拒绝策略决定系统是快速失败还是静默堆积。静默堆积（如无界队列）会导致请求延迟飙升，触发网关502；而快速失败可配合降级保障核心链路。
立即学习“Java免费学习笔记（深入）”；
- 拒绝策略优先选
AbortPolicy（抛异常）或CallerRunsPolicy（由调用线程执行），避免任务无限排队 - 通过Micrometer暴露
active、queued、rejected指标，接入Prometheus+Grafana，当排队数持续＞80%队列容量时告警 - Nginx侧同步调整
proxy_read_timeout，使其略大于业务最长合理RT（如导出接口设为120s），避免过早切断有效请求
统一异常处理与资源释放兜底
未捕获异常可能导致线程终止（尤其在fixedThreadPool中），线程数逐步减少，吞吐下降，间接引发超时和502。
- 所有提交到线程池的任务，必须包裹
try-catch，记录错误并确保资源释放（数据库连接、文件流等） - 使用
submit(Callable)代替execute(Runnable)，通过Future.get()捕获执行异常 - 在线程池构造时设置
ThreadFactory，为线程命名并指定UncaughtExceptionHandler，防止异常静默丢失
