C++如何使用std::atomicstd::shared_ptr进行线程安全指针操作-C++-PHP中文网

c++oding="utf-8" ?>

不能。c++标准禁止对std::shared_ptr特化std::atomic，因其不满足trivially copyable和lock-free要求；c++20虽引入部分支持，但仍受限于平台和实现，多数场景需用std::atomic_load/store自由函数或改用std::atomic等替代方案。

c++如何使用std::atomicstd::shared_ptr进行线程安全指针操作

std::atomic<:shared_ptr>> 能直接用吗？

不能。C++ 标准库不提供 std::atomic<:shared_ptr>></:shared_ptr> 的特化版本（直到 C++20 才部分支持，且仅限 trivially copyable 类型，而 std::shared_ptr 不满足该条件）。直接写 std::atomic<:shared_ptr>> ptr;</:shared_ptr> 会编译失败，报错类似：error: no matching constructor for initialization of 'std::atomic<:shared_ptr>>'</:shared_ptr>。

根本原因是 std::shared_ptr 的控制块引用计数操作不是原子的，其内部结构（指针 + 控制块指针）无法用单条 CPU 指令完成无锁读写 —— 即使底层支持双字原子操作，标准也未要求实现该特化。

替代方案：用 std::atomic 手动管理 shared_ptr

主流且可移植的做法是用 std::atomic<void></void> 存储 std::shared_ptr 的原始指针（get()），再配合 std::shared_ptr 构造函数重建对象。关键在于：所有线程必须只通过原子变量读写原始指针，且每次读取后立即构造临时 std::shared_ptr 来接管所有权。

写入时：先构造新 std::shared_ptr，再用 load() 获取旧指针并调用 reset()（或直接丢弃），最后用 store() 写入新指针
读取时：用 load() 得到 void*，强制转换为原类型指针，再传给 std::shared_ptr 构造函数（注意：该构造函数接受 T* 和自定义 deleter，但此处需确保原始指针仍有效）
必须配对使用自定义 deleter：否则原始指针被 store() 覆盖后，旧对象可能提前析构，导致悬空指针

示例：

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

struct Data { int x; };
std::atomic<void> ptr{nullptr};
<p>// 写入
auto new_ptr = std::make_shared<data>();
new_ptr->x = 42;
Data* raw = new_ptr.get();
// 注意：这里不直接 store(raw)，因为需要绑定 deleter
ptr.store(raw, std::memory_order_relaxed); // ❌ 错误！没处理引用计数</data></p>
<p>// 正确写法：用 RAII 封装，或改用 lock-free stack 等成熟模式
</p></void>

更安全的选择：std::atomic<:shared_ptr>> 在 C++20 中的限制

C++20 引入了对 std::atomic 的部分模板特化支持，但仅当 T 是 trivially copyable 时才可用。而 std::shared_ptr<t></t> 不是 trivially copyable（含非平凡构造/析构），所以即使在 C++20 下，std::atomic<:shared_ptr>></:shared_ptr> 依然不合法。某些编译器（如 libc++）可能提供扩展支持，但不可移植。

真正能用的 C++20 原子智能指针是 std::atomic<:unique_ptr>></:unique_ptr> —— 因为 std::unique_ptr 在满足 is_trivially_copyable_v<deleter></deleter> 时是 trivially copyable。但这和 shared_ptr 的共享语义无关。

实际项目中推荐怎么做？

放弃“原子 shared_ptr”幻想，回归明确的同步模型：

若只需多线程读、单线程写：用 std::shared_ptr<t></t> 配合 std::mutex 保护写操作，读操作无需加锁（shared_ptr 的引用计数本身是原子的）
若需无锁读写：改用 std::atomic<:unique_ptr>></:unique_ptr>（C++20），或基于 hazard pointer / RCU 的第三方库（如 folly::AtomicSharedPtr）
若必须共享所有权且高频更新：考虑用 std::shared_ptr + std::atomic_flag 实现粗粒度 CAS 循环，但复杂度陡增，容易出错

最常被忽略的一点：很多人以为把 shared_ptr 放进 atomic 就能避免竞态，却忘了 shared_ptr 的线程安全仅保证引用计数操作原子性，不保证所指对象的访问安全 —— 这才是绝大多数问题的根源。