使用std::atomic实现引用计数可确保多线程下对象安全共享，通过原子操作避免竞态条件。其核心是利用std::atomic作为引用计数器，在增减时保证操作不可分割，防止内存泄漏或双重释放。增加引用时用memory_order_relaxed提升性能，减少引用并判断是否释放资源时用memory_order_acq_rel确保内存顺序与可见性。自定义实现需注意循环引用、异常安全、自我赋值等问题，最佳实践是优先使用std::shared_ptr，若自研则遵循RAII、分离控制块并充分测试。
在C++中，使用
std::atomic实现引用计数是确保共享对象在多线程环境下能够被安全管理的关键。它的核心在于提供了一种无需锁机制，就能保证计数器增减操作原子性的方法，从而有效避免了竞态条件，防止了内存泄漏或过早释放等问题。简单来说，
std::atomic就是我们在并发编程中构建可靠共享所有权机制的基石。
解决方案
要使用
std::atomic实现引用计数，我们通常会设计一个类似于
std::shared_ptr的控制块结构。这个控制块会包含实际的数据指针和至少一个
std::atomic（或者
std::atomic，取决于预期引用数量的最大值）作为引用计数器。下面是一个简化的实现思路和代码示例：
我们先定义一个管理类，它内部持有实际的数据和引用计数。
#include#include #include // For std::exchange template class AtomicSharedPtr { private: T* data_ptr; std::atomic * ref_count; // 使用原子类型管理引用计数 void decrement_and_check() { if (ref_count && ref_count->fetch_sub(1, std::memory_order_acq_rel) == 1) { // 当引用计数减到1（即即将变为0）时，说明当前是最后一个引用 delete data_ptr; delete ref_count; data_ptr = nullptr; ref_count = nullptr; } } public: // 默认构造函数 AtomicSharedPtr() : data_ptr(nullptr), ref_count(nullptr) {} // 接受裸指针的构造函数 explicit AtomicSharedPtr(T* ptr) : data_ptr(ptr) { if (data_ptr) { ref_count = new std::atomic (1); // 初始化计数为1 } else { ref_count = nullptr; } } // 拷贝构造函数 AtomicSharedPtr(const AtomicSharedPtr& other) noexcept : data_ptr(other.data_ptr), ref_count(other.ref_count) { if (ref_count) { ref_count->fetch_add(1, std::memory_order_relaxed); // 增加引用计数 } } // 移动构造函数 AtomicSharedPtr(AtomicSharedPtr&& other) noexcept : data_ptr(std::exchange(other.data_ptr, nullptr)), ref_count(std::exchange(other.ref_count, nullptr)) {} // 拷贝赋值运算符 AtomicSharedPtr& operator=(const AtomicSharedPtr& other) noexcept { if (this != &other) { // 避免自我赋值 decrement_and_check(); // 先释放当前持有的资源 data_ptr = other.data_ptr; ref_count = other.ref_count; if (ref_count) { ref_count->fetch_add(1, std::memory_order_relaxed); // 增加新资源的引用计数 } } return *this; } // 移动赋值运算符 AtomicSharedPtr& operator=(AtomicSharedPtr&& other) noexcept { if (this != &other) { // 避免自我赋值 decrement_and_check(); // 释放当前资源 data_ptr = std::exchange(other.data_ptr, nullptr); ref_count = std::exchange(other.ref_count, nullptr); } return *this; } // 析构函数 ~AtomicSharedPtr() { decrement_and_check(); } // 提供访问底层数据的方法 T* get() const noexcept { return data_ptr; } T& operator*() const noexcept { return *data_ptr; } T* operator->() const noexcept { return data_ptr; } // 获取当前引用计数（仅供调试或特殊场景，非线程安全读取） long use_count() const noexcept { return ref_count ? ref_count->load(std::memory_order_relaxed) : 0; } // 检查是否为空 explicit operator bool() const noexcept { return data_ptr != nullptr; } }; // 示例用法 struct MyData { int value; MyData(int v) : value(v) { std::cout << "MyData(" << value << ") constructed.\n"; } ~MyData() { std::cout << "MyData(" << value << ") destructed.\n"; } }; int main() { AtomicSharedPtr ptr1(new MyData(100)); std::cout << "ptr1 use_count: " << ptr1.use_count() << "\n"; // 1 { AtomicSharedPtr ptr2 = ptr1; // 拷贝构造 std::cout << "ptr1 use_count: " << ptr1.use_count() << "\n"; // 2 std::cout << "ptr2 use_count: " << ptr2.use_count() << "\n"; // 2 AtomicSharedPtr ptr3(new MyData(200)); ptr3 = ptr1; // 拷贝赋值 std::cout << "ptr1 use_count: " << ptr1.use_count() << "\n"; // 3 std::cout << "ptr3 use_count: " << ptr3.use_count() << "\n"; // 3 // ptr2, ptr3 离开作用域，引用计数减少 } // ptr2, ptr3 析构，计数变为1 std::cout << "ptr1 use_count after scope: " << ptr1.use_count() << "\n"; // 1 AtomicSharedPtr ptr4; ptr4 = std::move(ptr1); // 移动赋值 std::cout << "ptr4 use_count: " << ptr4.use_count() << "\n"; // 1 std::cout << "ptr1 is now empty: " << (ptr1 ? "false" : "true") << "\n"; // true // ptr4 离开作用域，MyData(100) 被析构 return 0; }
这里我们用了
fetch_add和
fetch_sub，它们是
std::atomic提供的原子操作，能保证在多线程环境下，计数器的增减操作是不可中断的。当
fetch_sub返回的值是1时，意味着在当前操作之后，计数器会变成0，这正是我们执行资源清理（
delete data_ptr; delete ref_count;）的时机。
立即学习“C++免费学习笔记（深入）”；
为什么传统的int
计数器在多线程环境下会失效？
这个问题，其实是多线程编程里一个很经典也很容易被忽视的陷阱。想象一下，如果我们在多线程环境中使用一个普通的
int变量作为引用计数器，比如
int ref_count;，然后用
ref_count++;或
ref_count--;来增减计数。表面上看，这好像很简单，不就是一条语句嘛。但实际上，在CPU层面，一个简单的
++操作并非是原子的。它通常会分解成至少三个步骤：
-
读取
ref_count
的当前值到寄存器。 - 修改 寄存器中的值（加1或减1）。
-
写入 寄存器中的新值回
ref_count
所在的内存地址。
设想一下，两个线程A和B同时尝试增加一个初始值为1的计数器：
-
时刻T1: 线程A读取
ref_count
，得到1。 -
时刻T2: 线程B也读取
ref_count
，得到1。 -
时刻T3: 线程A将它寄存器中的1加1，得到2，然后将2写入
ref_count
。此时ref_count
变为2。 -
时刻T4: 线程B将它寄存器中的1加1，得到2，然后将2写入
ref_count
。此时ref_count
仍然是2。
结果是，我们期望的
ref_count应该是3（1 + 1 + 1），但实际却是2。这就是所谓的“竞态条件”（Race Condition）。在引用计数场景下，这种错误可能导致：
- 内存泄漏： 如果计数器没有正确地增加，某个线程可能误以为自己不是最后一个引用者，导致对象永远不会被删除。
- 过早释放/双重释放： 如果计数器没有正确地减少，可能在还有其他线程在使用对象时，某个线程错误地认为自己是最后一个引用者，提前删除了对象，导致其他线程访问到已释放的内存（Use-After-Free）。更糟糕的是，如果多个线程都认为自己是最后一个，就会出现双重释放（Double-Free），这通常会导致程序崩溃。
std::atomic正是为了解决这类问题而生。它通过底层硬件指令（如x86上的
LOCK CMPXCHG指令前缀）或编译器屏障等机制，确保对原子变量的读、写、修改-写等操作是不可分割的，从而避免了上述的竞态条件。
std::atomic
在引用计数中的内存序选择有什么讲究？
内存序（Memory Order）是
std::atomic一个非常深入且关键的概念，它决定了原子操作与其他内存操作的可见性（visibility）和顺序性（ordering）。在引用计数中，选择合适的内存序至关重要，它关系到程序的正确性和性能。
对于引用计数，我们主要关注两种操作：增加引用计数和减少引用计数。
-
增加引用计数（
fetch_add
）： 当一个AtomicSharedPtr
被拷贝时，引用计数会增加。这个操作通常可以使用std::memory_order_relaxed
。为什么呢？因为增加引用计数本身，并不需要同步其他内存操作。你只是说“又多了一个人关注这个对象”，这个信息不需要立即同步给所有线程，也不影响数据本身的访问顺序。只要最终计数器是正确的，且没有竞态条件，就足够了。relaxed
是最宽松的内存序，性能开销最小。ref_count->fetch_add(1, std::memory_order_relaxed);
-
减少引用计数（
fetch_sub
）和条件删除： 这是最复杂的部分，因为它涉及到对象的生命周期管理。当引用计数减少到1（意味着当前操作后会变为0）时，就需要删除被管理的对象。这个删除操作必须是可见的，并且要确保所有在删除前对对象进行的写入操作，都能被执行删除的线程看到。反之，删除操作也必须对所有后续尝试访问该对象的线程可见（虽然它们不应该再访问了）。-
std::memory_order_acq_rel
(Acquire-Release): 这是在引用计数递减并检查是否为最后一个引用时，一个非常好的通用选择。fetch_sub(1, std::memory_order_acq_rel)
包含了两个语义：-
Release语义： 确保当前线程在执行
fetch_sub
之前的所有内存写入操作，对任何后续（通过acquire
操作）观察到引用计数变为0的线程都是可见的。这意味着，如果我修改了对象的数据，然后减少了引用计数，那么当计数变为0时，执行删除的线程会看到我修改后的数据。 -
Acquire语义： 确保当前线程在
fetch_sub
之后，能够看到所有在之前（通过release
操作）对引用计数进行操作的线程所做的内存写入。这对于确保在删除对象之前，能够看到所有对对象状态的最终修改是重要的。
简单来说，
acq_rel
在引用计数递减并判断是否为零时，建立了一个完整的内存屏障，确保了内存操作的顺序和可见性，避免了数据不一致和过早删除的风险。 -
Release语义： 确保当前线程在执行
if (ref_count->fetch_sub(1, std::memory_order_acq_rel) == 1) { // 此时，确保了所有之前对data_ptr的写入都已完成并可见 delete data_ptr; delete ref_count; } -
虽然
std::shared_ptr内部的实现可能比这更复杂，考虑了更多极端情况和性能优化，但对于我们自己实现的基本引用计数，
relaxed用于增，
acq_rel用于减并判断删除，是一个既安全又合理的选择。过度使用更强的内存序（如
seq_cst）会带来不必要的性能开销，而使用过弱的内存序则可能导致难以调试的并发错误。
自定义引用计数类时有哪些常见陷阱和最佳实践？
自定义引用计数类，尤其是像
std::shared_ptr那样功能完备的，远比看起来要复杂。它不仅是计数器的增减，还涉及资源管理、异常安全等多个方面。
常见陷阱：
-
循环引用（Circular References）： 这是最经典的问题。如果对象A持有一个
AtomicSharedPtr
，同时对象B又持有一个AtomicSharedPtr
，那么当这两个对象都不再被外部引用时，它们的引用计数永远不会降到零，因为它们互相持有对方的引用。这会导致内存泄漏。std::shared_ptr
通过引入std::weak_ptr
来解决这个问题，weak_ptr
不增加引用计数，只提供对对象的弱引用。自定义实现时，也需要考虑类似的弱引用机制。 -
异常安全（Exception Safety）： 在构造函数中分配资源后，如果后续操作抛出异常，引用计数或原始指针可能没有被正确初始化或清理，导致内存泄漏。例如，
new MyData(args)
成功，但new std::atomic
失败，那么(1) MyData
的实例就泄漏了。使用try-catch
块或更巧妙的设计（如先分配计数器，再分配数据）可以缓解。 -
裸指针的生命周期管理： 如果将一个已经由其他智能指针管理的裸指针传递给自定义的
AtomicSharedPtr
，或者多次将同一个裸指针传递给不同的AtomicSharedPtr
实例，都可能导致双重释放。智能指针的原则是“一个资源只由一个智能指针家族管理”。 - 不正确的内存序选择： 前面已经详细讨论过，选择错误的内存序会导致竞态条件、内存可见性问题，进而引发数据损坏或程序崩溃。
-
自我赋值（Self-Assignment）： 在拷贝赋值运算符中，忘记检查
if (this != &other)
可能导致在释放当前资源后，尝试从一个已经被释放的源（other
）复制数据，从而引发崩溃。 -
析构函数中的裸指针操作： 在析构函数中直接
delete data_ptr
而没有检查data_ptr
是否为空，或者在ref_count
已经为nullptr
时尝试访问它，都可能导致问题。虽然我们的示例中通过decrement_and_check
函数统一处理，但如果逻辑分散，很容易出错。
最佳实践：
-
优先使用
std::shared_ptr
和std::weak_ptr
： 这是最重要的一条。C++标准库提供的智能指针经过了严格的测试和优化，覆盖了绝大多数使用场景。除非有非常特殊的需求（比如嵌入式系统、高度定制的内存分配策略等），否则不要重复造轮子。 -
封装和RAII（Resource Acquisition Is Initialization）： 将引用计数和被管理的数据封装在一个类中（就像
AtomicSharedPtr
那样），并严格遵循RAII原则。在构造函数中获取资源（增加计数），在析构函数中释放资源（减少计数并可能删除对象）。这确保了资源生命周期与对象生命周期绑定，减少了手动管理的错误。 -
分离控制块： 像
std::shared_ptr
一样，将引用计数器和自定义删除器等元数据放在一个单独的“控制块”中，与实际的数据指针分开。这样，即使AtomicSharedPtr
本身被移动或拷贝，控制块的生命周期也能独立管理，避免了重复的计数器分配/释放。 -
明确内存序： 对
std::atomic
操作的内存序要有清晰的理解。对于引用计数，通常std::memory_order_relaxed
用于增加，而std::memory_order_acq_rel
用于减少和条件删除，能提供良好的平衡。 - 彻底测试： 自定义并发数据结构时，务必在多线程环境下进行充分的压力测试和边缘情况测试。使用像ThreadSanitizer (TSan) 这样的工具可以帮助发现难以察觉的竞态条件和内存问题。
- 提供所有必要的特殊成员函数： 确保实现拷贝构造、
