你的 lock-free queue 通过了所有单元测试，在 4 线程环境下稳定跑了整整一周，性能数据漂亮，直到你把压测线程数拉到 64，跑了 17 分钟后收到 SIGSEGV，打开 coredump 一看，崩溃地址指向的那块内存已经被 free 掉又被另一次 enqueue 重新 allocate 成了一个全新的节点，而 dequeue 线程还在拿着这个地址做 CAS 比较，比较"成功"了——因为新节点的 next 指针恰好和旧节点的 next 指针值相同——然后整个队列的链表结构被撕裂，后续所有操作都在一个已经断裂的链上狂奔，直到某个线程解引用了一个彻底非法的地址。这不是一个低级 bug。每一步 CAS 操作都"正确地"返回了 true，每一个原子操作都满足了 memory ordering 的要求，TSan 在低并发下也报不出任何 data race。问题出在一个更深层的地方：你的无锁队列没有解决"什么时候可以安全地释放一个已经被逻辑删除的节点"这个问题。这就是无锁编程中最隐蔽、最致命、也最经常被"先跑起来再说"的程序员忽略的问题——内存回收的生死时序。这篇文章要做的事情是：从那个 coredump 出发，沿着 ABA 问题的精确时序一步步追踪崩溃的根因，然后从 1983 年 IBM 的第一个 ABA 相关专利讲到 2004 年 Maged Michael 提出 Hazard Pointer，再到 2024 年即将进入 C++26 标准的std::hazard_pointer，让你建立起对 lock-free 内存回收的完整认知——不只是"知道有这个东西"，而是能够精确判断"在我的场景下，该用 Hazard Pointer 还是 Epoch-Based Recla
为什么你的无锁队列在压测中崩了——从 ABA 问题到 Hazard Pointer，追踪 lock-free 内存回收的生死时序
你的 lock-free queue 通过了所有单元测试，在 4 线程环境下稳定跑了整整一周，性能数据漂亮，直到你把压测线程数拉到 64，跑了 17 分钟后收到 SIGSEGV，打开 coredump 一看，崩溃地址指向的那块内存已经被 free 掉又被另一次 enqueue 重新 allocate 成了一个全新的节点，而 dequeue 线程还在拿着这个地址做 CAS 比较，比较"成功"了——因为新节点的 next 指针恰好和旧节点的 next 指针值相同——然后整个队列的链表结构被撕裂，后续所有操作都在一个已经断裂的链上狂奔，直到某个线程解引用了一个彻底非法的地址。这不是一个低级 bug。每一步 CAS 操作都"正确地"返回了 true，每一个原子操作都满足了 memory ordering 的要求，TSan 在低并发下也报不出任何 data race。问题出在一个更深层的地方：你的无锁队列没有解决"什么时候可以安全地释放一个已经被逻辑删除的节点"这个问题。这就是无锁编程中最隐蔽、最致命、也最经常被"先跑起来再说"的程序员忽略的问题——内存回收的生死时序。这篇文章要做的事情是：从那个 coredump 出发，沿着 ABA 问题的精确时序一步步追踪崩溃的根因，然后从 1983 年 IBM 的第一个 ABA 相关专利讲到 2004 年 Maged Michael 提出 Hazard Pointer，再到 2024 年即将进入 C++26 标准的std::hazard_pointer，让你建立起对 lock-free 内存回收的完整认知——不只是"知道有这个东西"，而是能够精确判断"在我的场景下，该用 Hazard Pointer 还是 Epoch-Based Recla
