ArrayBlockingQueue 的并发控制依赖 ReentrantLock 和 Condition，而非 Object 的 wait()/notify()；它通过 notEmpty 和 notFull 两个条件队列实现精准唤醒，支持中断、超时等高级特性，避免了内置锁的局限性。
Object 类本身不直接参与 ArrayBlockingQueue 的并发控制，真正起作用的是 ArrayBlockingQueue 内部封装的 ReentrantLock 和 Condition，而非 Object 的 wait()/notify() 机制。Java 中的 ArrayBlockingQueue 是基于显式锁（AQS）实现的线程安全队列，它 不依赖 Object 的内置锁 来协调生产者与消费者。
ArrayBlockingQueue 并发控制的真实机制
ArrayBlockingQueue 使用一个可重入锁（final ReentrantLock lock = new ReentrantLock();）和两个 Condition 对象：
-
notEmpty：供消费者等待——当队列为空时阻塞，非空时被唤醒 -
notFull：供生产者等待——当队列满时阻塞，未满时被唤醒
所有操作（如 put()、take()）都先获取该 ReentrantLock，再根据条件调用 await() 或 signal()，完全绕过了 Object 的 wait/notify。
为什么不用 Object 内置锁？
Object 的 wait()/notify() 存在明显局限：
立即学习“Java免费学习笔记（深入）”；
- 无法精准唤醒特定等待组（比如只唤醒消费者，不误唤醒生产者）
- 必须配合 synchronized 使用，粒度粗、灵活性低
- 无法支持公平锁、中断响应、超时等待等高级特性
- 条件判断易出错（需配合 while 循环 + 虚假唤醒处理）
而 ReentrantLock + Condition 天然支持多等待队列、可中断、可超时、可轮询，更适合复杂协作场景。
如果硬要用 Object 锁模拟，会怎样？
你可以手动用 synchronized + wait/notify 实现简易版生产者-消费者，但要注意：
- 必须用同一个锁对象（如 queue 自身或 shared monitor）
-
wait()前必须用 while 检查条件（不能用 if），防止虚假唤醒 - 每次 notify 应尽量对应明确角色（如 notifyAll() 更稳妥，避免信号丢失）
- 无法像 ArrayBlockingQueue 那样支持超时 put/take、中断响应等特性
例如：不推荐但可理解的示意
synchronized (queue) {
while (queue.size() == capacity) {
queue.wait(); // 生产者等待
}
queue.add(item);
queue.notifyAll(); // 唤醒可能等待的消费者
}
实际开发中该怎么做？
直接使用 ArrayBlockingQueue 提供的线程安全方法即可：
- 生产者调用
put()（阻塞直到有空间）或offer(e, timeout, unit)（带超时） - 消费者调用
take()（阻塞直到有元素）或poll(timeout, unit) - 内部锁和条件变量已由 JDK 封装好，无需手动干预
- 若需定制逻辑（如统计、日志），可继承并重写
offer()/poll()，但不要碰底层锁
它的设计目标就是开箱即用，把并发细节完全封装起来。
