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