版本号与指针必须打包进同一个 lock-free 的 std::atomic<TaggedPtr> 才能防 ABA；两个独立原子变量因无法原子读取快照，会导致线程读到错位的指针和版本值而误判。
版本号单独存成 std::atomic<uint64_t></uint64_t> 根本防不住 ABA —— 必须和指针打包进同一个 std::atomic 对象，且该类型得是 lock-free 的。
为什么两个独立原子变量会失效
常见错误写法是定义两个变量：std::atomic<node> head_ptr</node> 和 std::atomic<uint64_t> version</uint64_t>。线程 A 先读 head_ptr.load() 得到地址 A，再读 version.load()，中间可能被调度暂停；此时线程 B 已完成“弹出 A → delete A → 复用地址 A 分配新节点”，version 已 +2，但线程 A 读到的是旧版本值，CAS 时误判为“没变”。
根本问题在于：compare_exchange_weak 只能保证单个 std::atomic 的原子性，无法跨变量同步读取时间点。
- 两次
load()不构成原子快照 - 加
memory_order_acquire也消除不了两个变量间的竞态窗口 - 哪怕版本号用
uint64_t，只要它和指针不绑定，就白搭
正确做法：用 TaggedPtr 打包指针与版本号
把指针和版本号塞进一个结构体，再用 std::atomic 包裹它，并验证是否 lock-free：
立即学习“C++免费学习笔记（深入）”；
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
struct TaggedPtr {
uintptr_t ptr : 48; // x86-64 地址通常 48 位有效
uint64_t version : 16; // 剩余 16 位存版本，防溢出
};
static_assert(std::atomic<TaggedPtr>::is_lock_free(), "TaggedPtr must be lock-free");关键点：
- 必须用位域或
memcpy构造（避免对齐/填充破坏原子性） - 别颠倒字段顺序：x86-64 的
CMPXCHG16B指令期望低地址存指针、高地址存 tag - 构造后立刻检查
is_lock_free()—— 返回false就说明底层 fallback 到互斥锁，既非无锁，又可能死锁
在 CAS 操作中如何使用
所有读写都通过 std::atomic<taggedptr></taggedptr> 进行，不能拆开访问：
std::atomic<TaggedPtr> head_;
void push(Node* node) {
TaggedPtr old_head = head_.load();
do {
node->next = reinterpret_cast<Node*>(old_head.ptr);
TaggedPtr new_head{reinterpret_cast<uintptr_t>(node), old_head.version + 1};
if (head_.compare_exchange_weak(old_head, new_head)) break;
} while (true);
}注意：
-
compare_exchange_weak同时比对整个TaggedPtr：地址变或版本变，都会失败 - 每次修改头指针，版本号必须严格递增（哪怕只是重试）
- 不能只在成功时加版本号——否则多次失败重试后，版本号不变，仍可能撞上 ABA
容易被忽略的内存安全陷阱
加了版本号只能防止 CAS 误判，但不解决节点释放后的 use-after-free。比如线程 A 成功 pop 出节点 X，线程 B 在 A 还没完成析构前就复用了 X 的地址。
这意味着：
- 单纯
TaggedPtr+delete是危险的，必须配合风险指针（Hazard Pointer）、RCU 或引用计数 - 工程可用的无锁队列，
retire节点不能直接delete，得等所有线程确认没在用它 - 很多教程只讲版本号，却跳过内存回收——那代码跑压测时可能几天才崩一次，更难定位
