std::atomic仅原子操作裸指针地址，不保证引用计数更新与对象析构的原子性；其store()/load()只拷贝指针值，而构造时+1、析构时-1的引用计数操作独立发生且不在同一原子上下文中。
它不保证“换指针 + 释放旧对象 + 增加新引用”的整套所有权语义是原子的，只保证裸指针地址的读写是原子的。想靠 std::atomic<:shared_ptr>></:shared_ptr> 一次调用就完成安全切换，会掉坑里。
为什么 store() 和 load() 只管指针地址，不管引用计数
std::atomic<:shared_ptr>></:shared_ptr> 的 store() 实际只是原子地拷贝内部的原始指针值（即 T*），并不触碰控制块；而 std::shared_ptr 构造时的引用计数 +1、析构时的 -1，早已在传入 store() 之前或之后独立发生——这些操作本身线程安全（因为控制块里的计数器是 std::atomic），但和指针替换动作不在同一个原子上下文中。
常见错误现象：
- 线程 A 调用
ptr.store(new_ptr)，线程 B 同时调用ptr.load()，B 拿到的是新地址，但此时 A 尚未完成对旧shared_ptr的析构，旧对象还活着 —— 看似没问题，但若 B 立即reset()自己持有的副本，可能提前释放资源 - 多个线程反复
store()同一个std::atomic<:shared_ptr>></:shared_ptr>，指针值切换是原子的，但每个线程传入的shared_ptr都指向同一控制块，引用计数增减虽原子，却无法防止旧对象被意外释放后，其它线程仍持有 dangling 指针
compare_exchange_weak 怎么用才不至于白忙活
CAS 不是用来“避免锁”的银弹，而是用来构建无锁结构的基石；它只保证“比较+写入”这一步原子，不负责后续生命周期管理。
典型正确用法（如无锁栈头更新）：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 先
load()当前值作为期望值 - 构造新节点，并确保其
next字段已设为旧头 - 用
compare_exchange_weak(expected, new_head)尝试替换；失败则重试（expected被自动更新为当前值） - 若成功，旧头节点的释放必须**显式、延后、单线程执行**（例如放进 hazard pointer 或 epoch-based reclamation 队列），不能依赖
shared_ptr自动析构
错误做法：把 compare_exchange_weak 当成“带锁的赋值”，以为只要 CAS 成功，旧对象就一定安全可析构 —— 实际上，其它线程可能正拿着旧 shared_ptr 的拷贝在访问它。
跨线程传递 shared_ptr 本身是否要加锁
不需要。拷贝或移动 std::shared_ptr 实例是线程安全的，因为其内部引用计数增减是原子操作；但前提是——你不是在并发读写**同一个变量**。
也就是说：
- ✅ 安全：
thread_A把sp拷贝给thread_B的局部变量（两个独立shared_ptr对象） - ❌ 危险：
thread_A和thread_B都直接读写全局变量std::shared_ptr<t> g_ptr</t>（C++20 前必须用std::mutex或改用std::atomic<:shared_ptr>></:shared_ptr>） - ⚠️ 易忽略：
std::weak_ptr::lock()是线程安全的，但返回的shared_ptr只保证“此刻存活”，后续解引用仍需同步对象内部状态（比如加std::mutex）
真正容易被忽略的点在于：原子智能指针解决的是“指针值变更”的竞态，不是“对象访问”的竞态。哪怕你把 store() 换成了 exchange()，拿到旧值后调用 reset()，这个 reset() 依然可能触发 delete，而 delete 正在执行时，其它线程若正通过 weak_ptr.lock() 拿到同一对象，就会踩进析构中半途的对象内存 —— 这就是为什么无锁结构必须配回收机制，而不是靠 shared_ptr 自动收尾。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
