危险指针的核心作用是延迟释放，即让读者声明“正在使用某节点”，写者检查无引用后才回收，需线程长期持有hazard_pointer实例并正确调用store/clear，配合retired_list周期扫描实现安全内存重用。
危险指针的核心作用不是“防止崩溃”，而是“延迟释放”
危险指针（Hazard Pointer）本身不提供线程安全的内存分配，也不自动保护读操作；它只解决一个具体问题：当多个线程并发访问无锁数据结构（如无锁栈、无锁队列）时，如何确保某个节点在被其他线程“正在读取”时不被提前 delete。它的本质是让读者主动声明“我正在用这个指针”，写者查表确认无人引用后才回收。
这意味着：你必须在每次解引用共享节点前，将该节点指针存入本线程专属的 hazard pointer 槽位；且每个线程至少需维护一个 hazard_pointer 实例（通常作为 TLS 变量）。
必须手动管理 hazard pointer 槽位的生命周期和可见性
常见错误是把 hazard_pointer 当作局部变量或临时对象使用——这会导致写者扫描时看到空槽，误判节点可回收。正确做法是每个线程长期持有至少一个可写的 hazard pointer 实例，并保证其地址对全局回收线程可见。
- 推荐用
thread_local存储：thread_local hazard_pointer hp;，避免反复构造/析构开销 - 调用
hp.store(ptr)必须发生在实际解引用ptr之前（不能晚于ptr->next） - 读完后应尽快调用
hp.clear()或覆盖为新值，否则会阻塞回收——但不必精确到每行，可在逻辑块末尾统一清理 - 若使用自定义数组模拟多槽位（如支持同时保护多个节点），要确保写者遍历的是所有活跃线程的全部槽位，而非仅当前线程
回收线程必须定期扫描 + 延迟释放，不能直接 delete
危险指针机制不保证“立即释放”。典型实现中，待回收节点先被链入全局 retired_list，回收线程周期性遍历所有线程的 hazard pointer 槽位，比对 retired_list 中每个节点是否未被任何槽位持有，仅当全都不持有时才真正 delete。
关键细节：
- 扫描频率影响内存驻留时间：太低 → 内存泄漏倾向；太高 → 影响写者性能。常见策略是每 N 次写操作触发一次扫描，或用单独低优先级线程轮询
-
retired_list本身需无锁（如用std::atomic头插），否则引入新锁点 - 务必注意 ABA 问题：节点被回收又重新分配为同一地址，可能被旧 hazard pointer “误保”。危险指针本身不解决 ABA，需配合版本号或内存池隔离
std::shared_ptr 不能替代 hazard pointer
有人试图用 std::shared_ptr 管理无锁结构中的节点，这是危险的。因为 shared_ptr 的引用计数增减不是无锁原子操作（即使 std::atomic 也仅保证指针本身原子，不保证内部计数器无锁），且计数器更新与解引用之间无顺序约束，可能导致计数归零后仍被访问。
更严重的是语义错配：shared_ptr 表达“谁还在用”，而 hazard pointer 表达“我现在正用”。前者无法表达瞬时读取意图，后者也不提供自动内存管理。两者混合使用反而增加竞态风险。
真正需要的是：明确区分“发布”（publish）、“读取”（read with protection）、“退休”（retire）、“回收”（reclaim）四个阶段，并严格按序执行——其中 hazard pointer 只负责第二步的显式声明与第四步的判定依据。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
