ArrayBlockingQueue为何采用单锁实现而非双锁，双锁版本是否存在缺陷？

一、高赞回答的逻辑解释 #

你提到的高赞回答内容如下：

ArrayBlockingQueue has to avoid overwriting entries so that it needs to know where the start and the end is. A LinkedBlockQueue doesn't need to know this as it lets the GC worry about cleaning up Nodes in the queue.

这段话的核心逻辑是两种队列的底层存储差异带来的同步要求不同：

• LinkedBlockingQueue基于单向链表实现，入队仅操作尾节点，出队仅操作头节点，两类操作的操作对象天然隔离，只有队列空/满状态判断会涉及共享状态交互。节点的内存分配、回收完全由JVM GC负责，不存在旧空间复用的问题，因此可以用两把锁分别控制入队、出队操作，互不干扰。
• ArrayBlockingQueue基于定长数组实现，空间是预分配且循环复用的：入队元素写入putIndex位置后下标自增，到数组末尾则回绕到0；出队从takeIndex位置取元素后下标自增，同样支持回绕。为了避免新写入的元素覆盖还未被取出的旧元素，必须准确感知队列当前的元素总数、头尾下标位置，这部分共享状态的同步如果用双锁实现会引入额外的复杂度。

二、双锁版ArrayBlockingQueue的常见缺陷 #

常规吞吐量测试很难覆盖到隐性问题，这类自行实现的版本普遍存在以下问题：

1. 元素可见性问题
   Java中数组的volatile修饰仅作用于数组引用本身，不会对数组内部元素的可见性生效。入队线程持有putLock写入数组元素的操作，和出队线程持有takeLock读取数组元素的操作之间没有天然的happens-before关系，高并发场景下可能出现出队线程读到null或旧值的问题。如果改用AtomicReferenceArray存储元素来保证可见性，会额外增加元素读写的开销，抵消双锁带来的吞吐量收益。
2. 条件唤醒的锁开销
   Condition对象和锁是绑定的，入队操作完成后要唤醒等待出队的线程，必须先获取takeLock才能调用notEmpty条件的唤醒方法；同理出队完成后要唤醒入队线程也需要额外获取putLock。这部分跨锁的唤醒操作会带来额外的锁竞争开销。
3. 批量操作、迭代器实现复杂度陡增
   ArrayBlockingQueue官方实现支持drainTo、clear、remove(Object)、迭代器遍历等功能，这类操作需要同时读取/修改整个数组的内容，双锁实现下必须同时持有两把锁才能保证操作的原子性，不仅容易出现锁顺序颠倒导致的死锁问题，操作性能也会比单锁实现差很多。
4. 公平锁实现复杂
   官方版本支持公平锁模式，保证等待线程按FIFO顺序获取锁。双锁实现下要同时保证入队、出队操作的公平性，还要避免两类操作的线程互相饥饿，实现难度和维护成本都会大幅上升。

三、官方不采用双锁实现的原因 #

1. 投入产出比低
   JVM的锁优化已经非常成熟，偏向锁、轻量级锁的开销极低，大多数业务场景下单锁实现的性能已经足够，双锁带来的吞吐量提升感知非常有限，反而要承担更高的实现复杂度、更多的隐性bug风险。
2. 设计定位匹配
   ArrayBlockingQueue的设计定位是内存占用稳定、延迟可控的阻塞队列，单锁实现逻辑简单，可预测性更强，更贴合它的设计目标。
3. 兼容性风险
   ArrayBlockingQueue从JDK1.5版本开始就已经是单锁实现，很多上层依赖的代码已经适配了它的线程安全模型，修改为双锁实现会引入不可预测的兼容性问题。

内容的提问来源于stack exchange，提问作者zysaaa