ArrayBlockingQueue的单锁机制因所有操作共用同一ReentrantLock，导致读写互斥，高并发写时锁竞争激烈，吞吐量被串行化瓶颈限制；小容量、多线程密集写入或启用公平锁时性能显著下降。
ArrayBlockingQueue 的单锁机制如何限制写吞吐量
ArrayBlockingQueue 所有操作（put、offer、take、poll）都依赖同一把 ReentrantLock，这意味着任何写入线程在调用 put 时，必须先获取这把锁；而此时若恰好有消费者正在执行 take，它也得抢同一把锁——写和读互斥。高并发写场景下，多个生产者线程会持续争抢这把锁，形成“锁竞争热点”，实际吞吐量很快被串行化瓶颈卡死。
什么情况下单锁会明显拖垮写性能
以下情况会让 ArrayBlockingQueue 的写吞吐量快速跌落：
- 队列容量小（如 ≤10），且生产节奏快：频繁触发
notFull.await()，每次唤醒后仍要重新抢锁，上下文切换开销放大 - 线程数 ≥8 且持续
put：实测中 16 线程向容量为 32 的队列密集写入时，锁争用率超 70%，平均等待时间跃升至毫秒级 - 启用了公平锁（
new ArrayBlockingQueue(cap, true)）：虽然避免饥饿，但调度开销更高，吞吐进一步下降 15%–25% - 与
LinkedBlockingQueue混用对比时未注意锁粒度差异：误以为“都是阻塞队列”，忽略了后者putLock和takeLock分离带来的并行优势
怎么验证当前队列是否已成为写瓶颈
不要只看 CPU 或 GC，重点观察锁行为：
- 用
jstack -l <pid>抓线程栈，搜索parking to wait for <.*?>，如果大量线程停在ArrayBlockingQueue$ConditionObject.await或ReentrantLock$NonfairSync.acquire，说明锁竞争严重 - 通过 JMX 查
java.util.concurrent.locks:type=Threading下的CurrentThreadCpuTime和CurrentThreadUserTime差值，若差值大且线程长期处于WAITING (parking)，基本可判定是锁等待 - 对比相同负载下
LinkedBlockingQueue的put耗时：若前者 P99 延迟高出 3 倍以上，大概率是单锁设计所致
绕过单锁写瓶颈的务实做法
不建议强行优化锁本身（源码不可改），而是调整使用方式或替换：
- 降低写压力：用批量
drainTo替代高频单条put，减少锁进入次数 - 换队列：写密集 + 消费异步的场景，直接切到
LinkedBlockingQueue；它在 20+ 线程下吞吐通常高 30%–60% - 加缓冲层：在生产者端加一个无锁环形缓冲区（如
Disruptor或自研RingBuffer），再由单个 writer 线程批量刷入ArrayBlockingQueue - 接受容量约束：如果业务本质就是“限流”（比如厨房工位只能接 5 单），那单锁反而是优点——它天然强制节流，此时性能不是问题，稳定性才是目标
真正容易被忽略的是：单锁不是缺陷，而是设计取舍。它换来的是内存局部性好、GC 压力低、实现简单可靠；一旦你把它当通用高吞吐队列用，就等于在用螺丝刀拧螺母——工具没错，只是用错了场。
