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）并调高系统级线程限额（谨慎操作）。
