LinkedBlockingQueue适合高吞吐、低竞争的生产者-消费者场景，采用双锁分离机制提升读写并发性能，但存在OOM风险、GC压力大等问题，需谨慎配置容量并避免阻塞误用。
LinkedBlockingQueue 适合高吞吐、低竞争的生产者-消费者场景
它内部用独占锁（takeLock 和 putLock 分离）实现双锁机制，读写操作不互斥，比 ArrayBlockingQueue 在多线程混合读写时吞吐更高。但锁粒度仍大于无锁队列（如 ConcurrentLinkedQueue），所以不适合超高频、极低延迟要求的场景。
典型适用场景包括：
- 后台任务调度器（如定时任务分发到工作线程池）
- 日志收集系统中，应用线程异步写入，日志线程批量刷盘
- RPC 框架的请求/响应缓冲，尤其是 QPS 中等、消息体较大、对偶发延迟不敏感的情况
容量设置为 Integer.MAX_VALUE 时等于无界队列，但仍有风险
默认构造函数创建的是“无界”队列，实际是容量设为 Integer.MAX_VALUE。它不会抛 IllegalStateException，但可能引发 OOM —— 因为只要生产者快于消费者，队列就持续增长，JVM 堆内存会被撑爆。
建议显式指定合理容量，并配合拒绝策略：
立即学习“Java免费学习笔记（深入）”；
- 用带参构造函数：new
LinkedBlockingQueue(1024) - 在
offer()失败后主动降级（如丢弃、告警、同步阻塞写入） - 避免依赖
put()的无限等待特性，除非你确认消费者永不积压
take() 和 poll(timeout, unit) 的阻塞行为差异影响线程模型
take() 是无超时阻塞，线程会一直挂起直到有元素；而 poll(long, TimeUnit) 可中断、可超时，更适合需要响应关闭信号或做周期性检查的场景。
常见误用：
- 在 shutdown 流程中调用
take()，导致线程无法退出（即使已调用shutdownNow()） - 用
poll(1, TimeUnit.SECONDS)替代take()却未处理返回null的逻辑，造成空指针或忙等 - 在响应式流（如 Project Reactor）中混用阻塞调用，破坏非阻塞契约
与 SynchronousQueue、ArrayBlockingQueue 的关键取舍点
选型不能只看“是否阻塞”，得看数据流动模式和资源约束：
- 要零缓冲、严格一对一交接（如线程池中直接移交任务），用
SynchronousQueue—— 它不存储元素，put()必须等待配对的take() - 要确定容量上限 + 公平策略 + 更小内存开销，选
ArrayBlockingQueue（数组结构，无额外 Node 对象） - 要中等容量 + 读写分离锁 + 兼顾吞吐与可控内存，才真正适合
LinkedBlockingQueue
最容易被忽略的一点：它的节点是链表结构，每个元素都包装成一个 Node 对象，高频短生命周期消息会显著增加 GC 压力 —— 这比容量配置错误更隐蔽，也更难排查。
