CachedThreadPool 是按需创建、自动回收的线程租赁系统，核心参数为 corePoolSize=0、maximumPoolSize=Integer.MAX_VALUE、keepAliveTime=60秒、SynchronousQueue，适用于高并发短任务，但易引发资源失控。
CachedThreadPool 不是“池”，而是一个按需创建、自动回收的线程租赁系统。它不预占资源，也不限制上限，核心逻辑是：有任务就开线程，没任务就退租，60秒空闲即销毁。这种设计完全服务于高并发、短生命周期任务场景，但用错地方反而容易引发资源失控。
参数配置决定行为本质
它等价于以下 ThreadPoolExecutor 构造调用：
- corePoolSize = 0：初始不保留任何常驻线程，连“底座”都不设
- maximumPoolSize = Integer.MAX_VALUE：理论无上限，靠系统资源兜底（实际受限于JVM线程数和OS限制）
- keepAliveTime = 60L, TimeUnit.SECONDS：非核心线程空闲满60秒即终止
- workQueue = new SynchronousQueue<Runnable>()：不缓存任务，只做“一手交接”——没有空闲线程，就立刻新建；有空闲线程，就直接交过去
执行流程：三步判断，零排队
每次 submit/execute 一个任务时，线程池内部按顺序执行以下判断：
- 是否有空闲线程？有 → 直接交任务执行（复用）
- 没有空闲线程，但当前线程数
- 当前线程数已达 max（极罕见）→ 触发拒绝策略（默认 AbortPolicy，抛 RejectedExecutionException）
注意：它跳过了“入队等待”这一步。SynchronousQueue 的特性决定了任务永远不会在队列中堆积，所以不会出现“任务排队等线程”的情况——要么马上执行，要么马上扩容。
立即学习“Java免费学习笔记（深入）”；
适用与慎用场景
适合：大量突发性、毫秒级完成的异步任务，如 RPC 客户端调用、事件通知、轻量计算回调。
慎用：
- 任务执行时间较长（>1s）：线程长期占用，60秒后才回收，易导致线程数持续高位，OOM 风险上升
- 任务量稳定且持续较高：线程反复创建销毁带来额外 GC 和上下文切换开销，不如 FixedThreadPool 稳定
- 资源受控环境（如容器、Serverless）：无法约束最大线程数，可能被平台强制 kill
真实问题排查线索
线上若发现 CachedThreadPool 表现异常，可重点关注：
- 线程名是否大量为
pool-X-thread-Y且 Y 持续增长？说明扩容频繁，任务未及时释放 - JVM 线程数是否接近 OS 限制（如 Linux 默认 1024）？可用
jstack -l <pid> | wc -l快速估算 - 是否存在未 shutdown 的 cachedPool 导致 JVM 无法退出？务必在使用完毕后调用
shutdown()或shutdownNow()
