SynchronousQueue 的 size() 永远为 0 是设计使然，因其作为无缓冲通道，仅在有线程正调用 take() 时才完成任务移交，从而支撑 newCachedThreadPool“即时创建线程、绝不排队”的语义。

SynchronousQueue 的 size() 永远是 0，这不是 bug，而是它能驱动线程池“有任务就交、没线程就建”的根本前提。

为什么 newCachedThreadPool 必须配 SynchronousQueue

因为 newCachedThreadPool 的语义是：任务来了，有空闲线程立刻执行；没有，就新建线程——中间不能排队。

而 SynchronousQueue 正是唯一满足这个语义的队列：

• offer(task) 在无空闲线程等待时直接返回 false，线程池借此判断“移交失败”，立即触发 addWorker() 创建新线程
• put(task) 会阻塞，直到有线程调用 take()，这天然匹配“任务必须被某个线程当场接手”的强同步要求
• 换成 ArrayBlockingQueue 或 LinkedBlockingQueue，任务会堆积在队列里，线程数卡在核心数不动，背压悄悄吃掉内存

size() == 0 是健康信号，不是告警依据

监控看到 queue.size() 恒为 0，别急着调优或换队列——这是设计契约。

真正该查的是：

• 线程是否被 I/O、锁、GC 阻塞，导致无法及时调用 take()
• 是否有线程在 take() 后迟迟不处理任务（比如任务体里 sleep 或长循环）
• isEmpty() 总返回 true，peek() 直接抛 UnsupportedOperationException，别试图“检查队列内容”

offer() 和 put() 的语义差异决定线程池行为路径

线程池内部用的是 offer()，不是 put()。这点很关键：

• queue.offer(task) 是非阻塞的快速试探：有空闲线程在等？有就交过去，没就立刻返回 false
• queue.put(task) 是强同步移交：必须等到 take() 出现才返回，线程池不用它，否则 submit 会卡死
• 如果你自己封装逻辑误用了 put()，就会发现任务提交后线程一直挂起，直到另一个线程来 take()

真正容易被忽略的点在于：SynchronousQueue 不是“轻量版 BlockingQueue”，它是“无状态通道”。它的价值不在容量管理，而在强制线程协作时机——任务能否被接住，完全取决于那一刻有没有线程正等着 take()。任何想绕过这个协作模型的设计，都会让线程池退化成普通缓冲队列模式。