concurrentlinkedqueue 是基于 cas 的无锁线程安全队列，不使用操作系统互斥锁，而是通过 volatile 变量和 unsafe.compareandset 原子操作实现 head/tail 指针更新与节点发布，支持高并发但 size() 不精确、不允许 null 元素。
ConcurrentLinkedQueue 是 Java 中基于 CAS 实现的无锁、线程安全队列，核心在于不依赖 synchronized 或 ReentrantLock，而是通过原子操作保障多线程下的结构一致性与内存可见性。
为什么叫“无锁”？它到底锁了什么
所谓“无锁”，不是完全不涉及同步机制，而是不使用操作系统级的互斥锁（如 monitor）。它依赖 CPU 提供的 CAS（Compare-And-Swap）指令，在硬件层面原子地更新指针（如 head/tail 节点引用）。线程不会因竞争而被挂起或阻塞，失败时主动重试——这带来更低的上下文切换开销和更好的可伸缩性。
需要注意的是：无锁 ≠ 无竞争。高并发下多个线程反复 CAS 失败再重试，仍可能造成 CPU 浪费（即“忙等待”），但整体吞吐通常优于传统锁队列（如 BlockingQueue 的加锁实现）。
CAS 如何支撑队列的线程安全操作
ConcurrentLinkedQueue 内部是单向链表结构，每个节点包含 item 和 next 引用。关键操作均围绕两个 volatile 变量展开：
- head：指向队列头节点（可能不是逻辑首元素，存在“懒更新”优化）
- tail：指向队列尾节点（同样可能滞后，用于快速入队）
所有修改都通过 UNSAFE.compareAndSet 完成，例如：
- offer()：尝试将新节点追加到 tail.next；若失败（tail 已变），则先跳转到最新 tail 再重试
- poll()：尝试将 head.next 的 item 设为 null 并前移 head；若 head 无后继或已被其他线程消费，则推进 head 指针并重试
这种“乐观 + 重试”策略避免了临界区，也消除了死锁风险，但要求开发者理解其弱一致性语义——比如 size() 方法遍历链表计数，结果可能不精确。
volatile 与内存屏障的关键作用
CAS 能正确工作，离不开 volatile 对变量读写的内存语义约束：
- head/tail 声明为 volatile，确保每次读取都从主内存获取最新值，写入立即刷新到主内存
- JVM 在 volatile 读/写前后插入内存屏障（Memory Barrier），防止指令重排序破坏节点间依赖关系（例如：不能把 item 初始化放在 next 赋值之后）
- Node 内部的 next 和 item 字段虽未显式声明 volatile，但通过 Unsafe 的原子操作+volatile 引用传播，间接保证了发布安全性（safe publication）
实际使用中需注意的边界行为
ConcurrentLinkedQueue 高性能的背后，是一些反直觉的设计取舍：
- 不允许插入 null 元素，否则抛 NullPointerException（这是明确契约，非 bug）
- size() 方法时间复杂度为 O(n)，且返回值仅作估算参考；如需精确计数，应自行维护原子计数器
- 迭代器 weakly consistent：遍历时允许其他线程修改队列，不抛 ConcurrentModificationException，但可能跳过刚插入的元素或重复看到已删除元素
- 空队列的 poll() 返回 null，不阻塞；如需阻塞语义，请选用 LinkedBlockingQueue 等有界/阻塞实现
