C++如何使用std::atomicstd::shared_ptr进行无锁指针切换-C++-PHP中文网

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

不能。std::atomic 不合法，因 std::shared_ptr 非 trivially copyable，标准禁止该特化；多数实现 is_lock_free() 为 false，实为锁模拟，并非真正无锁。

c++如何使用std::atomicstd::shared_ptr进行无锁指针切换

std::atomic<:shared_ptr>> 能否直接用于无锁指针切换？

不能。标准明确禁止对 std::shared_ptr 类型特化 std::atomic（除 trivially copyable 的特例外），std::atomic<:shared_ptr>></:shared_ptr> 在绝大多数编译器上会触发编译错误，例如：static_assert failure 或 “specialization of ‘atomic’ for non-trivial type is not allowed”。这是因为 std::shared_ptr 的拷贝/移动涉及引用计数修改，不是原子操作，无法满足 std::atomic 对底层 is_lock_free() 和 trivial 复制的硬性要求。

为什么 std::atomic<:shared_ptr>> 编译失败后有人还能用？

部分旧版 libstdc++（如 GCC 4.8–5.x）曾提供非标准扩展，允许 std::atomic<:shared_ptr>></:shared_ptr>，但其内部实际加了互斥锁（is_lock_free() == false），根本不是无锁——只是语法上“看起来像”。C++17 起该扩展已被移除，Clang libc++ 从未支持。所以你看到的“能编译”，大概率是：用了过时工具链、没开 -std=c++17、或误把 std::atomic<void></void> 当成了 shared_ptr 版本。

检查方式：添加 static_assert(std::atomic<:shared_ptr>>::is_lock_free(), "");</:shared_ptr> —— 几乎必然失败
替代路径：必须用 std::atomic<t></t> + 手动管理 shared_ptr 生命周期，或改用 std::atomic<:uintptr_t></:uintptr_t> 存储裸指针地址

安全无锁切换 shared_ptr 的可行方案：atomic + 引用计数双检查

核心思路是：不原子地操作 shared_ptr 对象本身，而是原子地操作其内部裸指针，并确保引用计数在切换前后始终有效。典型做法是用 std::atomic<void></void> 存储当前有效对象地址，配合 std::shared_ptr 构造时的自定义删除器做延迟释放。

C函数速查手册（CHM版）

下载

示例关键逻辑：

struct Node { int data; };
std::atomic<void> g_head{nullptr};
<p>void push_node(std::shared_ptr<node> new_node) {
void<em> expected = g_head.load();
do {
new_node->next = static_cast<node>>(expected);
} while (!g_head.compare_exchange_weak(expected, new_node.get()));
// 注意：此处 new_node 离开作用域，但其控制块仍被链表持有
}</node></em></node></p>
<p>std::shared_ptr<node> pop_node() {
void<em> curr = g_head.load();
Node</em> node = static_cast<node>>(curr);
if (!node) return nullptr;
void next = node->next;
if (g_head.compare_exchange_strong(curr, next)) {
return std::shared_ptr<node>(node, [](Node<em> p) { /</em> 延迟释放逻辑 */ });
}
return nullptr;
}</node></node></node></p></void>