应手动构造有界线程池：设合理maxpoolsize（io型建议≤100，计算型20～40）、arrayblockingqueue（50～200）、keepalivetime（io型10～30秒）、allowcorethreadtimeout、callerrunspolicy或自定义拒绝策略。
直接用 Executors.newCachedThreadPool() 替代方案，等于把线程创建权完全交给系统——核心线程为 0、最大线程数是 Integer.MAX_VALUE、队列是同步移交（SynchronousQueue），看似“按需伸缩”，实则毫无节制。高并发下瞬间拉起数百上千线程，极易触发 OutOfMemoryError: unable to create new native thread 或 CPU 抢占风暴。真正安全的替代，是手动构造一个有明确最大边界、可回收空闲线程、且拒绝策略可控的 ThreadPoolExecutor。
明确最大线程数，堵住失控源头
必须显式设定 maximumPoolSize，绝不能依赖默认值。该值不是拍脑袋定的，而是结合业务峰值与机器资源综合评估：
- 若任务以短时 IO 为主（如 HTTP 调用、Redis 查询），建议从
2 × Runtime.getRuntime().availableProcessors()起步，压测后逐步上调，上限建议不超过 100（单机） - 若任务含一定计算量，或服务部署在资源受限容器中，应更保守，例如设为 20～40
- 永远确保
corePoolSize ≤ maximumPoolSize，否则构造时直接抛IllegalArgumentException
选用有界队列，避免任务无限堆积
CachedThreadPool 本质不缓存任务，靠不断新建线程应对压力；但盲目新建不可控。自定义池要改用有界阻塞队列，让任务在“等线程”和“被拒绝”之间取得平衡：
- 推荐
ArrayBlockingQueue，容量设为 50～200（视任务平均耗时与吞吐目标而定） - 避免
LinkedBlockingQueue无参构造（即默认容量Integer.MAX_VALUE），那是FixedThreadPool的陷阱重演 - 队列满 + 线程达最大值 → 触发拒绝策略，这是你主动设防的关键出口
设置合理 keepAliveTime，兼顾弹性与稳定
CachedThreadPool 的 60 秒空闲回收看似合理，但实际场景中可能造成“波峰刚过就销毁，波谷刚来又重建”的抖动。手动配置时注意：
-
keepAliveTime仅对超出corePoolSize的线程生效，所以先定好corePoolSize（建议设为 2～5，保证基础吞吐不依赖频繁创建） - IO 密集型任务：设为 10～30 秒，响应快、回收及时
- 若希望核心线程也参与超时回收（比如极低频定时任务），需额外调用
allowCoreThreadTimeOut(true)
绑定强感知拒绝策略，把失败变成可观测信号
CachedThreadPool 在线程创建失败时会直接抛异常，但往往被上层吞掉，难以定位。自定义池应选一个能暴露问题、便于降级或补偿的策略：
-
CallerRunsPolicy：让提交线程自己执行任务，天然限流，适合非关键路径 - 自定义策略：记录日志 + 上报监控 + 写入延迟队列（如 Redis Stream），实现异步重试
- 避免
AbortPolicy（直接抛RejectedExecutionException）在核心链路中裸用，除非你已做好全链路熔断
替换时，把原 newCachedThreadPool() 的调用点统一改为注入你定义的 ThreadPoolExecutor Bean，并配合线程名前缀、统一异常捕获和 Prometheus 指标埋点，就能彻底摆脱“线程雪崩”风险，让弹性真正可控。
