ConcurrentLinkedQueue 的 head 指向哑节点、tail 可能滞后，是为在无锁下安全实现 offer/poll；它通过一次性节点避免 ABA 问题，offer 性能优于 poll，无界且不阻塞，不适合需容量控制或等待语义的场景。
ConcurrentLinkedQueue 的 head/tail 指针为什么不是直接指向首尾元素？
因为 Michael-Scott 算法要求 head 始终指向一个“哑节点”（dummy node），而不是实际数据节点；tail 则可能指向最后一个节点，也可能指向倒数第二个节点。这种设计不是偷懒，而是为了在无锁前提下安全地完成出队（poll）和入队（offer）——避免 CAS 失败后无法判断当前结构是否已变更。
关键点在于：出队时先用 CAS 尝试把 head 从哑节点推进到下一个节点，再取该节点的 item；如果失败，说明其他线程刚完成了这步，那就重试读取新的 head。整个过程不依赖锁，也不阻塞。
-
head和tail都是volatile字段，确保多核 CPU 上的可见性 - 每次 CAS 前都重新读取一次最新值，构成“读-改-写”循环，这是非阻塞算法的典型模式
- 不保证实时一致性：迭代器创建后看到的是快照，后续的
offer/poll不会影响它
为什么 ConcurrentLinkedQueue 不怕 ABA 问题，而自己手写容易翻车？
ABA 问题本质是：某个线程读到地址 A，另一线程把 A 改成 B 再改回 A，第一个线程的 CAS 误判为“没变”，导致逻辑错误。ConcurrentLinkedQueue 用的是指针地址比较，不是值比较 —— 即使新节点的 item 和旧节点一样，只要内存地址不同，CAS 就不会成功。
但它真正绕过 ABA 的关键是：所有节点一旦被出队，就不再复用（不回收、不 reset、不放回对象池）。也就是说，Node 实例是“一次性”的，地址永远只用一次。这比用版本号或 epoch 更轻量，也避免了复杂内存回收机制。
- 手写无锁队列时若尝试复用节点（比如用对象池），就必须引入 Hazard Pointer 或 EBR，否则大概率崩溃
- ConcurrentLinkedQueue 的
Node构造器是私有的，且内部不暴露引用，防止外部篡改或复用 - 它的 CAS 调用全部基于
UNSAFE.compareAndSwapObject，操作目标是字段偏移量，不是值本身
offer() 和 poll() 的性能差异为什么比想象中大？
offer() 在绝大多数情况下是单次 CAS：更新 tail.next，再尝试推进 tail；而 poll() 可能触发两次 CAS：先推进 head，再清空原 head.next.item。更关键的是，poll() 还要处理 head == tail 的边界情况（比如队列只剩一个真实节点），这时需要额外校验并重置 tail。
实测表明，在高争用（大量线程同时 poll）场景下，poll() 的失败重试概率明显高于 offer()。这不是 bug，而是 Michael-Scott 算法对“出队优先级”更低的权衡结果 —— 它优先保障入队吞吐，出队则接受一定延迟。
- 当队列长期为空又高频
poll()，会频繁触发head == tail分支，性能下降更明显 - 没有
size()的精确实现，是因为遍历链表算长度会破坏无锁性；isEmpty()也只是检查head == tail是否成立，不保证绝对准确 - 如果你的应用里消费速率远高于生产速率，得小心
poll()成为瓶颈，考虑换用LinkedBlockingQueue配合合理阻塞策略
什么时候不该用 ConcurrentLinkedQueue？
它不适合需要强一致语义或容量控制的场景。比如你希望队列最多存 1000 个任务，满了就拒绝新任务 —— ConcurrentLinkedQueue 是无界的，offer() 永远返回 true，不会拒绝。这时候必须靠上层加限流（如 Semaphore）或换用 ArrayBlockingQueue。
另一个常被忽略的点：它不提供任何等待能力。如果业务逻辑依赖“队列空时等新任务来”，你就得自己包装一层轮询 + Thread.sleep()，或者干脆用阻塞队列。别试图用 while (queue.isEmpty()) {} 自旋，那只会吃满 CPU。
- 秒杀系统里用它做任务缓冲没问题，但订单去重、库存扣减这类需原子事务的操作，不能只靠它保证一致性
- 日志收集场景常用它，但要注意：如果下游写磁盘慢，队列会无限增长，最终 OOM —— 必须配监控+告警+降级开关
- 它和
ConcurrentLinkedDeque共享同一套底层逻辑，但后者支持双端操作，代价是更复杂的 CAS 序列，别为了“看起来更通用”而误选
tail 滞后两步，也不用额外锁同步；为什么宁愿放弃 size() 精确值，也要保住 wait-free 特性。这些设计选择，往往比代码本身更值得细读。 
