LinkedBlockingQueue 吞吐高是因为采用 takeLock 和 putLock 两把独立锁实现读写分离，使入队和出队操作可并行执行；默认无界但需防 OOM，推荐有界初始化并避免频繁调用 size()。
LinkedBlockingQueue 是 Java 并发包中一个线程安全、基于链表实现的阻塞队列，适合高吞吐场景——关键在于它内部使用了两把独立锁（takeLock 和 putLock），实现“读写分离”，让出队和入队操作可并行执行，避免传统单锁队列的串行瓶颈。
为什么 LinkedBlockingQueue 吞吐高？
它不像 ArrayBlockingQueue 那样用一把 ReentrantLock 保护整个队列，而是：
- putLock：仅控制入队（offer/put）操作，不影响出队
- takeLock：仅控制出队（poll/take）操作，不影响入队
- 两把锁互不干扰，生产者和消费者可真正并发执行
- 默认容量为 Integer.MAX_VALUE，适合缓冲大量待处理任务（但要注意 OOM 风险）
典型高吞吐用法：生产者-消费者模型
搭配线程池与非阻塞/阻塞方法合理使用，减少线程挂起开销：
- 生产者优先用 offer(E)（非阻塞，失败立即返回 false），配合重试或降级逻辑
- 消费者用 poll() 或 poll(timeout, unit)，避免无限等待；若需强可靠性，可用 take()（但注意线程可能长时间阻塞）
- 初始化时显式指定容量（如 new LinkedBlockingQueue(1024)），防止无界增长导致内存失控
关键调优与避坑点
高吞吐不等于盲目堆参数，需关注实际瓶颈：
立即学习“Java免费学习笔记（深入）”；
- 慎用无界队列：默认无界易引发内存溢出，尤其在生产速率远超消费速率时
- 避免频繁调用 size()：该方法需同时加两把锁，会严重拖慢吞吐；改用 isEmpty() 或预估水位（如记录计数器）
- 注意锁竞争残留：虽然双锁分离，但在队列空/满时，仍需短暂获取另一把锁来通知等待线程（如空队列中 put 后需 signal notEmpty），但频率低、影响小
- 结合监控：通过 peek() + size()（低频采样）或自定义包装类统计积压量，及时触发告警或动态扩缩容消费者
简单示例：轻量级异步日志收集器
体现高并发写入 + 稳定消费的典型模式：
// 定义有界队列，避免无限堆积
private static final BlockingQueue<String> logQueue = new LinkedBlockingQueue<>(8192);
// 生产者（业务线程中快速写入）
public static void log(String msg) {
if (!logQueue.offer(msg)) {
// 入队失败：丢弃、降级到文件或触发告警
System.err.println("Log queue full, dropped: " + msg);
}
}
// 消费者（单独线程持续拉取）
new Thread(() -> {
while (running) {
try {
String log = logQueue.poll(100, TimeUnit.MILLISECONDS); // 短超时，平衡延迟与CPU
if (log != null) writeToFile(log);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
break;
}
}
}).start();
