BlockingQueue 是 Java 并发中实现线程协作的核心工具，通过 ReentrantLock 与 Condition 实现自动挂起与精确唤醒；其类型选择（Array、Linked、Synchronous、Delay）直接影响协作效率与系统稳定性，并深度耦合线程池调度策略，需避免混用阻塞/非阻塞方法、无界队列 OOM 及不当启用公平模式等陷阱。
BlockingQueue 是 Java 并发编程中实现线程协作的核心工具，它通过“自动挂起 + 条件唤醒”的机制，让生产者和消费者无需手动加锁、轮询或 wait/notify 就能安全高效地交换数据。
阻塞行为如何触发
BlockingQueue 的关键在于“条件不满足即阻塞”，不是忙等，也不是抛异常：
- 调用 put(e) 时，若队列已满，当前线程会被挂起，进入
notFull条件队列，直到有其他线程调用take()腾出空间并发出 signal - 调用 take() 时，若队列为空，当前线程被挂起，进入
notEmpty条件队列，等待有线程执行put()后唤醒 - 这种挂起由
ReentrantLock配合Condition实现，完全由 JDK 底层保障原子性与唤醒精确性
不同实现类的协作特点
选对 BlockingQueue 类型，直接影响线程协作效率和系统稳定性：
- ArrayBlockingQueue：固定容量、基于循环数组，单锁 + 两个 Condition，适合对吞吐量要求不高但需强可控性的场景（如银行交易队列）
- LinkedBlockingQueue：默认无界（Integer.MAX_VALUE），内部使用两把锁（putLock/takeLock），读写可并发，适合高吞吐、低延迟的生产消费模型
-
SynchronousQueue：不存储元素，
put()必须等待另一个线程同时执行take()，本质是线程间直接 handoff，适合任务分发、零缓冲调度 -
DelayQueue：仅允许到期元素被
take()，内部用堆维护时间顺序，常用于定时任务、缓存过期清理
与线程池的深度绑定
ThreadPoolExecutor 不是简单“用队列存任务”，而是将 BlockingQueue 作为调度策略的中枢：
- 新任务提交后，优先尝试交给空闲核心线程；失败则调用
workQueue.offer()入队 - 若入队失败（如 ArrayBlockingQueue 满），才触发扩容逻辑：新建非核心线程（≤ maximumPoolSize）
- 若队列仍满且线程数已达上限，则交由
RejectedExecutionHandler处理——这意味着队列容量直接决定线程池是否扩容、何时拒绝 - 因此，队列不是被动容器，而是流量调控开关：小容量队列倾向快速扩容+早拒绝；大/无界队列倾向压任务、少建线程、但可能掩盖背压问题
避免常见协作陷阱
看似简单，实际易踩坑：
- 不要混用阻塞方法与非阻塞方法（如一边用
put()，一边用poll()），会导致一方永远等待、另一方空转 - 无界队列（如默认 LinkedBlockingQueue）在持续高负载下可能引发 OOM，务必结合监控与限流使用
- 公平模式（
fair = true）虽保证等待顺序，但会显著降低吞吐，仅在严格 FIFO 语义不可妥协时启用 - 所有元素插入前都会校验是否为 null，传入 null 会立即抛
NullPointerException，不是静默失败
