用BlockingQueue而非手写synchronized队列，因其已封装锁、条件变量、中断响应与超时处理，避免虚假唤醒、notify误用等边界错误；ArrayBlockingQueue适合容量确定场景，LinkedBlockingQueue双锁并发更高但需防无界OOM。
为什么用 BlockingQueue 而不是自己 synchronized 加锁？
因为手写线程安全队列极易漏掉「等待-唤醒」的边界条件，比如忘记在 wait() 前加 while 循环判断，导致虚假唤醒后直接出错；或者 notify 用错对象，造成线程永远挂起。
而 BlockingQueue 接口的所有实现（如 ArrayBlockingQueue、LinkedBlockingQueue）已把锁、条件变量、中断响应、超时处理全封装好了——你只管调 put() 和 take()，不用碰 ReentrantLock 或 Condition。
- 错误写法：
if (queue.isEmpty()) wait();→ 应该是while (queue.isEmpty()) wait(); - 正确姿势：直接用
queue.take()，它内部已做 while + 中断检查 + 条件唤醒 - 性能影响：自己写锁容易全局串行化；
LinkedBlockingQueue用双锁（putLock/takeLock），生产/消费可并行
ArrayBlockingQueue 和 LinkedBlockingQueue 怎么选？
关键看是否需要容量硬限制 + 是否在意内存碎片与 GC 压力。
-
ArrayBlockingQueue：构造时必须指定固定大小，底层是循环数组，内存连续，GC 友好；但所有操作共用一把ReentrantLock，高并发下吞吐略低 -
LinkedBlockingQueue：默认无界（慎用！），有参构造可设容量；底层链表节点动态分配，存在小对象 GC 开销；但生产/消费分离双锁，吞吐更高 - 常见误用：
new LinkedBlockingQueue()（无参）→ 实际是无界队列，OOM 风险极高；应显式传容量，如new LinkedBlockingQueue(1024) - 场景建议：消息中间件缓冲、秒杀限流 → 选
ArrayBlockingQueue（容量确定 + 稳定）；后台异步日志、事件分发 → 选带界的LinkedBlockingQueue
put() vs offer() vs add()：别在生产环境混用
三者行为差异直接影响系统健壮性，尤其在满队列或空队列场景下。
-
add(e)：队列满时抛IllegalStateException→ 生产代码中几乎不用，无法优雅降级 -
offer(e)：队列满时返回false→ 适合非阻塞逻辑，但你要自己处理失败分支（比如丢弃、告警、重试） -
put(e)：队列满时阻塞，直到有空间 → 生产者节奏可控时首选，但注意：若消费者长期卡住，生产者会永久挂起 - 同理，
take()（阻塞取）、poll()（立即取，空则 null）、remove()（空则抛异常）也需按需选用
用 SynchronousQueue 实现“一手交钱一手交货”要注意什么？
它不存数据，每个 put() 必须等一个配对的 take()，反之亦然。本质是线程间直接 handoff，不是缓冲。
- 典型场景：线程池的
DirectHandoff模式（如Executors.newCachedThreadPool()内部就用它） - 危险点：
put()调用方若没配对消费者，会无限阻塞；且不能用size()判断状态（始终为 0） - 调试线索：线程 dump 中看到大量
WAITING on java.util.concurrent.SynchronousQueue$TransferStack→ 基本就是某端没跟上 - 替代方案：真要解耦又不想存数据，考虑
TransferQueue子类或明确用CompletableFuture传递结果
真正难的从来不是选哪个类，而是想清楚「谁该等谁」「等多久」「等不到怎么办」——这些决策藏在 put/take 和 offer/poll 的语义里，而不是文档的 API 列表中。
