shared_ptr通过独立控制块实现引用计数，控制块包含指向对象的指针、强弱引用计数及删除器；多个shared_ptr共享同一控制块，构造、拷贝时增加强引用计数，析构或赋值时减少，归零则销毁对象；weak_ptr通过弱引用计数观察对象而不影响其生命周期；控制块支持自定义删除器与非侵入式管理，解耦计数与对象；多线程下引用计数操作为原子操作，保证线程安全；简化实现需注意原子性、控制块生命周期、自赋值检查与异常安全；相比unique_ptr的独占所有权，shared_ptr适用于共享所有权场景，但有性能开销。
C++中
shared_ptr
实现引用计数的核心机制，在于它将对象所有权的管理与实际对象的生命周期解耦，通过一个独立的“控制块”（Control Block）来维护引用计数。这个控制块通常包含指向实际对象的指针、强引用计数（
shared_ptr
的数量）和弱引用计数（
weak_ptr
的数量），以及可能的自定义删除器和分配器。每当一个
shared_ptr
被创建、拷贝或赋值时，其内部的强引用计数会相应地增加；当一个
shared_ptr
被销毁或重新赋值时，强引用计数则会减少。当强引用计数归零时，
shared_ptr
便会负责销毁它所管理的对象。
解决方案
shared_ptr
的引用计数机制主要依赖于以下几个关键组件和操作：
控制块（Control Block）：
这是一个动态分配的辅助数据结构，与被管理对象（Managed Object）生命周期独立。它至少包含：
T* ptr
：指向实际被管理对象的裸指针。
std::atomic_long shared_count
：强引用计数，记录有多少个
shared_ptr
实例正在引用该对象。
std::atomic_long weak_count
：弱引用计数，记录有多少个
weak_ptr
实例正在观察该对象。可选的自定义删除器（
Deleter
）和分配器（
Allocator
）。一个被多个
shared_ptr
共同管理的对象，只对应一个控制块。
shared_ptr
实例：
立即学习“C++免费学习笔记（深入）”；
每个
shared_ptr
实例内部都存储两个指针：一个是指向被管理对象的裸指针（
T*
）。另一个是指向其对应的控制块的指针（
ControlBlock*
）。
引用计数的生命周期管理：
构造函数：当从一个裸指针或另一个
shared_ptr
构造时，如果这是第一个
shared_ptr
，会创建一个新的控制块，将强引用计数初始化为1，弱引用计数初始化为0。如果是拷贝构造，则简单地将源
shared_ptr
的控制块指针和对象指针复制过来，并将控制块中的强引用计数原子性地增加1。拷贝赋值运算符：首先，它会递减当前
shared_ptr
所管理对象的强引用计数。接着，它会复制源
shared_ptr
的控制块指针和对象指针，并将新管理对象的强引用计数原子性地增加1。如果旧的强引用计数归零，则会检查并可能删除旧的对象。析构函数：当
shared_ptr
实例被销毁时，它会原子性地递减其控制块中的强引用计数。如果强引用计数递减后变为0：它会调用自定义删除器（如果存在）或
delete
操作符来销毁被管理对象。然后，它会检查弱引用计数。如果弱引用计数也为0，说明没有任何
weak_ptr
还在观察这个控制块，此时控制块本身也会被销毁。如果强引用计数不为0，则对象和控制块都保持不变。
weak_ptr
的作用：
weak_ptr
在构造时，会增加控制块中的弱引用计数。
weak_ptr
的析构会减少弱引用计数。
weak_ptr
不会影响对象的生命周期，它只是一个观察者。当强引用计数归零，对象被销毁后，
weak_ptr
通过
lock()
方法尝试获取
shared_ptr
会失败（返回空的
shared_ptr
）。
这种设计确保了在多个
shared_ptr
实例共同拥有一个对象时，对象的生命周期能够被正确地管理，并且在最后一个
shared_ptr
离开作用域时，对象才会被安全地销毁。
shared_ptr
shared_ptr
为何需要一个独立的控制块（Control Block）来管理引用计数？
在我看来，
shared_ptr
采用独立控制块的设计，是其灵活性和强大功能的核心所在，并非仅仅是为了存储引用计数那么简单。
首先，它实现了引用计数与被管理对象的解耦。想象一下，如果引用计数直接内嵌在被管理对象内部，那么所有被
shared_ptr
管理的对象都必须是可修改的，并且必须在堆上分配。但实际应用中，我们可能需要管理一个栈上的对象（虽然不常见，但理论上可能），或者一个由C风格API返回的内存块，甚至是一个自定义资源（如文件句柄、数据库连接）。这些对象可能没有地方存放引用计数，或者它们本身就不是通过
new
分配的。通过一个外部的控制块，
shared_ptr
能够以统一的方式管理各种类型的资源，无论它们是如何分配的，或者它们是否包含内部状态。这是一种非常优雅的抽象。
其次，支持自定义删除器和分配器。控制块是存储这些自定义逻辑的理想场所。比如，你可能需要用
free()
而不是
delete
来释放C风格的内存，或者需要关闭一个文件句柄。这些操作与对象的类型紧密相关，但与
shared_ptr
本身的类型无关。将这些信息放在控制块中，允许
shared_ptr
在析构时执行正确的清理操作，极大地增强了其通用性。
再者，
weak_ptr
的实现离不开控制块。
weak_ptr
的目的是在不延长对象生命周期的情况下观察对象。它通过弱引用计数来判断对象是否仍然存活。当所有
shared_ptr
都已销毁，强引用计数归零，对象被删除后，
weak_ptr
依然可以知道对象已经不存在了，因为控制块仍然存在（只要还有
weak_ptr
在观察），并且其中的强引用计数已经为零。如果控制块与对象一同销毁，
weak_ptr
将无法安全地判断对象状态，甚至可能导致悬空指针。这是一种精妙的设计，它允许我们在不引入循环引用风险的情况下，实现复杂的对象依赖关系。
从内存布局和性能角度看，虽然引入控制块会增加一点点内存开销和间接性，但它避免了对被管理对象本身的侵入式修改，这在很多场景下是不可接受的。而且，对于同一个对象，无论有多少个
shared_ptr
指向它，都只对应一个控制块，这在一定程度上也避免了冗余。在我看来，这种设计上的权衡是值得的，它赋予了
shared_ptr
无与伦比的灵活性和健壮性。
shared_ptr
shared_ptr
的引用计数在多线程环境下是如何保证安全的？
多线程环境下，引用计数的安全性是
shared_ptr
设计中一个至关重要的考量，也是其内部复杂性所在。简单地使用一个
int
类型的计数器进行增减操作是绝对不够的，因为这些操作并非原子性的，可能导致竞态条件（race condition）。
shared_ptr
通过使用原子操作（Atomic Operations）来确保引用计数的线程安全。C++标准库通常会利用
std::atomic
系列类型（如
std::atomic_long
）或底层平台提供的原子指令（如
fetch_add
,
fetch_sub
等）来实现引用计数的增减。
具体来说：
原子性增减：当一个
shared_ptr
被拷贝或析构时，它对控制块中的强引用计数（
shared_count
）和弱引用计数（
weak_count
）的增减操作，都是通过原子指令完成的。这意味着，即使多个线程同时尝试修改同一个计数器，这些操作也会以一种互不干扰、线性化的方式执行，保证了计数器的值始终是正确的，不会出现丢失更新或错误读取的情况。例如，
std::atomic_long::fetch_add(1)
操作会原子性地读取当前值，将其加1，然后写回新值，整个过程不可中断。
内存顺序（Memory Ordering）：除了原子操作本身，现代处理器为了性能优化，可能会重排指令的执行顺序。这可能导致在一个线程中对共享变量的修改，在另一个线程中无法立即看到，或者看到的是旧值。
std::atomic
类型通常会伴随默认的内存顺序（如
memory_order_seq_cst
或
memory_order_acquire
/
release
），确保在引用计数操作前后，相关的内存操作（如对象的构造或析构）能够被正确地同步和可见。这保证了当引用计数达到0并触发对象删除时，所有线程都能看到这个事件，并且被删除对象的状态在删除前是正确的。
性能考量：原子操作通常比非原子操作要慢，因为它们可能涉及CPU缓存同步、内存屏障（memory barrier）等开销。然而，这种开销是保证多线程环境下正确性的必要代价。
shared_ptr
的设计者们在性能和正确性之间找到了一个平衡点。在大多数情况下，引用计数的增减频率相对较低，因此原子操作带来的额外开销是可以接受的。当然，如果在一个极其性能敏感的循环中频繁地创建和销毁
shared_ptr
，可能需要重新评估设计，但这通常不是
shared_ptr
的典型使用场景。
在我看来，
shared_ptr
的这种线程安全机制是其成为C++11及以后版本中不可或缺的智能指针的关键原因之一。它极大地简化了多线程编程中资源管理的问题，让开发者可以更专注于业务逻辑，而不是疲于应对复杂的锁机制和竞态条件。
如何自己动手实现一个简化的
shared_ptr
shared_ptr
？需要注意哪些关键点？
自己动手实现一个简化的
shared_ptr
是理解其内部机制的绝佳实践。这会让你深刻体会到标准库实现的精妙与复杂。下面我将给出一个简化的实现框架，并强调一些关键点。
首先，我们需要一个独立的控制块（
ControlBlock
）类来存储引用计数和可能的删除器。
#include // 用于线程安全的引用计数#include #include // 用于自定义删除器// 简化的ControlBlockclass ControlBlockBase {public: std::atomic_long shared_count; // 强引用计数 std::atomic_long weak_count; // 弱引用计数 ControlBlockBase() : shared_count(1), weak_count(0) {} virtual ~ControlBlockBase() = default; // 纯虚函数，用于销毁被管理对象 virtual void destroy_object() = 0;};template<typename T, typename Deleter = std::default_delete>class ControlBlock : public ControlBlockBase {public: T* ptr; Deleter deleter; ControlBlock(T* p, Deleter d = Deleter()) : ptr(p), deleter(d) {} void destroy_object() override { if (ptr) { deleter(ptr); // 使用自定义删除器或默认删除器 ptr = nullptr; // 避免二次删除 } }};
接下来是
MySharedPtr
类：
templateclass MySharedPtr {private: T* data_ptr; ControlBlockBase* control_block; void release() { if (control_block) { // 原子递减强引用计数 if (control_block->shared_count.fetch_sub(1) == 1) { // 如果强引用计数归零，销毁对象 control_block->destroy_object(); // 如果弱引用计数也归零，销毁控制块 if (control_block->weak_count.load() == 0) { delete control_block; control_block = nullptr; } } } }public: // 默认构造函数 MySharedPtr() : data_ptr(nullptr), control_block(nullptr) {} // 裸指针构造函数 template explicit MySharedPtr(U* p) : data_ptr(p) { if (p) { control_block = new ControlBlock(p); } else { control_block = nullptr; } } // 带自定义删除器的裸指针构造函数 template MySharedPtr(U* p, Deleter d) : data_ptr(p) { if (p) { control_block = new ControlBlock(p, d); } else { control_block = nullptr; } } // 拷贝构造函数 MySharedPtr(const MySharedPtr& other) noexcept : data_ptr(other.data_ptr), control_block(other.control_block) { if (control_block) { control_block->shared_count.fetch_add(1); // 原子递增强引用计数 } } // 移动构造函数 MySharedPtr(MySharedPtr&& other) noexcept : data_ptr(other.data_ptr), control_block(other.control_block) { other.data_ptr = nullptr; other.control_block = nullptr; } // 拷贝赋值运算符 MySharedPtr& operator=(const MySharedPtr& other) noexcept { if (this != &other) { // 处理自赋值 release(); // 释放当前资源 data_ptr = other.data_ptr; control_block = other.control_block; if (control_block) { control_block->shared_count.fetch_add(1); // 原子递增强引用计数 } } return *this; } // 移动赋值运算符 MySharedPtr& operator=(MySharedPtr&& other) noexcept { if (this != &other) { // 处理自赋值 release(); // 释放当前资源 data_ptr = other.data_ptr; control_block = other.control_block; other.data_ptr = nullptr; other.control_block = nullptr; } return *this; } // 析构函数 ~MySharedPtr() { release(); } // 解引用运算符 T& operator*() const noexcept { return *data_ptr; } // 箭头运算符 T* operator->() const noexcept { return data_ptr; } // 获取裸指针 T* get() const noexcept { return data_ptr; } // 获取引用计数 long use_count() const noexcept { return control_block ? control_block->shared_count.load() : 0; } // 检查是否拥有对象 explicit operator bool() const noexcept { return data_ptr != nullptr; }};// 辅助函数：make_shared (简化版，不处理完美转发和内存优化)templateMySharedPtr make_my_shared(Args&&... args) { // 实际的make_shared会一次性分配对象和控制块的内存，这里简化处理 return MySharedPtr(new T(std::forward(args)...));}
需要注意的关键点：
原子操作：所有对
shared_count
和
weak_count
的增减操作都必须使用
std::atomic
，这是保证多线程安全的核心。否则，在并发环境下会出现严重的竞态条件和数据损坏。控制块的生命周期：控制块的销毁时机是关键。它只有在强引用计数和弱引用计数都归零时才能被销毁。
ControlBlockBase
在这里作为基类，确保无论
T
和
Deleter
是什么，我们都能通过多态调用
destroy_object()
。自赋值检查：在拷贝赋值运算符和移动赋值运算符中，
if (this != &other)
是必不可少的，用于防止对象自赋值导致的问题（例如，先释放自己的资源，然后从自己那里复制，结果资源已经没了）。异常安全：上述简化实现并未完全考虑异常安全。一个健壮的
shared_ptr
在构造新对象或控制块失败时，需要确保不会泄露资源。标准库的
std::make_shared
就是为了提供更好的异常安全和性能而设计的，它能一次性分配对象和控制块的内存。自定义删除器：通过模板参数
Deleter
和
std::function
，我们可以支持各种自定义的资源释放逻辑，这极大地扩展了
shared_ptr
的应用范围。
weak_ptr
的缺失：这个简化版本没有实现
MyWeakPtr
。如果实现
MyWeakPtr
，它将持有
ControlBlockBase*
指针，并在构造时增加
weak_count
，析构时减少
weak_count
。
MyWeakPtr::lock()
方法会检查
shared_count
是否大于0，如果是，则原子性地增加
shared_count
并返回一个
MySharedPtr
。类型擦除：
ControlBlockBase
和模板化的
ControlBlock
是实现类型擦除的一种方式，使得
MySharedPtr
可以管理任意类型的对象，而不需要在
MySharedPtr
类中直接知道
T
的具体类型来调用删除器。
通过这个练习，你会发现标准库的
std::shared_ptr
远比我们想象的要复杂和精巧，它在性能、线程安全、异常安全和灵活性之间做到了极佳的平衡。
shared_ptr
shared_ptr
与
unique_ptr
、
weak_ptr
之间的关系与选择考量是什么？
在C++智能指针家族中，
shared_ptr
、
unique_ptr
和
weak_ptr
各自扮演着独特的角色，它们共同构成了C++资源管理的核心工具。理解它们之间的关系和各自的适用场景，是写出高效、安全且易于维护的C++代码的关键。
1.
unique_ptr
：独占所有权
关系：
unique_ptr
代表着独占所有权。一个资源在任何时刻只能被一个
unique_ptr
管理。当
unique_ptr
被销毁时，它所管理的资源也会被销毁。它不支持拷贝，但支持移动语义，这意味着所有权可以从一个
unique_ptr
转移到另一个
unique_ptr
。选择考量：明确的单一所有者：当你确定一个资源只有一个所有者，并且这个所有者的生命周期就是资源的生命周期时，
unique_ptr
是首选。例如，函数内部创建的对象，或者类成员变量，其生命周期与包含它的函数或类实例绑定。性能优先：
unique_ptr
没有引用计数，因此其开销非常小，几乎与裸指针相当，只在析构时有一次函数调用（删除器）。如果你不需要共享所有权，
unique_ptr
是性能最优的选择。自定义删除器：
unique_ptr
也支持自定义删除器，但与
shared_ptr
不同，删除器的类型是
unique_ptr
类型的一部分，这使得它在编译时就能确定
以上就是C++如何实现shared_ptr引用计数机制的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1475733.html
微信扫一扫 
支付宝扫一扫 
