ArrayBlockingQueue通过一个ReentrantLock配对两个Condition（notEmpty和notFull）实现单锁双条件机制：notEmpty用于消费者等待非空，notFull用于生产者等待未满，二者共享同一锁但维护独立等待队列，确保精准唤醒、避免虚假唤醒，且必须用while循环配合await以保障线程安全。
ArrayBlockingQueue 的 lock 和两个 Condition 是怎么配对的
单锁双条件的核心在于：一个 ReentrantLock 实例搭配两个独立的 Condition 对象，分别对应「队列非空」和「队列未满」两种等待场景。不是靠 if 判断轮询，而是用 notEmpty.await() 让消费者线程挂起在自己的条件队列上，生产者调用 notEmpty.signal() 时只唤醒等在这个条件上的消费者——互不干扰。
关键点是：notEmpty 和 notFull 都由同一个 lock 创建，但各自维护独立的等待队列。这避免了 synchronized + wait/notify 的“notify 随机唤醒”问题，也比用两个锁更轻量、无死锁风险。
常见错误现象：
– 手动 new Condition() —— 不行，必须用 lock.newCondition()
– 在没 hold 住 lock 时调用 await() —— 抛 IllegalMonitorStateException
– signal() 后没 unlock() —— 其他线程永远拿不到锁
put() 和 take() 中的 await/signal 时机为什么不能颠倒
顺序错乱会导致虚假唤醒或永久阻塞。比如在 put() 中，必须先 if (count == items.length) notFull.await();，再执行入队和 notEmpty.signal()；反过来（先 signal 再 await）就可能唤醒一个还没开始等的消费者，而当前线程却卡在满状态里。
真实场景中，这个顺序保障了「唤醒即有效」：只有当新元素真正入队后，才通知消费者可以取；同理，take() 中必须先判空、await，取完再 notFull.signal()，否则可能唤醒生产者往已满队列写数据。
参数差异体现在：await() 是释放锁并挂起；signal() 不释放锁，只是把等待线程从 condition queue 移到 sync queue；最终唤醒依赖下一次 lock 竞争。
为什么不用 while 循环包裹 await 就会出错
Condition 的 await() 可能被虚假唤醒（spurious wakeup），也可能被其他线程 signal 后又快速消费掉元素——所以必须用 while (count == 0) notEmpty.await(); 而不是 if。JDK 源码里全是 while，不是疏忽。
容易踩的坑：
– 用 if 导致取到 null 或 ArrayIndexOutOfBoundsException
– 忘记在 await 前加锁检查条件（比如没 lock 就直接 await）
– 在多核 CPU 上，没有 while 的代码可能在测试时偶现，上线后高频失败
性能影响不大：每次 await 前的 while 判定是内存读，开销可忽略；但少了它，正确性直接崩塌。
ArrayBlockingQueue 的容量固定带来哪些隐含约束
固定容量意味着 notFull 条件只在 count 时为 true。这简化了条件判断逻辑，但也决定了它不适合流式、不可预估长度的场景——比如日志缓冲区若突发流量打满，后续生产者只能阻塞或丢弃。
兼容性注意点：
– 构造时传 0 容量会抛 IllegalArgumentException
– remainingCapacity() 返回的是静态差值，不反映当前是否真能插入（得看实际 count）
– 迭代器遍历是弱一致性的，不加锁也能读，但可能看不到刚 put 的元素
真正复杂的是中断处理：如果线程在 await 时被 interrupt，会抛 InterruptedException 并自动清理等待节点——这点比自己手写 wait/notify 稳定得多，但要求所有上层调用必须正确传播异常，否则 silent fail。
