Executors.newCachedThreadPool() 因最大线程数为Integer.MAX_VALUE，易在高并发或下游延迟时无限创建线程，导致栈内存耗尽、系统线程数超限及上下文切换风暴，故存在严重资源失控风险。

Executors.newCachedThreadPool() 创建的线程池看似“按需创建、空闲回收”，但其最大线程数设为 Integer.MAX_VALUE（约 21 亿），这在高并发突发场景下极易引发系统级资源耗尽，而非简单的“线程过多”警告。

为什么 Integer.MAX_VALUE 是个危险的默认值？

该值并非设计为“足够大”，而是为表达“无硬性上限”的语义。但 JVM 和操作系统对线程数量有真实约束：

• 每个线程默认占用 1MB 栈空间（可通过 -Xss 调整），1000 个线程就消耗 1GB 堆外内存；
• Linux 默认单进程线程数限制通常为 1024～65535（受 /proc/sys/kernel/threads-max 和 RLIMIT_NPROC 约束）；
• 线程创建本身开销显著：内核调度结构、TLS（线程局部存储）、JVM 线程对象、GC 元数据等都会随线程数线性增长。

典型触发场景：不是压测，而是日常异常

以下情况无需百万 QPS 就可能瞬间拉爆线程池：

• 下游服务响应变慢或超时，导致大量任务堆积并持续创建新线程等待；
• 定时任务误配为“每毫秒执行”，且任务体含阻塞 I/O（如未设超时的 HTTP 调用）；
• 异步日志、监控埋点等辅助逻辑未做限流，流量高峰时批量提交到 cached 线程池；
• 代码中误将 newCachedThreadPool() 用于长期运行的计算型任务（如图像处理），线程无法及时回收。

更安全的替代方案

没有银弹，但可根据场景选择收敛边界明确的构造方式：

• 用 Executors.newFixedThreadPool(n) —— 明确容量，配合有界队列（如 ArrayBlockingQueue）和拒绝策略（如 AbortPolicy 或自定义降级）；
• 手动构建 ThreadPoolExecutor：指定核心/最大线程数、存活时间、队列类型与容量、拒绝策略，例如：
  

  new ThreadPoolExecutor(4, 16, 60L, TimeUnit.SECONDS,<br>    new SynchronousQueue(),<br>    new NamedThreadFactory("biz-task"),<br>    new ThreadPoolExecutor.CallerRunsPolicy());

• 对 I/O 密集型任务，优先考虑 非阻塞模型（如 Netty、Project Reactor），而非靠堆线程缓解阻塞。

如果必须用 newCachedThreadPool()，至少做三件事

• 监控 ThreadPoolExecutor.getPoolSize() 和 getActiveCount()，设置告警阈值（如活跃线程 > 200 持续 1 分钟）；
• 确保所有提交的任务都具备超时控制（如 Future.get(3, TimeUnit.SECONDS)）；
• 在 JVM 启动参数中显式限制线程栈大小（-Xss256k）并调高系统级线程限额（谨慎操作）。