ConcurrentLinkedQueue 的 head/tail 非 volatile，因一致性由节点 next 字段的 volatile 语义间接保证；tail 允许滞后以减少 CAS 竞争，offer() 必须先 CAS next 再 CAS tail 防断链，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()时可能先 CASnext，再尝试更新 tail - head 同样可能指向已出队的“哨兵节点”，实际有效头由
first()跳过已删除节点确定 - 不要试图用反射修改
head/tail，它们没有同步契约，也不保证线程安全访问
offer() 里两次 CAS 的顺序为什么不能颠倒？
必须先 CAS 当前 tail 的 next 字段成功，再尝试 CAS tail 自身；如果反过来，先移动 tail 再设 next，会出现“断链”：新 tail 指向一个尚未被任何节点 next 指向的空节点，导致后续入队无法找到插入点，链表逻辑断裂。
这种顺序依赖是典型的无锁编程陷阱——CAS 成功不代表结构就绪，必须按拓扑依赖严格排序。
立即学习“Java免费学习笔记（深入）”；
- 第一次 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 更可预期
next 字段和有限几步 CAS 序列里；看懂 tail 滞后、head 清理、断链防护这三点，基本就摸到边界了。 
