CachedThreadPool 的 SynchronousQueue 不缓存任务，而是直接移交：无空闲线程时立即创建新线程执行，不存在排队等待；换其他队列会破坏其按需伸缩与毫秒级响应特性。
看穿 CachedThreadPool 的 SynchronousQueue 底层链路，关键不在“看队列”，而在理解它根本**不排队**——任务不是存进去等执行，而是直接“移交”给空闲线程，或当场创建新线程来接招。
核心逻辑：SynchronousQueue 不是缓冲区，而是握手通道
SynchronousQueue 容量为 0，没有内部存储空间。它的 offer() 方法永远返回 false（非超时模式下），意味着“无法暂存”。所以当任务提交到 CachedThreadPool：
- 线程池先尝试把任务 直接塞给一个已空闲的工作线程（通过
take()唤醒） - 若无空闲线程，
offer()失败 → 触发addIfUnderMaximumPoolSize()→ 立即新建线程执行该任务 - 不存在“任务在队列里躺着等”的中间态；要么被线程立刻取走，要么催生新线程
移交过程的三步真实时序
以一次 submit(Runnable) 调用为例，底层实际发生的是：
- 主线程调用
execute()，进入ThreadPoolExecutor#addWorker(null, false)流程 - 先尝试
workQueue.offer(command)→ SynchronousQueue 返回false - 于是跳转至创建新线程分支：
addWorker(command, true)，新线程启动后立即执行该 command
注意：这里没有“入队→唤醒→出队→执行”的分段，而是一次原子移交判断 + 即时响应决策。
为什么不能换 ArrayBlockingQueue 或 LinkedBlockingQueue？
换其他队列会彻底破坏 CachedThreadPool 的设计意图：
- 若用
ArrayBlockingQueue(1)：单个任务入队后就卡住，后续无消费者则一直阻塞，违背“快速响应”原则 - 若用
LinkedBlockingQueue（哪怕容量 1）：任务可暂存，线程复用率下降，空闲线程可能长期闲置，而新任务却在队列中等待，失去“按需伸缩”特性 - 只有 SynchronousQueue 能保证：任务提交时刻 = 执行启动时刻（或线程创建时刻），毫秒级延迟可控
验证链路的两个轻量方法
不必读源码也能感知移交行为：
-
日志打点法：在任务 Runnable 内打印
Thread.currentThread().getName()，连续提交多个任务，会发现线程名高度分散（如 pool-1-thread-1/2/3…），说明每个任务大概率由独立线程执行，而非复用 -
延时阻塞法：启动一个线程持续
take()SynchronousQueue，再另启线程反复put()；观察输出严格交替（put1 → take1 → put2 → take2），印证“一对一即时配对”机制
