SynchronousQueue的阻塞机制实质上是一种协作式等待，而非线程错误或异常。其无容量设计要求put()与take()必须一一配对，线程通过LockSupport.park()挂起并等待唤醒，该队列适用于强实时性、反积压场景，但配置线程池参数时需要格外谨慎。
SynchronousQueue在线程池中引发的阻塞，不应被误解为线程“卡死”或故障。实际上，这是一种协作式等待——任务提交线程主动暂停，等待工作线程就绪。该队列不缓存任何任务，遵循“一手交钱一手交货”的原则：当没有消费者时，生产者必须停在put()处，直到有线程调用take()才能继续。这种阻塞机制依赖于队列内部的Lock+Condition或Unsafe.park()实现，与LockSupport.park()的挂起机制高度相关，但语义和用途需要区分对待。
SynchronousQueue的阻塞是协作式等待，并非失败信号
该队列容量为零，任何put()都必须匹配一个尚未发生的take()，反之亦然。当线程调用put()却无人take()时，它不会轮询或占用CPU，而是直接进入WAITING状态，等待被配对线程唤醒。
- 这不是异常或错误，而是设计者的有意为之：适用于任务必须立即执行、不允许排队的场景，例如高频短任务或资源敏感型服务。
- 在线程池中使用它时，如果所有核心线程都忙，且尚未达到最大线程数，线程池会尝试创建新线程；如果已达到最大线程数，且没有空闲线程，那么
execute()就会阻塞，直到有线程完成任务并准备接收下一个任务。 - 这里有一个关键点：此时拒绝策略（例如
AbortPolicy）不会触发——因为任务尚未被“拒绝”，只是“暂时未交接成功”。
底层通过LockSupport.park()实现线程挂起，但并非传统意义上的“挂起”
LockSupport.park()是JVM提供的底层线程调度原语，作用是让当前线程暂停执行、释放CPU，进入WAITING状态，直到被unpark()显式唤醒。SynchronousQueue（尤其在公平模式下）大量使用它替代Object.wait()，原因很简单：更轻量，不依赖对象监视器，唤醒时机可精确控制。
park()不释放锁，也不关联monitor，只负责线程状态切换；它由JVM调用操作系统的线程挂起机制（例如Linux的futex），属于用户态到内核态的协作。- 在SynchronousQueue中，一个线程执行
put()后调用park()等待配对，另一个线程执行take()成功后立即unpark()对应的等待者，实现点对点唤醒。 - 这与已被淘汰的
Thread.suspend()/resume()完全不同：后者是粗粒度、易死锁的强制暂停；而park()/unpark()是异步、配对、无条件的，是现代并发工具类（如AQS、LinkedBlockingQueue、SynchronousQueue）的基石。
阻塞 vs 挂起：Java层语义要分清
平时我们说的“线程阻塞”，在Java并发上下文中通常指线程因资源不可用而暂停执行的逻辑状态（例如等待锁、等待队列、等待I/O）；而“挂起”在JVM和操作系统层是具体的执行动作（即park）。二者不是并列关系，而是抽象与实现的关系。
- 阻塞是结果（线程无法推进），挂起是手段（JVM调用park让线程休眠）。
synchronized争抢锁失败时，线程也会park——这属于“被动阻塞”，由JVM自动管理；而SynchronousQueue的park是“主动协作阻塞”，由队列逻辑驱动。- 真正需要避免的是手动
suspend()：它不配合锁机制，可能在持有锁时被挂起，导致其他线程永久等待。
配置线程池使用SynchronousQueue时的关键提醒
选择SynchronousQueue不是为了追求“高性能”，而是为了强实时性与反积压。但参数配置不当，极易导致线程数失控或任务无限等待，下面几个点值得特别注意。
- corePoolSize和maximumPoolSize必须合理设置：如果两者相等，又没有空闲线程，新任务会永远阻塞；如果差值过大，又可能瞬间创建过多线程，耗尽资源。
- keepAliveTime建议设为0：SynchronousQueue不存任务，空闲线程没有存在的必要，设为0可快速回收。
- 拒绝策略基本形同虚设：除非显式调用
offer()（非阻塞提交），否则execute()和submit()都会阻塞，根本走不到拒绝逻辑那里去。
