synchronousqueue.offer()返回false是正常契约而非bug，表明无空闲线程接收任务，触发线程池扩容；其size()恒为0是设计使然，反映无缓冲语义。

SynchronousQueue.offer() 返回 false 就该扩容，不是 bug 是契约

当你看到 queue.offer(task) 立即返回 false，别急着加日志或改队列——这是 SynchronousQueue 正常工作的信号。它不缓存任务，offer() 成功的前提是「此刻恰好有空闲线程在调用 take()」；否则立刻失败，触发线程池的 addWorker() 流程。这正是 CachedThreadPool 能在高并发下秒级扩容的核心机制。

• corePoolSize == 0 时，所有任务都走 offer() → 失败 → 新建线程路径
• 若误配成 LinkedBlockingQueue，任务全堆积在队列里，poolSize 永远卡在 corePoolSize，根本不会扩容
• offer() 不阻塞、不重试、不抛异常，返回 false 是控制流分支，必须被 execute() 内部逻辑捕获并响应

为什么 size() 永远是 0？这不是监控失灵，是设计使然

SynchronousQueue.size() 恒为 0，isEmpty() 恒为 true。这不是实现缺陷，而是“无存储”语义的直接体现。你在 Prometheus 里看到 thread_pool_queue_size{pool="cached"} == 0，说明它工作正常；一旦非零，反而意味着你用错了队列类型，或者有线程卡死没调用 take()。

• 监控中持续看到 queue.size() > 0，大概率是消费者线程阻塞、崩溃或未启动
• 不要用 size() 判断负载，它毫无意义；应关注 pool.getActiveCount() 和拒绝率
• 日志里打印 queue.size() 做 debug 是无效动作，只会干扰判断

put() 和 offer() 的语义差异决定你是阻塞等待还是快速失败

同一个 SynchronousQueue，put() 和 offer() 行为完全不同：put() 会无限期阻塞直到有线程 take()；offer() 则只尝试一次，无人接招就立刻返回 false。线程池内部用的是 offer()，因为它需要把“移交失败”转化为“新建线程”的决策依据。

• 手写生产者-消费者时，若想强制同步移交（比如支付请求必须被处理线程当场接住），才用 put()
• 若用 put() 替代 offer() 在线程池提交路径中，会导致任务提交线程被卡死，整个池不可用
• 公平模式（new SynchronousQueue(true)）仅影响等待线程的唤醒顺序，不改变 offer() 的失败行为

真正容易被忽略的是：SynchronousQueue 的“快”不来自性能，而来自它把线程调度决策权完全交给了线程池的 execute() 逻辑——它不做任何缓冲，也不隐藏背压，任务来了不是排队，而是立刻回答“谁来接？”或“要不要生一个？”。这个简单到极致的契约，恰恰是应对突发流量最可靠的杠杆。