如何通过 ConcurrentLinkedQueue 的 Pointee 变量理解无锁算法中对“空节点”的特殊处理逻辑

如何通过 ConcurrentLinkedQueue 的 Pointee 变量理解无锁算法中对“空节点”的特殊处理逻辑

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

开门见山，先说一个核心澄清：ConcurrentLinkedQueue 里压根就没有所谓的 Pointee 变量。这个误解流传甚广，通常是因为不同编程语言的术语，或者某些教学模型为了方便讲解而引入的示意性概念被混淆了。在 Ja va 标准库的实现里，ConcurrentLinkedQueue 的核心就是一个基于 CAS 的链表，每个节点依靠 volatile Node next 和 Object item 这两个字段来运转。“Pointee”并非 JDK 源码的一部分。

所以，如果你在博客、技术分享或者 Rust/Go 的类比代码里看到这个词，那多半是作者为了形象地解释“逻辑上应该被跳过的节点”而自创的，千万别把它和官方实现划等号。

ConcurrentLinkedQueue 怎么识别和跳过“空节点”

那么，源码里真正的“空节点”指的是什么？它特指那些 item == null 并且已经成功执行了出队操作（即 casItem(item, null) 成功）的节点。这些节点虽然还留在链表里，但已经不代表任何有效数据了。

无论是入队（offer）还是出队（poll），线程在遍历时都必须主动跳过这些“空节点”，否则整个队列的线性一致性就会被破坏。这里的跳过逻辑，并不依赖任何额外的标记字段，而是通过一个经典的双重检查来实现：既要看 item == null，也要确认 next != null。后者说明这个节点虽然逻辑上被删除了，但还没有被后续的线程从链表结构上完全“绕开”。

// 简化自 JDK 8 的 poll() 片段
Node p = head;
for (;;) {
    Node h = p, s = p.next;
    if (h == p) { // 检查是否被其他线程修改过 head
        if (s == null) return null; // 队列空
        else if (s.item != null) // 找到首个非空节点 → 返回
            return s.item;
        else // s.item == null → 是空节点，跳过它
            p = s;
    }
}

为什么不用额外字段（如 Pointee）标记“跳转目标”

一个很自然的想法是：既然要跳过，为什么不直接用个字段（比如假想的 Pointee）预先存好下一个有效节点的地址呢？原因其实很实际。

首先，增加字段就意味着更多的内存占用，每次更新节点状态时，CAS 操作需要覆盖的字节数也更多，开销自然就上去了。

更重要的是，空节点的“跳转目标”是动态变化的。它可能被后续的线程继续向前推进，也可能因为并发入队操作而失效。预先存一个地址，很可能下一秒就过时了。

所以，ConcurrentLinkedQueue 采用的策略更加轻巧：让前驱节点通过 CAS 操作，直接将其 next 指针更新到真正的后继节点上（即源码中的 helpDelete 逻辑）。这种设计将状态和动作紧密耦合在一起：

• item == null 这个状态本身就宣告了节点“逻辑死亡”。
• next != null 则表明它还在链表中“占着位置”。
• 线程在遍历过程中，顺带就完成了这种“惰性清理”（lazy cleanup），无需额外的簿记工作。

容易踩的坑：误把 next == null 当作队尾，忽略空节点链

在实际使用或调试时，有一个常见的思维陷阱：认为只要 tail.next == null，就找到了队列的末尾。

这个判断在高并发场景下尤其危险。因为 tail 指针的更新是延迟的，在大量出队操作后，队列尾部很可能堆积起一连串 item == null 的“空节点”。此时，tail 指向的未必是真正的逻辑尾节点。

正确的做法是，必须从 head 或者当前的 tail 出发，沿着 next 指针一路向后扫描。直到找到第一个 item != null 的有效节点，或者遇到一个 next == null 且 item == null 的节点，那才是物理和逻辑上都真正的终点。

调试时，别光看对象引用链的形状。多利用 toString() 方法或者直接断点查看 node.item 和 node.next 的实际值，你会对并发下的链表状态有更直观的认识。

说到底，无锁算法的难点从来都不在于“如何跳”，而在于“什么时候该跳，以及跳到哪一步才能停住”。这个决策是由多个线程对同一个节点发起 CAS 操作的顺序动态决定的，无法通过单次读取某个字段来预测。这也正是所有正确的无锁实现都强调“循环重试 + volatile 读 + CAS 写”这一组合拳的原因——它依赖的是动作的原子性和状态的可观测性，而不是某个静态的标记。这才是理解此类并发容器的关键所在。