ConcurrentLinkedQueueCAS实现解析

ConcurrentLinkedQueue 作为 Java 中典型的无锁并发队列，其精妙之处在于摒弃了对 head/tail 字段加 volatile 的直觉做法，转而依托节点 next 字段的 volatile 语义与严格有序的双 CAS 操作（先设 next 再更新 tail）来保障链表拓扑完整性与内存可见性；它允许 tail 滞后、head 指向已出队哨兵节点，以换取极低的 CAS 竞争开销，而 poll() 返回 null 并非队列为空，而是触发惰性清理的信号，迭代器则采用弱一致性设计，在性能与实时性间做出务实取舍——理解这三大机制（滞后更新、断链防护、惰性清理），才算真正掌握了无锁链表背后“协调藏于节点、同步隐于顺序”的设计哲学。

ConcurrentLinkedQueue 的 head/tail 指针为什么不是 volatile？

因为它们本身不直接参与 CAS 逻辑，真正被 CAS 修改的是节点的 next 字段；head 和 tail 是普通字段，靠节点链路的可见性（通过 next 的 volatile 语义）间接保证一致性。JVM 内存模型中，volatile 写对后续 volatile 读有 happens-before 关系，而 next 字段正是这个“枢纽”。

常见错误是误以为要给 head/tail 加 volatile —— 这不仅多余，还会破坏 Doug Lea 原始设计中的“懒更新”策略：tail 不总指向真实尾节点，而是允许滞后几个节点，减少 CAS 竞争。

• tail 滞后是正常行为，不是 bug；调用 offer() 时可能先 CAS next，再尝试更新 tail
• head 同样可能指向已出队的“哨兵节点”，实际有效头由 first() 跳过已删除节点确定
• 不要试图用反射修改 head/tail，它们没有同步契约，也不保证线程安全访问

offer() 里两次 CAS 的顺序为什么不能颠倒？

必须先 CAS 当前 tail 的 next 字段成功，再尝试 CAS tail 自身；如果反过来，先移动 tail 再设 next，会出现“断链”：新 tail 指向一个尚未被任何节点 next 指向的空节点，导致后续入队无法找到插入点，链表逻辑断裂。

这种顺序依赖是典型的无锁编程陷阱——CAS 成功不代表结构就绪，必须按拓扑依赖严格排序。

• 第一次 CAS：U.compareAndSet(node.next, null, newNode)，确保插入点存在且未被抢占
• 第二次 CAS：U.compareAndSet(this.tail, node, newNode)，仅在上一步成功后才推进 tail
• 若第一次失败（node.next != null），说明别人已插入，直接重试；若第二次失败，不影响数据正确性，只是 tail 更新延迟

poll() 返回 null 时，到底发生了什么？

不是队列为空，而是当前 head 节点的 item 已被其他线程清空（设为 null），且该节点尚未被跳过；此时 poll() 会触发一次“清理动作”：顺着 next 找下一个非空 item 的节点，并尝试用 CAS 更新 head 指针。

这个过程可能跨多个节点，也可能遇到中间节点也被并发修改的情况，所以返回 null 只代表“本次没取到有效值”，不代表队列真的空了。

• 返回 null 后立即再调用 poll()，很可能拿到值——因为清理已推进
• 如果连续多次返回 null，大概率是多线程激烈竞争下 head 滞后严重，或大量节点处于“已出队但未清理”状态
• 注意：isEmpty() 并不遍历全链表，它只检查 head.item == null && head.next == null，因此可能误判（false negative）

为什么不能用 for-each 遍历 ConcurrentLinkedQueue？

因为它的迭代器是弱一致性的（weakly consistent），不抛 ConcurrentModificationException，但也不保证看到所有元素或不重复；遍历时若其他线程正在 offer()/poll()，可能跳过刚插入的节点，或反复看到同一个节点（尤其在 tail 滞后、head 清理不及时的情况下）。

这不是 bug，而是性能与一致性权衡的结果：强一致性遍历需要全局快照，代价太高，无锁结构主动放弃它。

• 想可靠统计长度？别用 size()（它要遍历，且结果可能过期），更别用 for-each
• 需要稳定快照？自己加锁 copy 到 ArrayList，或换用 CopyOnWriteArrayList（但注意写多场景下性能崩塌）
• 调试时打印内容？用 toArray() 更稳妥，它内部做了单次遍历+复制，比 for-each 更可预期

事情说清了就结束。CAS 链表的“无锁”不是没有协调，而是把协调压进每个节点的 next 字段和有限几步 CAS 序列里；看懂 tail 滞后、head 清理、断链防护这三点，基本就摸到边界了。

好了，本文到此结束，带大家了解了《ConcurrentLinkedQueueCAS实现解析》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！