corepoolsize设为0时线程池仍会工作，但首个线程需任务入队后二次检查workercount为0才启动，导致延迟；不同队列（如linkedblockingqueue vs synchronousqueue）冷启动表现差异大，且无法通过setcorepoolsize(0)预热。
线程池的 corePoolSize 设为 0 并不等于“不干活”，而是把线程创建完全交给运行时状态驱动——但这个机制在低频或首次提交任务时，容易因队列行为和隐式启动时机错配，造成可感知的延迟。真正的问题不在“不启线程”，而在于“何时启、启几个、谁来消费”。
关键原因：首个线程不是提交即启，而是入队后二次检查才触发
很多人误以为 corePoolSize = 0 就会像 newCachedThreadPool 那样“有任务就建线程”。其实不然。JDK 1.6+ 的 execute() 流程中，任务先尝试入队；入队成功后，会**再次检查当前 workerCount 是否为 0**——只有这时才调用 addWorker(null, false) 启动第一个非核心线程。
这个“二次检查”环节看似微小，却带来两个实际影响：
- 如果任务入队耗时略高（比如自定义队列、锁竞争、GC 暂停），线程启动就被延后
- 该线程的
firstTask是null，它不会直接执行刚提交的任务，而是启动后去take()队列——中间存在一次上下文切换和阻塞等待
队列类型决定“冷启动”是否真的冷
同一个 corePoolSize = 0，换不同队列，冷启动表现天差地别：
- LinkedBlockingQueue（无界）：offer 几乎总成功 → 首个任务入队 → 触发隐式启动 → 线程很快开始消费 → 延迟轻微（通常
- ArrayBlockingQueue（有界，如容量 5）：前 5 个任务全部静默入队，池中仍为 0 线程 → 第 6 个任务到来，队列满 → 才触发线程创建 → 此时前面 5 个任务已在队列中等待，新线程启动后才逐个 take → 初期延迟可能达数十到数百毫秒
- SynchronousQueue：offer 总失败 → 完全跳过队列 → 每个任务都走 addWorker 分支 → 表现接近“热启动”，但频繁创建销毁线程带来开销
keepAliveTime + 空闲回收加剧间歇性延迟
当 corePoolSize = 0 时，所有线程都是非核心线程，keepAliveTime 严格生效：
- 一个线程执行完任务后进入空闲状态
- 若在
keepAliveTime内没等到新任务，它就被回收，workerCount回到 0 - 下一次任务来，又得重复“入队 → 检查为 0 → 启线程 → take → 执行”的完整链路
在请求间隔略大于 keepAliveTime 的场景（例如每 65 秒来一个任务，而 keepAliveTime=60s），就会反复经历冷启动——看似低频省资源，实则每次都有明显首任务延迟。
prestartAllCoreThreads() 对 corePoolSize=0 完全无效
有人想用 prestartAllCoreThreads() 提前“暖机”，但该方法只对 corePoolSize > 0 生效。若设为 0，调用后返回 0，什么也不会发生。这意味着你无法通过标准 API 主动预热——只能依赖任务自然触发，或自行调用 prestartCoreThread()（它不依赖 corePoolSize，但需确保线程池处于 RUNNING 状态）。
