ConcurrentLinkedQueue原理及实现解析

今日不肯埋头，明日何以抬头！每日一句努力自己的话哈哈~哈喽，今天我将给大家带来一篇《ConcurrentLinkedQueue原理与实现解析》，主要内容是讲解等等，感兴趣的朋友可以收藏或者有更好的建议在评论提出，我都会认真看的！大家一起进步，一起学习！

ConcurrentLinkedQueue 是基于 CAS 和 volatile 实现的无锁线程安全队列，采用单向链表结构，通过“延迟更新”tail/head、懒删除和自旋重试机制实现高并发性能，但牺牲强一致性，适用于高吞吐、弱一致性可接受场景。

ConcurrentLinkedQueue 是 Java 中基于无锁（lock-free）算法实现的线程安全队列，核心原理是利用 CAS（Compare-And-Swap）原子操作 + volatile 变量 + 链表结构，在不加锁的前提下保证多线程下的高并发读写性能。

底层是单向链表，节点用 volatile 修饰保证可见性

每个节点（Node）包含 item（元素）和 next（指向后继节点的引用），其中 next 字段被声明为 volatile。这确保了任意线程对 next 的修改能立即被其他线程看到，避免因 CPU 缓存不一致导致的读取旧值问题。item 字段也用 volatile 修饰，但插入成功后会被设为 null（作为已出队标记），这是其“懒删除”设计的一部分。

CAS 驱动入队（offer）和出队（poll）全过程

入队操作不是简单追加到 tail，而是遵循“两步定位 + 一次 CAS”策略：

• 先尝试在当前 tail 后插入新节点；若失败（tail 已被其他线程更新），就通过跳转到实际尾节点再重试
• 插入成功后，再尝试 CAS 更新 tail 指针——但这个更新不是必须的，属于“延迟更新”，即 tail 可能滞后于真实尾节点（允许一定误差，提升性能）

出队操作类似：先检查 head.next 是否存在，若存在则 CAS 尝试将 head.item 设为 null（逻辑删除），再 CAS 移动 head 指针；若 head.next 为空（队列空或中间有未清理节点），就通过遍历跳过已删除节点，重新定位有效头结点。

没有锁，但有“自旋 + 重试”机制应对竞争

当多个线程同时操作同一个位置（如同时更新 tail 或 head）时，CAS 失败会触发循环重试（spin loop），直到成功或发现结构已变化需重新探测。这种机制避免了阻塞和上下文切换开销，但也意味着在极高争用下可能带来一定 CPU 消耗。它不提供强一致性保证，比如 size() 方法就只是遍历计数，结果可能瞬间过期——所以官方文档明确建议 size() 仅作估算，不可用于条件判断。

不支持 null 元素，且不保证迭代器强一致性

构造时就禁止插入 null，否则抛 NullPointerException。迭代器采用“快照式”弱一致性设计：遍历时不会抛 ConcurrentModificationException，但可能跳过刚入队的元素，也可能重复返回已被 poll 但尚未完成物理移除的节点（因为节点只逻辑删除，物理链路还在）。这是无锁设计的典型取舍——用一致性换吞吐量。

基本上就这些。它不是万能的，适合高并发、低延迟、容忍弱一致性的场景；如果需要阻塞、精确大小或强一致性，应考虑 LinkedBlockingQueue 或 ArrayBlockingQueue。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。