Java并发队列ConcurrentLinkedQueue原理详解

ConcurrentLinkedQueue 是一个基于CAS的无锁、非阻塞、高并发友好的链表队列，它舍弃了强一致性、阻塞语义和可靠size统计，换来了极致的吞吐与低延迟，特别适用于日志收集、事件缓冲等允许瞬时不可见、无需等待、能容忍null返回的场景；但正因如此，它绝非BlockingQueue的替代品——误将其用于需要阻塞或精确状态判断的逻辑（如忙等待轮询或size条件判断）不仅低效，更违背其设计契约，真正高效使用的关键在于理解并尊重它的“无锁哲学”：线程从不等待，只靠重试推进，而一切性能优势都建立在对使用边界清醒认知的基础之上。

ConcurrentLinkedQueue 是什么队列

它不是 synchronized 或 ReentrantLock 保护的阻塞队列，而是靠 Unsafe.compareAndSetObject 实现的无锁（lock-free）非阻塞队列。这意味着多线程入队、出队不会挂起线程，也不会因锁竞争拖慢吞吐——但代价是：它不保证强一致性，也不提供阻塞操作（比如 take() 或 put()）。

为什么 offer() 和 poll() 不会阻塞却可能返回 null

poll() 在队列为空时直接返回 null，不是抛异常，也不是等待；offer() 几乎总返回 true（仅在内存耗尽等极端情况下失败）。这是设计使然：它面向高并发、低延迟场景，比如事件缓冲、日志收集，而不是任务调度。

• 常见错误：把 ConcurrentLinkedQueue 当作 BlockingQueue 用，写成 while (queue.poll() == null) Thread.sleep(1) —— 这既浪费 CPU，又违背非阻塞本意
• 正确姿势：配合生产者-消费者模式中的“忙等待 + yield”或转投 LinkedBlockingQueue（如果真需要阻塞）
• size() 方法不可靠：它遍历链表计数，过程中节点可能被其他线程修改，返回值仅作估算，不能用于条件判断（比如 if (q.size() > 0)）

CAS 失败时它怎么重试

内部节点用 volatile 字段标记状态，所有结构变更（如 next 指针更新）都靠 UNSAFE.compareAndSwapObject 循环尝试。失败不报错，只是继续循环——这就是 lock-free 的核心：线程永不等待他人，只靠重试推进。

• 典型场景：多个线程同时 offer()，都试图更新 tail 节点的 next，只有一个成功，其余自动重试指向新 tail
• 性能影响：在极高争用下（比如单核超线程+密集写），CAS 自旋会抬高 CPU，但比锁竞争更可控
• 注意：JVM 必须支持 Unsafe，且 JDK 9+ 中部分 Unsafe 方法受限，但 ConcurrentLinkedQueue 已适配为使用 VarHandle 回退，无需用户干预

它和 CopyOnWriteArrayList / LinkedBlockingQueue 的关键区别

不是“更快”或“更安全”的通用替代品，而是适用面窄、假设强：要求元素操作本身无副作用、不依赖顺序强一致、能容忍瞬时不可见。

• CopyOnWriteArrayList：读多写少，每次写都复制数组，适合迭代频繁且写极少的场景；ConcurrentLinkedQueue 写吞吐高，但迭代器弱一致性（可能跳过刚入队未链接的节点）
• LinkedBlockingQueue：有锁 + 可选容量限制 + 支持阻塞，适合任务分发；而 ConcurrentLinkedQueue 容量无限、无界、不阻塞，失控增长可能 OOM
• 容易被忽略的一点：它不实现 BlockingQueue 接口，所以不能传给 ThreadPoolExecutor 构造函数（会编译报错）

实际用的时候，别只看“高性能”三个字——先想清楚你要不要阻塞、要不要精确 size、能不能接受 poll() 返回 null 且不通知。这些不是缺陷，是契约。

终于介绍完啦！小伙伴们，这篇关于《Java并发队列ConcurrentLinkedQueue原理详解》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！