concurrentlinkedqueue 通过傀儡头节点、原子推进 head 指针和链式引用关系实现无锁出队，无需显式状态标志位；head 推进即逻辑出队，节点是否可达由引用关系隐式标记，更轻量且规避 aba 问题。
Java 中 CAS 在无锁队列（如 ConcurrentLinkedQueue）里不靠“状态标志位”来避免多线程同时出队冲突，而是靠节点结构设计 + 原子推进 head 指针 + 傀儡头节点（dummy node）机制协同实现。所谓“状态标志位”在标准 JDK 实现中并不存在——它用的是更轻量、更符合无锁语义的链式标记策略。
傀儡头节点隔离真实数据，天然规避状态竞争
队列初始化时，head 指向一个不存业务数据的傀儡节点（dummy node）。所有真实数据节点都从它的 next 开始链接。这样：
- 多个线程调用
poll()时，都尝试 CAS 更新head从傀儡节点指向其next（即第一个有效节点） - 只有一个线程能成功——其余线程看到
head已被更新，就自动转向新的head.next继续尝试 - 不需要给节点加“已出队”标志位，因为节点一旦被某个线程通过 CAS 摘下，后续线程读到的
head已不同，自然绕过该节点
CAS 更新 head 不是直接改值，而是“推进指针”
poll() 的核心不是修改节点字段，而是原子地移动 head 引用：
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 先读当前
head节点 - 再读该节点的
next（即待出队节点） - 用
UNSAFE.compareAndSetObject尝试把head从旧节点设为next - 失败说明其他线程已抢先推进，就重试；成功则拿到待出队节点，返回其数据
这个过程完全不依赖节点内部的状态字段，避免了写冲突和内存可见性问题。
真正起“标记”作用的是指针位置本身
节点是否“已被出队”，不由节点上的布尔字段决定，而由它是否还被 head 或中间节点引用决定：
- 只要一个节点仍被某处引用（比如还在链上），它就“逻辑存活”
- 一旦
head推进越过它，且没有其他节点指向它，它就进入不可达状态，可被 GC 回收 - 这种基于引用关系的隐式标记，比显式 flag 更安全：不会因忘记设 flag、flag 被覆盖或缓存不一致导致误判
为什么不用显式状态标志位？
如果强行在节点加 volatile boolean inQueue 或类似字段：
- 每次
poll()都要 CAS 修改该字段，增加一次原子操作，降低吞吐 - 多个线程可能同时对同一节点的 flag 执行 CAS，失败率上升
- 无法解决 ABA 问题：节点被出队又重入（极少见但理论存在），flag 可能被复用误判
- 而傀儡节点+指针推进方案，天然规避 ABA——因为 head 总是向前单向移动，不会回退
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
