CAS与ABA问题破解：无锁编程的版本号与延迟回收方案

我到现在还记得那次线上事故排查：一个压测中的无锁队列，跑了不到两小时开始偶发节点丢失，日志里怎么都找不到规律。最折磨人的是，所有 CAS 操作的结果都显示成功，程序却依然给出错误的状态。那是我第一次真正见识到 ABA 问题的杀伤力——表面上看起来“数据没变”，实际上中间已经经历了翻天覆地的变化。也正是那段排查经历，让我对无锁编程的底层语义有了完全不同的理解。

这篇文章我想把 CAS、ABA 问题以及破解方案一次讲透，配合 C++ 和 Java 两个方向的代码示例。不管你是刚接触无锁编程的新手，还是已经在线上踩过坑的资深工程师，都值得花十分钟读完下面这部分内容。因为这类问题一旦发生，排查成本通常远超你的预期，而且它不会以“报错”的方式提醒你——它只会在你的数据结构里悄悄撕开一道口子。

1. 无锁编程的基石：从“锁的代价”到 CAS

1.1 锁到底慢在哪

在介绍 CAS 之前，先理解为什么我们需要 CAS。传统多线程编程用锁保护共享变量，临界区同时只能进一个线程。这个做法简单可靠，代价却藏在看不见的地方。

线程在获取锁失败后会被操作系统挂起，进入休眠状态并让出 CPU；等到锁被释放，系统再找到它、唤醒它、重新调度它。一次完整的线程切换往往要消耗几十微秒，而一条原子指令在硬件上只需要几个纳秒。如果临界区本身的代码只有几十纳秒，那锁的开销就是临界区执行时间的一千倍以上。更麻烦的是，锁竞争越激烈，上下文切换越频繁，CPU 缓存命中率下降，整体性能会进一步恶化。

还有一个不那么直观的问题：锁的粒度很难控制。你用一把大锁保护整个数据结构，两个线程明明操作的是不同节点，也要互相等待；你用细粒度锁，死锁和顺序问题又来了。无锁编程就是为了绕开这些问题产生的——它不用操作系统挂起线程，而是通过原子操作让多个线程“尝试”更新数据，成功就继续，失败就重试。高并发场景下这种忙等策略反而比线程切换更高效。

1.2 CAS 的硬件原语与内存语义

CAS 的全称是 Compare And Swap，硬件上就是一条指令。它的语义可以写成这样：

bool compare_and_swap(void* ptr, void* expect, void* update) { if (*ptr == expect) { *ptr = update; return true; } return false; }

关键区别在于，“读取当前值、判断是否相等、写入新值”这三步在硬件层面是原子的，中间不存在任何让其他线程插入的空隙。这不是编译器优化能做到的，而是 CPU 指令集提供的原生能力。

C++ 里最常见的写法是：

