ArrayBlockingQueue单锁在高并发下成瓶颈，因其put/take共用同一ReentrantLock，导致生产者与消费者线程必须串行争锁，无法读写分离，锁粒度粗、上下文切换多，实测16线程时锁等待超30%。
ArrayBlockingQueue 的单锁为什么在高并发下成瓶颈
因为所有入队 put 和出队 take 操作都必须竞争同一把 ReentrantLock，哪怕生产者和消费者完全不共享数据（比如一个在疯狂塞、一个在稳定取），也得排队抢锁。这跟数据库里所有读写都串行化执行是一个道理——吞吐量上不去。
实测中，当线程数超过 8 个，ArrayBlockingQueue 的平均响应延迟开始明显抬升；到 16 线程时，锁等待时间占比常超 30%，CPU 利用率却卡在 60% 左右，说明大量时间花在上下文切换和锁争用上，而不是实际干活。
- 锁粒度太粗：数组本身是连续内存，但
putIndex和takeIndex实际互不干扰，却共用一把锁 - 没有读写分离：消费者只读
takeIndex和items[takeIndex]，生产者只写putIndex和items[putIndex]，逻辑上可并行 - 公平锁模式下更糟：启用
fair = true后，线程按 FIFO 排队，但唤醒开销更大，反而加剧延迟毛刺
notEmpty 和 notFull 这两个 Condition 怎么配合单锁工作
notEmpty 和 notFull 是同一个 ReentrantLock 实例创建的两个独立条件变量，它们不解决锁竞争，只优化「等」的过程。
比如消费者调用 take() 时发现 count == 0，就执行 notEmpty.await() —— 此时线程释放锁、挂起，不占用 CPU；等生产者 put() 成功后，调用 notEmpty.signal() 唤醒一个等待线程。这个机制避免了忙等，但唤醒后的线程仍要重新抢锁。
- 关键点：两个
Condition共享一把锁，不能同时被不同线程持有 -
notFull.signal()不会唤醒消费者，notEmpty.signal()也不会唤醒生产者，职责严格分离 - 如果误用
signalAll()而非signal()，可能引发“惊群效应”，多个线程被唤醒后又一起抢锁，浪费资源
对比 LinkedBlockingQueue 的双锁设计，差在哪
LinkedBlockingQueue 把锁拆成 putLock 和 takeLock 两把，生产者只碰 putLock，消费者只碰 takeLock，真正实现读写分离。这是它在 16 线程下吞吐量比 ArrayBlockingQueue 高 40%+ 的根本原因。
但要注意：这种优势只在生产/消费节奏相对均衡时明显。如果全是生产者（比如突发流量涌入），putLock 依然会成为新瓶颈；同理，纯消费者场景下 takeLock 也会排队。
-
ArrayBlockingQueue的单锁 + 双Condition是“强一致性换简单性”：逻辑清晰、内存局部性好、GC 压力小 -
LinkedBlockingQueue的双锁 + 双Condition是“并发性换复杂度”：节点动态分配、链表遍历缓存不友好、长期运行 GC 更多 - 别只看吞吐量数字：如果你的队列长度固定且较小（比如流控限流用的
new ArrayBlockingQueue(100)），单锁的确定性反而更可控
什么时候该坚持用 ArrayBlockingQueue 的单锁设计
当你要的是可预测性、低延迟毛刺、以及明确的容量天花板时，单锁不是缺陷，而是约束力。
比如做接口流控：你设了 new ArrayBlockingQueue(200)，那系统最多积压 200 个请求，超出的直接被 offer() 拒绝或 put() 阻塞住——这种行为边界非常干净。换成 LinkedBlockingQueue，默认无界，稍不注意就 OOM；即使设了界，双锁带来的微小延迟波动反而让限流精度下降。
- 队列容量小（ArrayBlockingQueue 更稳
- 需要强内存局部性（如实时音视频帧缓冲），数组结构比链表更适合 CPU 缓存预取
- 拒绝策略必须硬性生效（如返回 503），而不是靠“尽力而为”的并发吞吐来扛压
单锁的瓶颈不是不能绕过，而是它本来就没打算绕——它要的是“可控的慢”，不是“不可控的快”。这点容易被忽略。
