是。CachedThreadPool 会无限制创建线程，因使用 SynchronousQueue 且不设线程数上限，高并发时易致 native thread 耗尽和 OOM；生产环境应改用有界队列与明确 maxPoolSize 的 ThreadPoolExecutor。
CachedThreadPool 会无限制创建线程吗？
会。这是它最核心的风险：CachedThreadPool 内部使用的是 SynchronousQueue，任务提交时若无可复用的空闲线程，就会直接调用 ThreadFactory 创建新线程，且**不设上限**。
常见错误现象：突发大量短任务（如 HTTP 请求、RPC 调用）涌入，线程数在几秒内飙升到数百甚至上千，触发 OutOfMemoryError: unable to create new native thread。
- 不是堆内存溢出，而是操作系统级线程资源耗尽（Linux 默认每进程线程数有限制，如
/proc/sys/kernel/threads-max） -
CachedThreadPool的线程空闲 60 秒后自动终止，但高并发下“创建速度 >> 销毁速度”，根本等不到回收 - 线程栈默认占用 1MB（JVM 参数
-Xss控制），1000 个线程就吃掉 1GB 栈内存，极易压垮 JVM
为什么 Executors.newCachedThreadPool() 不适合生产环境？
因为它的默认构造完全放弃对并发规模的约束，把控制权交给了不可控的外部请求流量。
使用场景仅限于：已知任务极轻量、执行极快（毫秒级）、并发量稳定且可控的测试或工具类代码。真实服务端几乎从不适用。
立即学习“Java免费学习笔记（深入）”；
- 替代方案不是“调小 keepAliveTime”，而是换用有界队列 + 固定大小线程池，例如
new ThreadPoolExecutor(4, 8, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue(100)) -
Executors.newFixedThreadPool(n)看似安全，但它用的是无界LinkedBlockingQueue，任务持续积压仍会导致 OOM（堆内存） - 真正健壮的配置必须同时约束：核心线程数、最大线程数、队列容量、拒绝策略
如何安全地模拟 CachedThreadPool 的“弹性”效果？
用 ThreadPoolExecutor 手动构造，保留弹性扩缩能力，但加上硬性防护。
ThreadPoolExecutor executor = new ThreadPoolExecutor(
2, // corePoolSize：保底线程数
16, // maximumPoolSize：绝不突破的线程上限
60L, TimeUnit.SECONDS,
new SynchronousQueue<>(),
new ThreadFactoryBuilder().setNameFormat("cache-like-%d").build(),
new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝时由调用线程执行，自然限流
);
关键差异点：
- 明确设置
maximumPoolSize = 16，防止无限创建 - 拒绝策略选
CallerRunsPolicy，让过载压力回传到上游（比如 Web 容器线程），触发自然降级或超时，而不是堆积或崩溃 - 避免使用
AbortPolicy（抛异常）或DiscardPolicy（静默丢弃），它们掩盖问题而非缓解
监控和诊断 CachedThreadPool 行为的关键指标
如果已有代码在用 CachedThreadPool，上线前必须补监控，否则问题爆发时无法定位。
- 线程数：通过
executor.getActiveCount()和executor.getPoolSize()定期采集，观察是否持续攀升 - 任务排队数：虽然
SynchronousQueue不排队，但可监控executor.getTaskCount()与executor.getCompletedTaskCount()差值，反映积压趋势 - JVM 层面：用
jstack -l查看线程堆栈，确认是否存在大量WAITING on java.util.concurrent.SynchronousQueue或TIMED_WAITING (parking)
线程池不是黑盒，尤其 CachedThreadPool 这种“看起来省事实则危险”的类型——它的风险不在写法，而在缺少显式边界意识。一旦忽略最大线程数和拒绝策略，就等于把系统稳定性交给运气。