std::atomic<int> counter{0}; int current = counter.load(); if (counter.compare_exchange_strong(current, current + 1)) { // 更新成功 }

注意这里current是引用语义：如果 CAS 失败，current会被改写为最新的实际值，所以可以直接放进循环里重试。Java 里则更直白一些：

AtomicInteger counter = new AtomicInteger(0); int current = counter.get(); if (counter.compareAndSet(current, current + 1)) { // 更新成功 }

除了 CAS，还有 Test-And-Set、Fetch-And-Add、Compare-And-Exchange 等原子原语。它们的共性都是：单条原子指令内完成“检查 + 修改”，这是无锁编程能成立的前提。

1.3 CAS 最适合解决的场景

CAS 擅长处理“读-改-写”类型的操作，典型场景包括：

• 计数器与统计值：比如线程数、库存余量、点击量
• 标志位翻转：不可变状态机的推进、单次初始化
• 引用计数：智能指针、GC 辅助
• 数据结构头节点：无锁栈、无锁队列的入队/出队

用一个贴近生活的类比：CAS 就像一个门卫，他只会做一件事——如果房间里站着“你认为的那个人”，就让他进去，否则就什么都不动。并且“看清是谁 + 放行”是同一个动作，中间没有任何间隙。这个类比能解释后文的所有问题，请记住它。

2. ABA 问题：为什么“值没变”不等于“状态没变”

2.1 从理论定义到第一个崩溃瞬间

ABA 问题的定义一句话就能说清：一个变量从 A 变成 B，再从 B 变回 A。此时 CAS 检查发现“值还是 A”，就判定操作成功，但实际上中间已经发生过其他线程的插入操作。

问题在于，CAS 只比较值，不比较时间线。值相等不代表状态一致，尤其当这个值是一个指针、索引、引用句柄时，中间的 B 状态可能已经彻底改变了数据的结构。最经典的例子，也是我第一次真正理解它的场景，是 Treiber 无锁栈。

2.2 Treiber 无锁栈的现场还原

Treiber 栈是教科书级的无锁数据结构，入栈和出栈都只用 CAS 操作栈顶指针top。你可以先想象一个初始状态：Top -> A -> B -> C，栈顶是 A，A 的 next 是 B，B 的 next 是 C。

线程 T1 准备执行 pop 操作，它先读到top = A，并且保存了A->next = B。就在它准备 CAS 的瞬间，被操作系统切走了。这是整个事故的起点——无锁编程里所有的崩溃都发生在“读取了旧状态但还没完成更新”这个窗口。

线程 T2 接管后开始操作：

• T2 执行 pop，弹出 A，栈顶变为 B；
• T2 继续执行 pop，弹出 B，栈顶变为 C；
• T2 执行 push(A)，把 A 又压回栈顶，栈顶重新变为 A，并且A->next被改成了NULL。

此时栈的状态是：Top -> A -> NULL。原来的 B、C 节点已经不在链表中了。

T1 终于被唤醒，它在 CAS 中期望top == A。比较后发现 top 确实还是 A，于是 CAS 成功，它把top更新为A->next，也就是它记忆里的 B。但问题来了：这个 B 已经不是当初栈结构里那个 B 了。它可能已经被释放回内存池，甚至被复用作其他对象。T1 更新后的栈顶指向一块早已不属于当前栈的内存，整个链路直接断裂。站在内存层面看，top 变量从 A 变成 B 再变回 A，T1 从头到尾只看到了 A——这就是 ABA 名字的由来。

2.3 不止无锁栈会炸：哪些场景容易踩坑

总结下来，以下场景是 ABA 的高发地带：

• 无锁队列：head/tail 指针的 CAS 同样管不住节点地址重用，队列里的“幽灵元素”经常是 ABA 的杰作。
• 对象池与内存复用：拉取对象、归还对象的过程如果依赖指针 CAS，地址被归还后再被分配到别处，就会造成“A 地址指向了身份完全不同的对象”。
• 引用计数：两个线程对同一个计数做 CAS，看似计数相等，但中间对象可能已经进入了回收流程。计数相等但生命周期状态不等，就会误释放正在使用的对象。
• 自旋锁：用 CAS 实现的自旋锁也有 ABA 的影子。一个线程持锁后阻塞，另一个线程抢锁、释放锁，锁状态看起来又变回“未持有”。如果前者醒来后只凭 CAS 判定“锁可用”，但它的锁其实已经丢了，行为就会出错。
• 缓存索引：很多系统用自增 ID 做缓存键，当 ID 回绕或被复用后，用 CAS 比较旧 ID 也会踩坑。

核心结论是：只要 CAS 比较的“值”存在被重用、回绕、复用的可能，你就该考虑 ABA。尤其是引用/指针型变量，几乎必然中招——因为堆内存上的 malloc 分配和释放非常频繁，操作系统极有可能把一个刚释放的内存块重新分配给后续的分配请求。这意味着，即使一个指针的“数值”一模一样，两次取值之间它指向的对象可能已经换了主人。ABA 在指针语义下几乎是环境条件，不是偶然意外。

3. 破解之道：从版本号到延迟回收

3.1 方案一：版本号/标记位——CAS 加一维时间轴

最直观的思路是给目标值配一个版本号（Stamp）。每次修改，值可以回到原点，但版本号只增不减。CAS 比较时同时比较“值 + 版本号”，只有两者都相等才算成功。

Java 标准库里已经有现成的工具：AtomicStampedReference<V>。它内部维护一个Pair<V, Integer>，compareAndSet同时验证引用和版本号。使用示例：

AtomicStampedReference<Node> top = new AtomicStampedReference<>(head, 0); int[] stampHolder = new int[1]; Node current = top.get(stampHolder); Node next = current.next; if (top.compareAndSet(current, next, stampHolder[0], stampHolder[0] + 1)) { // 成功 }

这里的关键等式是：引用相等 并且 版本号相等，才能完成替换；版本号在每次成功修改时递增。这样即使节点地址从 A 变回 A，版本号也已经从n变成了n+1，旧线程的 CAS 就会失败，然后重试读最新状态。

对于只需要“标记是否变化过”的场景，AtomicMarkableReference<V>更省内存：它内部只有一个布尔标记位，每次修改时翻转它。使用版本号要注意一个问题：版本号本身的溢出。32 位 int 版本号如果被高频操作频繁递增，极端条件下会回到原点，ABA 死灰复燃。虽然现实中很难碰到，但严谨的系统会使用 64 位版本号，或者在单调递增的分配器里兜底。

3.2 方案二：Tagged Pointer——把地址和版本号塞进一个原子字

版本号方案在 Java 里实现很简单，因为语言封装好了。但在 C/C++ 里，把一个指针和一个版本号放进结构体，再对结构体做 CAS，会碰上一个现实问题：大多 CPU 的 CAS 只能操作一个机器字（通常是 8 字节），没法原子地同时比较“指针 + 另一个独立变量”。

解决思路有两种，本质都是“想办法压缩到 8 字节以内”。

第一种做法利用内存对齐。现代 CPU 上，通过malloc或者new分配的对象，地址通常按 8 字节对齐，也就是地址的低 3 位永远是 0。这 3 个位可以腾出来放标记或版本号。操作时先把普通指针编码成一个包含 tag 的uintptr_t，CAS 成功后再把 tag 清除，恢复真实指针：

constexpr uintptr_t TAG_MASK = 0x7; // 低 3 位做 tag Node* get_node(uintptr_t encoded) { return reinterpret_cast<Node*>(encoded & ~TAG_MASK); } uintptr_t get_tag(uintptr_t encoded) { return encoded & TAG_MASK; }

每次成功更新top时，都把版本号递增，并写进新编码值里：

uintptr_t encoded = top.load(); uintptr_t old_tag = encoded & TAG_MASK; Node* next_node = get_node(encoded)->next; uintptr_t new_encoded = (reinterpret_cast<uintptr_t>(next_node) & ~TAG_MASK) | ((old_tag + 1) & TAG_MASK); top.compare_exchange_strong(encoded, new_encoded);

即使next_node正好等于旧节点地址（比如 A 被压回栈顶），因为新编码里的 tag 已经变了，旧线程拿旧编码去做 CAS 依然会失败。这就是 Tagged Pointer 的精髓：同一个地址，因为携带的版本号不同，被视为不同的值。

第二种做法更通用：在 x86-64 平台，用户态指针实际只使用低 48 位（现在硬件逐步扩展到 57 位，但用户态仍有余量），可以把高 16 位放版本号，低 48 位放指针。但这种方式跟平台强绑定，换架构就要改代码。除非你在写一次性配套的底层库，否则我更推荐低 3 位 tag 方案——它只依赖于“8 字节对齐”这一普遍事实，跨平台移植性更好。

注意：用低位 tag 方案前，务必确认对象的对齐方式。如果你用了#pragma pack(1)或者自行分配了未对齐的内存，低 3 位可能非零，tag 方案不再适用。在 C++17 里可以写个静态断言拦一道：static_assert(alignof(Node) >= 8)。

3.3 方案三：别让 ABA 有发生的土壤——延迟回收与 RCU

版本号与 Tagged Pointer 是“检测到变化就失败”。还有另一种更巧妙的思路：让旧值不可能被复用。只要旧地址永远不会被重新分配给新对象，ABA 就无从谈起。

GC 语言天然占有这个优势。Java 的AtomicReference虽然也做 CAS，但 JVM 的垃圾回收器不会在对象存活期间把刚弹出的节点地址重新分配给新对象。因此在 Java 中，纯粹的指针型 ABA 很难发生，真正需要小心的是“值语义”字段的 ABA。

C/C++ 世界里则要靠自己实现延迟回收。常见方案包括：

• RCU（Read-Copy-Update）：读操作不加锁，直接读旧数据；写操作复制一份副本修改完再发布新版本；旧版本节点不立刻释放，等到所有读者离开临界区后才回收。
• Hazard Pointer：每个线程在自己的线程局部区记录“我当前正在读哪个节点”。写站在释放节点前，先看有没有线程记录了该地址，有就延迟释放。
• 引用计数：在 CAS 更新前先对节点引用计数加 1，确保对象不会被并发释放，操作完成后再减计数。实现简单，但对计数本身的 CAS 又可能引入新的 ABA，需要结合版本号使用。

这三种方案的共同点是：用“内存安全”换“不检测 ABA”。在绝大多数无锁数据结构设计里，它才是更本质的解法。

3.4 四种方案横评

从实际项目角度，Java 里优先用AtomicStampedReference，C++ 里优先用低 3 位 tag，除非你的对象分配器无法保证 8 字节对齐。

4. 实战避坑：从方案选型到线上排查

4.1 如何根据数据类型选择防 ABA 方案

先对数据类型做一个粗粒度分类：

• 纯整数自增/减（计数器）：一般不必防 ABA，因为业务通常只关心最终值，中间过程不可观测。但如果你用 CAS 做“库存扣减再补回”这类补偿逻辑，就需要版本号。判断标准是：业务是否关心“被其他线程读到的中间状态”。
• 引用/指针语义：几乎必须防 ABA。用 Tagged Pointer 最省事，但要保证对齐。
• 混合结构：比如无锁队列的完整节点，用版本号方案做整体 CAS 成本较高，不如在关键的 top/head/tail 指针上加 tag。

实际项目中我最推荐的策略是“先防指针型 ABA，再看业务是否需要对值型防 ABA”。不要一上来给所有 CAS 都加版本号，那会把一个简单计数器变成一台昂贵的摩擦机。

4.2 C++ Tagged Pointer 的完整实现细节

除了核心思路，还有几个细节值得说深一点。

第一，对齐校验。在代码里加编译期断言，而不是运行时报错：

static_assert(alignof(Node) >= 8, "Node must be at least 8-byte aligned");

第二，解引用前必须清 tag。我曾经见过一个线上 bug：tag 方案上线后进程频繁崩溃，GDB 一查全是非法地址访问，原因是拿到编码后的值后直接reinterpret_cast<Node*>(encoded)->next去读，忘了把低 3 位清零。这短短一行，就是事故的全部。

第三，位宽与回绕。3 位 tag 的取值空间是 0 到 7，如果一个地址在极短时间内被连续复用 8 次，tag 会回绕到原值，ABA 会死灰复燃。在绝大多数业务下 8 次足够，但如果你在设计一个极度追求极限的底层组件，就得多留几个位，比如利用 16 字节对齐时的低 4 位，或者直接走高 16 位方案。

第四，CAS 失败后绝不能盲目重试。使用 tag 戳破一次假 CAS 后，必须重新 load top 的最新值，重新提取 next 指针，再发起新 CAS——每次失败都要刷新全部状态。很多人栽在这上面：循环写对了，但循环体里用的还是旧的current和next，于是陷入活锁。

4.3 Java 无锁栈的完整示例

写一个防 ABA 的 Treiber 栈，方便对照：

public class LockFreeStack<T> { private static class Node<T> { final T value; Node<T> next; Node(T value) { this.value = value; } } private final AtomicStampedReference<Node<T>> top = new AtomicStampedReference<>(null, 0); public void push(T value) { Node<T> newNode = new Node<>(value); int[] stamp = new int[1]; Node<T> current; while (true) { current = top.get(stamp); newNode.next = current; if (top.compareAndSet(current, newNode, stamp[0], stamp[0] + 1)) { return; } } } public T pop() { int[] stamp = new int[1]; Node<T> current; Node<T> next; while (true) { current = top.get(stamp); if (current == null) return null; next = current.next; if (top.compareAndSet(current, next, stamp[0], stamp[0] + 1)) { return current.value; } } } }

这段代码跟经典 Treiber 栈唯一的差别就是多了一个 stamp。在 pop 失败后，循环会重新读取最新的 top 和 stamp，而不是拿旧的再试一次——这本身就是防止 ABA 死循环的关键。

4.4 一次线上 ABA 事故排查实录

我处理过的一起事故，现象是：压测环境下，无锁 FIFO 队列偶发“丢节点”。队列的 head 和 tail 都用 CAS 更新，出队人数和入队人数从日志看偶尔不等，而且无法稳定复现。

排查走了三条路：

• 第一步，看日志和统计，确认不是算法逻辑错乱，而是某个 CAS 假成功；
• 第二步，开启线程调度记录，发现丢节点的时间点往往出现在“一个线程从睡眠里被唤醒、立即执行出队”的窗口；
• 第三步，用 GDB 断在 CAS 附近，打印每次 CAS 前后的节点地址，发现有一组前后完全相同的地址——节点指针在队列里被弹出又压回，地址没有变化，但 next 指针已经变了。这正是 ABA。

修复方式选用 Tagged Pointer，因为当时已经在 C++ 场景下，低 3 位 tag 改动最小，也没有引入新的分配策略。压测 12 小时后不再出现丢失，问题闭环。

这件事最大的教训是：无锁代码的正确性不能靠“看”，要靠压力测试和工具。除了 TSan、GDB，我还会用 Java 的 Loom 或者形式化建模（TLA+）来辅助验证，尤其是设计新模块时，模型检查能提前发现一批隐蔽的并发 bug。

5. 常见误区与高频面试考点

5.1 误区一：ABA 问题只在指针类型中出现

这不是事实，值类型也时有发生。典型的例子是账户余额扣减。线程 A 读取余额 100，准备扣到 90；线程 B 先扣到 85，又通过某种补偿逻辑补回 100。此时线程 A 的 CAS(100 -> 90) 必然成功，但它实际扣的是一个“后来才涨回去”的余额，中间那笔交易的历史信息已经丢失。

这种场景是否需要防，取决于业务语义。如果只要求“当前余额最终正确”，ABA 带来的“多扣一次/少扣一次”可能还能接受。但支付网关那种强一致场景，就不能有任何侥幸。

5.2 误区二：用 volatile 或 synchronized 就能避开

volatile只能保证可见性，不提供原子性，更没法检测中间变化。synchronized虽然保证互斥，但你把 CAS 换成synchronized后就不再是无锁编程了，性能逻辑也变了。ABA 是 CAS 语义的自带属性，避不开它，只能用更强的语义（版本号）或换实现（锁）。

5.3 误区三：stamp 的初始值随便传一个就行

AtomicStampedReference构造时传入的 stamp 代表状态的“出生版本”。如果业务里用 -1 表示“未知”，而初始 stamp 传了 0，第一条 CAS 和系统初始化之间就可能出现语义错位。规范做法是：把 stamp 当作单调递增的序列号来用，不要赋予它业务含义。

还要警惕递增溢出。int 最大值约 21 亿，大多数业务一亿年也跑不到，但如果你的系统里有“高频率循环复用同一地址的节点池”，几年内是有可能戳到边界的。真遇到这种边界，最稳妥的兜底是加一个全局重置逻辑或直接切换成 64 位计数器。

5.4 高频面试题：手写防 ABA 的无锁栈

这道题在面试中出现频率极高。面试官的潜台词是：你能不能识别 CAS 的假成功，并且用最少代码解决。参考思路如下：

• 第一步，定义节点，顶层变量就是AtomicStampedReference<Node>；
• 第二步，push 时用 stamp 包装新节点；
• 第三步，pop 时用 stamp 记录当前版本，CAS 时同时更新版本；
• 第四步，失败后重新读取 top 和 stamp，再循环。

追问点通常是：如何在 32 位环境下实现同样的防 ABA？这个答案并无定式，常见拆法是“用两个 32 位原子组合成一个逻辑原子变量”，但两个 32 位之间还有空隙，并发下并不完全安全。更稳妥的答案是用锁保护。这时候面试官更想听的是：无锁是手段，不是目的。正确性和可维护性才是第一位的。

我在实际开发中的体会是，ABA 问题不是“nice-to-have”的优化点，而是无锁编程必需的一课。所有基于 CAS 的高并发组件，架构设计阶段就要确立两件事：这个值会被复用吗？中间状态会被其他线程观测到吗？只要有一个答案是肯定的，就老老实实加上版本号或延迟回收，不要心存侥幸。

最后再分享一个排查小技巧：如果你的无锁结构在压测时偶现异常，不要立刻怀疑 CPU 或编译器，先写一个 5 分钟内能跑出结果的高并发循环测试，把 CAS 成功次数与总操作次数同时打出来。如果成功次数远大于预期，就说明有假成功——这时候 80% 的注意力可以放在“变量是否被复用”上。这个经验帮我省下很多时间，也希望它能让你少走一次弯路。