ArrayBlockingQueue的单锁（ReentrantLock）锁住整个队列状态，包括items数组、putIndex、takeIndex、count及阻塞唤醒逻辑，put和take无法并发执行，这是循环数组结构下保障原子性的必然设计。
ArrayBlockingQueue 的单锁（ReentrantLock）到底锁住了什么
它锁住的是整个队列的全部状态：items 数组、putIndex、takeIndex、count，以及所有阻塞/唤醒逻辑。也就是说，put() 和 take() 不能并发执行——哪怕一个在头、一个在尾，也必须排队抢同一把锁。
这不是设计疏漏，而是循环数组结构的必然约束：两个指针共享同一块内存区域，任何修改都需原子性保障。所以你看到的“高并发写入易卡住”，本质是生产者线程在 notFull.await() 唤醒后，仍要和刚被 notEmpty.signal() 唤醒的消费者争锁。
- 公平锁（
fair = true）会让争锁更可预测，但吞吐量进一步下降；非公平锁默认启用，允许插队，反而在中低负载下表现更好 -
offer()和poll()这类非阻塞方法同样走同一把锁，只是不 await 而已，争锁开销没减少 - 即使队列空或满，
lock.lock()仍会先获取锁再判断条件，存在“先抢锁再发现无事可做”的浪费
什么时候单锁会成为明显瓶颈
典型信号是：监控显示线程大量阻塞在 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await() 或反复进出 ReentrantLock.lockInterruptibly()，同时 CPU 利用率不高、吞吐却上不去。
这往往出现在以下组合场景：
- 生产者线程数 ≥ 4，且持续以接近吞吐上限的速率
put()（比如日志收集、批量消息入队） - 消费者处理速度波动大，导致队列频繁触达
capacity边界，notFull和notEmpty条件频繁切换 - 队列容量设得偏小（如
new ArrayBlockingQueue(16)），加剧了满/空状态切换频率
此时你看到的不是锁本身慢，而是大量线程在锁门口排队 + 条件等待 + 唤醒调度的叠加延迟。
对比 LinkedBlockingQueue 的双锁设计，差在哪
LinkedBlockingQueue 对头（take）和对尾（put）分别用两把锁：takeLock 和 putLock。这意味着只要队列非空且非满，生产和消费就能真正并行——一个改 head，一个改 tail，互不干扰。
但要注意这个优势有前提：
- 仅当队列容量远大于线程数、且读写比例较均衡时，双锁才能摊薄锁竞争
- 链表节点分配带来额外 GC 压力，小对象高频创建时可能反超数组的内存局部性优势
- 无界模式（
new LinkedBlockingQueue()）下，putLock仍需保护count更新，部分场景锁粒度并未完全解耦
所以不是“双锁一定更快”，而是它把性能拐点往更高并发推了一段距离；而 ArrayBlockingQueue 的单锁边界更早、更陡峭，容易暴露。
实际调优时别只盯着锁，先看容量与节奏匹配度
很多人一遇到吞吐卡顿就换队列实现，但真正拖慢 ArrayBlockingQueue 的，往往是容量和业务节奏不匹配：
- 队列太小（如 8～32）：一次突发流量就打满，后续所有
put()都得等消费者清出空间 + 抢到锁 → 延迟毛刺明显 - 队列太大（如 > 1024）：缓存行失效加剧，
putIndex/takeIndex跳转跨度大，CPU 预取效率下降；且满/空判断虽快，但条件变量 signal 唤醒的线程可能立刻又因锁失败而挂起 - 生产/消费速率长期严重失衡：比如消费者每秒处理 100 条，生产者稳定 200 条/秒，那无论锁多快，队列都会快速堆满 → 此时问题不在锁，而在背压策略缺失
单锁设计的代价清晰可见，但它换来了内存确定性、GC 友好、以及极简的边界控制逻辑。真正该警惕的，是把它用在本该由背压、限流、或异步批处理承接的场景里。
