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()。任何想绕过这个协作模型的设计，都会让线程池退化成普通缓冲队列模式。
