ConcurrentLinkedQueue 的线程安全完全依赖 UNSAFE.compareAndSetObject，核心 CAS 发生在 tail 和 head 的更新上；offer() 可能需两次 CAS（先连节点再推进 tail），poll() 返回 null 不代表队列为空，size() 非实时且不可用于空判断。
ConcurrentLinkedQueue 的 CAS 操作到底在哪儿发生
它不是靠 synchronized 或 ReentrantLock，所有线程安全逻辑都压在 UNSAFE.compareAndSetObject 上。关键位置只有两处：入队的 tail 更新和出队的 head 更新。每次 offer() 或 poll() 都会循环尝试 CAS，直到成功或发现结构已变（比如 tail 被别的线程改了）。
常见错误现象是：明明队列不为空，poll() 却返回 null。这不是 bug，而是因为当前线程看到的 head 节点还没被前序操作“真正推进”，它还在“逻辑头节点”的前一个傀儡节点上 —— 这正是无锁设计里典型的 ABA 问题缓解策略：用傀儡节点隔离数据节点，避免直接 CAS head 到数据节点引发的判断混乱。
-
tail不一定指向队尾元素，可能指向倒数第二个节点（为减少 CAS 冲突而延迟更新） -
head同样不一定指向第一个有效节点，初始时就是傀儡节点，且长期可能滞留 - 所有 CAS 失败后都会重新读取最新
tail或head，再重试，不阻塞、不挂起线程
为什么 offer() 有时要走两次 CAS 才能插入成功
因为 ConcurrentLinkedQueue 把“找到尾节点”和“把新节点连上去”拆成了两个独立 CAS 步骤。第一次 CAS 尝试把新节点设为当前 tail.next；如果失败（说明 tail 已过期），就先用第二次 CAS 推进 tail 到更靠后的节点，再重试连接。
这在高并发写场景下很常见：多个线程同时 offer()，都基于同一个旧 tail 值去设置 next，必然只有一个成功，其余全得先帮着“修正 tail”，再继续插。性能影响在于：写吞吐越高，CAS 失败率越高，平均每个元素插入实际执行的原子操作数可能远超 1 次。
立即学习“Java免费学习笔记（深入）”；
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 单线程下
offer()几乎总是一次 CAS 完成 - 多线程争抢时，
tail可能被反复推进，导致某次offer()触发 2～3 轮 CAS 循环 - 没有锁膨胀开销，但 CPU cache line 争用会变明显，尤其在多 socket 机器上
poll() 返回 null 却 size() > 0 是正常现象
这是最常被误认为“队列坏了”的地方。size() 方法本身是遍历链表计数，而 poll() 只负责尝试摘下第一个有效节点。两者完全异步、无同步点。当你看到 size() 返回 5，poll() 却返回 null，大概率是：当前 head 还卡在傀儡节点，而真实第一个数据节点已被别的线程抢先 poll() 并标记为已删除（但尚未推进 head）。
根本原因在于：size() 不保证实时性，也不加任何控制；它只是个尽力而为的快照。JDK 文档明确说它是 O(n) 且“不一定准确”。线上如果用 size() == 0 来判断是否停止消费，一定会漏数据。
- 永远别用
size()控制循环或判断空闲状态 -
poll()返回null只代表“此刻没拿到”，不代表“队列空”，需结合业务重试或用peek()辅助判断 - 如果真需要精确大小，自己用
AtomicInteger配合入队/出队手动维护
add() 和 offer() 行为差异极小，但异常语义不同
两者底层调用的都是同一套 CAS 插入逻辑，性能、内存布局、线程安全性完全一致。唯一区别是：当队列因 JVM 内存不足无法创建新节点时，add() 会抛 IllegalStateException，而 offer() 返回 false。注意，这个异常不是来自并发冲突，而是 new Node() 失败 —— 实际生产中几乎只会在 OOM 前夕出现。
所以选哪个，纯粹看你的错误处理风格：喜欢用异常流控就用 add()，偏好显式状态判断就用 offer()。别指望它们在并发行为上有任何差别。
-
add()和offer()在 CAS 层面调用的是同一个私有方法enqueue() - 没有容量限制，所以永远不会因为“满”而拒绝插入（不像
ArrayBlockingQueue） - 别被名字误导：
add()不是“加锁版”，offer()也不是“弱一致性版”
真正难啃的是节点状态的隐式流转：傀儡节点、已删除节点、未连接节点……这些都不暴露给用户，但每一步 CAS 都在和它们博弈。看源码时盯着 casNext() 和 casHead() 两条路径，比死记“无锁=快”有用得多。
