LinkedBlockingQueue高吞吐的核心在于头尾分离的双锁机制：putLock管入队、takeLock管出队，二者互不干扰，并行执行；配合AtomicInteger count实现无锁计数与精准信号唤醒，避免串行瓶颈。
LinkedBlockingQueue 的高吞吐能力，核心就来自头尾分离的双锁机制——putLock 管尾部入队，takeLock 管头部出队，二者互不干扰。只要队列既不满也不空，生产者和消费者就能真正并行执行，不是“轮流上锁”，而是各自在独立临界区里干活。
为什么两个锁能实现真实并行？
关键在于职责彻底拆分：
- putLock 只负责：检查容量、新建节点、尾插、更新 count、唤醒其他生产者（notFull.signal）
- takeLock 只负责：检查非空、移除头节点、推进 head、更新 count、唤醒其他消费者（notEmpty.signal）
- 两把锁之间没有嵌套、不互相等待，也不存在锁顺序依赖
- 即使 put() 正在执行，take() 也能同时运行——前提是队列有空间且有数据
count 字段为何必须是 AtomicInteger？
count 是唯一被两个锁共同读写的共享变量，但它不走加锁路径，全靠原子操作保正确性：
- put() 中调用
count.getAndIncrement()：返回旧值 c，用于判断“插入前是否为空”（c == 0 → 需 signalNotEmpty） - take() 中调用
count.getAndDecrement()：返回旧值 c，用于判断“取出前是否已满”（c == capacity → 需 signalNotFull） - 若改用普通 int + synchronized，每次读写都要抢同一把锁，双锁优势瞬间归零
- CAS 保证了可见性与原子性，又避免了锁竞争开销
信号唤醒不是可选项，而是防死锁刚需
signalNotEmpty() 和 signalNotFull() 不是“锦上添花”，而是防止线程永久挂起的关键逻辑：
- put() 结束后，仅当 c == 0（即插入前队列为空）才调用 signalNotEmpty() —— 因为此时可能有消费者正卡在 notEmpty.await() 上
- take() 结束后，仅当 c == capacity（即取出前队列已满）才调用 signalNotFull() —— 否则生产者会永远等不到空间释放
- 漏掉任一条件判断，就会导致“队列明明有数据/有空位，但线程还在傻等”的典型假死现象
和 ArrayBlockingQueue 对比，差异一目了然
ArrayBlockingQueue 所有操作共用一把 ReentrantLock，put() 和 take() 必须串行执行：
- 哪怕 CPU 有 16 核，同一时刻也只能有一个线程在操作队列
- 压测中吞吐量常卡在某个平台值上，容易误判为 GC 或 CPU 瓶颈，实则是锁粒度太粗
- LinkedBlockingQueue 在相同场景下吞吐量可高出约 2.3 倍（JDK 17，100 万元素/秒级测试）
