核心线程数设为0并非错误，而是“按需启动、零常驻”策略：任务直接入队（不启线程），仅当队列拒绝时才创建临时线程；必须配SynchronousQueue才能即时响应，禁用无界队列以防任务积压不执行。
核心线程数设为 0 并非错误配置，而是一种明确的“按需启动、零常驻”策略。它让线程池退化为纯调度协调器，所有执行线程均为临时线程，生命周期完全由任务流量与队列行为驱动。理解它，关键不在“能不能用”，而在“什么时候该用、怎么配才不翻车”。
核心线程数为 0 的真实行为逻辑
这不是“不创建线程”，而是“不保留任何常驻线程”。线程是否创建，取决于 队列能否立即接收任务：
- 若队列能立刻入队（如无界队列或有界但未满）→ 任务进队，不创建线程，此时池中线程数 = 0
- 若队列拒绝入队（如 SynchronousQueue.offer() 返回 false，或有界队列已满）→ 立即尝试创建非核心线程执行
- 若线程数已达 maximumPoolSize → 触发拒绝策略
注意：即使 corePoolSize=0，只要满足创建条件，线程池仍会新建线程——它只是跳过了“先建核心线程”的环节，直接走“队列失败→建临时线程”路径。
必须搭配 SynchronousQueue 才能真正“即时响应”
这是最典型且安全的 corePoolSize=0 实战组合。SynchronousQueue 不存储任务，每次 offer() 都需配对的 take()，本质是线程间直接移交任务。
- 提交任务时，若无空闲线程 → 立即创建新线程执行（不排队）
- 线程执行完任务后空闲，超过 keepAliveTime 自动销毁
- 结果：线程数 ≈ 当前并发任务数，伸缩性极强，资源占用随负载实时变化
示例配置：new ThreadPoolExecutor(0, 8, 60, TimeUnit.SECONDS, new SynchronousQueue()) —— 适合短时、突发、低频 HTTP 请求或事件回调。
用有界队列时要警惕“假死”与“延迟爆发”
比如 ArrayBlockingQueue(5) + corePoolSize=0：
- 前 5 个任务全部入队，池中仍无任何线程 → 任务“静默积压”，不执行
- 第 6 个任务到来 → 队列满 → 创建第 1 个临时线程执行它
- 该线程执行完后若空闲超时，被回收；后续任务继续排队或触发新线程
问题在于：你无法预测任务何时开始执行。低吞吐下看似省资源，高并发初段却可能因“等满队列才启线程”造成明显延迟。需配合监控 activeCount 和 queue.size 判断是否卡在“排队不执行”状态。
绝对避免搭配无界队列（如 LinkedBlockingQueue 默认构造）
这是最危险的误用：
- corePoolSize=0 + 无界队列 → 任务永远成功入队，never 触发线程创建
- 线程池保持 poolSize=0，所有任务堆积在内存中，永不执行
- 最终 OOM，且无任何异常抛出，极难排查
哪怕用了 new LinkedBlockingQueue(Integer.MAX_VALUE)，也属于逻辑上的无界行为，同样踩坑。真要用有界队列，容量必须显式指定且合理（如 100–1000），并确保业务能接受排队等待。
