ArrayBlockingQueue和LinkedBlockingQueue最稳妥，但ArrayBlockingQueue有界、基于数组、适合内存敏感场景，LinkedBlockingQueue默认伪无界、双锁并行、适合消费稳定场景；务必避免PriorityBlockingQueue用于生产者消费者模式。
BlockingQueue 选哪个实现类才不踩坑
直接说结论：ArrayBlockingQueue 和 LinkedBlockingQueue 是最常用、最稳妥的两个，但它们行为差异很大，选错会导致吞吐量骤降或线程卡死。
常见错误现象：用 LinkedBlockingQueue 默认构造（无参），结果生产者疯狂塞数据，消费者处理不过来，队列内存暴涨甚至 OOM；或者反过来，用 ArrayBlockingQueue 配了太小的容量，频繁阻塞，吞吐上不去。
-
ArrayBlockingQueue：有界、基于数组、线程安全、公平锁可选。适合对内存敏感、能预估峰值流量的场景 -
LinkedBlockingQueue：默认无界（Integer.MAX_VALUE），实际是“伪无界”——节点对象本身占堆内存。适合消费速率相对稳定、不想因容量限制过早阻塞的场景 - 别碰
PriorityBlockingQueue做生产者消费者——它不保证 FIFO，消费者拿到的顺序和插入顺序不一致，业务逻辑容易错乱
offer()、put()、add() 到底该调谁
这三个方法看着像，但阻塞行为和异常策略完全不同，混用会埋下超时无感知、线程假死等隐患。
-
add(e)：队列满时直接抛IllegalStateException，不适合生产环境——你得自己 catch 异常再重试或降级，太糙 -
offer(e)：非阻塞，满时返回false，适合做快速失败或带退避的重试逻辑 -
put(e)：阻塞直到有空间，适合生产者必须投递成功的场景；但要注意：如果消费者长期卡住，生产者线程会被永久挂起 - 消费者侧同理：
poll()（非阻塞）、take()（阻塞）、remove()（不推荐，可能抛NoSuchElementException）
用 take() + interrupt() 实现优雅关闭
很多代码直接在循环里写 while (!Thread.interrupted()) { queue.take(); ... }，看似没问题，其实关不掉——take() 被中断后抛 InterruptedException，但没清空中断状态，下次循环又进 take()，继续阻塞。
- 正确做法：捕获
InterruptedException后立即Thread.currentThread().interrupt()恢复中断标记 - 关闭时调用
thread.interrupt()，消费者线程就能在下一次take()时跳出循环 - 别依赖
queue.isEmpty()判断退出——它不反映正在被take()的线程是否已唤醒，可能漏数据
别让 BlockingQueue 成为性能瓶颈
BlockingQueue 本身不是银弹，高并发下锁争用、GC 压力、虚假唤醒都可能拖慢整个流水线。
-
ArrayBlockingQueue用单把锁（ReentrantLock），所有操作串行；LinkedBlockingQueue用两把锁（putLock / takeLock），生产/消费可并行，吞吐更高 - 大量短生命周期消息（比如日志）走
LinkedBlockingQueue，注意 GC：每个元素包装成 Node 对象，比ArrayBlockingQueue多一次对象分配 - 如果生产/消费速率严重不匹配，考虑加个缓冲层（如批量拉取、背压控制），而不是单纯调大队列容量
真正难的从来不是“怎么放进去”，而是“什么时候放、放多少、放完怎么收场”。队列只是容器，边界逻辑才是关键。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
