BlockingQueue线程安全但非万能，仅保障单操作原子性；ArrayBlockingQueue有界数组+单锁，LinkedBlockingQueue无界链表+双锁；禁插null，需权衡阻塞与背压策略。
BlockingQueue 是线程安全的，但不是“开箱即用”的万能队列
直接使用 BlockingQueue 接口的实现类（如 ArrayBlockingQueue、LinkedBlockingQueue）本身是线程安全的——所有核心操作（put()、take()、offer()、poll()）都已加锁或基于 CAS 实现。但「线程安全」仅保证单个操作原子性，不等于业务逻辑自动线程安全。比如多个线程协作完成“先检查再入队”这种复合操作时，仍需额外同步。
选对实现类：ArrayBlockingQueue 和 LinkedBlockingQueue 的关键区别
二者都实现了 BlockingQueue，但底层机制和适用场景差异明显：
-
ArrayBlockingQueue是有界、基于数组、**公平锁可选**（构造时传true），内存占用固定，适合对资源消耗敏感且容量可控的场景 -
LinkedBlockingQueue默认无界（实际是Integer.MAX_VALUE），基于链表，**吞吐量通常更高**，但可能掩盖生产过快导致的 OOM 风险 - 两者在高并发下性能表现不同：
ArrayBlockingQueue使用单一把锁保护整个队列；LinkedBlockingQueue用两把锁（takeLock和putLock）分离读写，减少争用
阻塞 vs 非阻塞方法：别在循环里无脑调用 take()
take() 和 put(E) 是阻塞方法，线程会在队列空/满时挂起，直到条件满足。但若配合超时或轮询使用不当，容易写出低效甚至死锁倾向的代码：
- 避免在 while 循环中反复调用
take()而不处理中断 —— 它会响应Thread.interrupted()，但若忽略返回值或未声明InterruptedException，会导致线程无法被优雅终止 - 慎用
poll(long, TimeUnit)+ 空循环重试：它可能频繁唤醒线程又立即休眠，浪费 CPU - 更推荐方式是让消费者线程长期存活，靠
take()自然阻塞等待，或用drainTo(Collection)批量消费，减少锁竞争
while (!Thread.currentThread().isInterrupted()) {
try {
String task = queue.take(); // 阻塞直到有元素
process(task);
} catch (InterruptedException e) {
Thread.currentThread().interrupt(); // 恢复中断状态
break;
}
}
注意 null 元素限制和容量边界行为
所有 BlockingQueue 实现均**禁止插入 null 元素**，否则抛 NullPointerException。这点常被忽略，尤其在从 Map 或数据库取值后直传入队时。
立即学习“Java免费学习笔记（深入）”；
容量边界行为也需明确：
-
offer(E)在队列满时返回false，不阻塞也不抛异常 -
add(E)在队列满时抛IllegalStateException（继承自Collection接口，不推荐用于 BlockingQueue 场景） -
put(E)在队列满时阻塞，直到有空间 —— 若生产者速度远高于消费者，可能导致大量线程挂起，拖垮系统响应
真正难处理的，往往是「阻塞语义」和「背压策略」之间的权衡：是让生产者等，还是丢弃、拒绝、降级？这不在 BlockingQueue 职责内，得由上层决定。
