std::shared_ptr通过引用计数机制自动管理内存，每个实例共享一个控制块，内含强弱引用计数、对象指针、自定义删除器等，确保对象在无拥有者时自动析构；循环引用需用std::weak_ptr打破；std::make_shared提升性能与异常安全。
std::shared_ptr
通过一种叫做“引用计数”的机制来管理它所指向的动态分配对象的内存。简单来说，它会记录有多少个
shared_ptr
实例共同拥有同一个对象。每当一个新的
shared_ptr
指向这个对象时，计数就增加；每当一个
shared_ptr
实例被销毁或不再指向这个对象时，计数就减少。当这个引用计数归零时，就意味着没有
shared_ptr
再需要这个对象了，
shared_ptr
会自动地释放掉它所管理的内存。
解决方案
在我看来，
std::shared_ptr
是C++现代内存管理中最优雅的设计之一。它把复杂的资源生命周期管理简化成了一个几乎“隐形”的机制，让开发者能更专注于业务逻辑，而不是频繁地与
new
和
delete
打交道。
它的核心工作原理可以这样理解：每个
std::shared_ptr
实例，除了持有指向实际对象的指针外，还共同引用一个“控制块”（Control Block）。这个控制块才是引用计数的真正所在地。
当一个
shared_ptr
被创建或复制时（例如通过拷贝构造函数或赋值操作），它会与现有的
shared_ptr
共享同一个控制块，并且控制块中的“强引用计数”（strong reference count）会递增。这个强引用计数代表了有多少个
shared_ptr
实例正在“拥有”这个对象。
立即学习“C++免费学习笔记（深入）”；
反之，当一个
shared_ptr
实例被销毁（比如它离开了作用域），或者被重新赋值去管理另一个对象，又或者被
reset()
，那么它所关联的控制块中的强引用计数就会递减。
关键点来了：一旦这个强引用计数降到零，
std::shared_ptr
就知道这个对象不再被任何拥有者所需要了。此时，它会负责调用对象的析构函数，并释放对象所占用的内存。如果这个控制块还包含了“弱引用计数”（weak reference count，用于
std::weak_ptr
），并且弱引用计数也归零了，那么控制块本身的内存也会被释放。
这种机制有效地避免了手动内存管理中常见的“忘记
delete
”导致的内存泄漏，以及“重复
delete
”造成的程序崩溃。它把所有权的概念清晰化，让资源管理变得自动化且安全。
std::shared_ptr
std::shared_ptr
的控制块里到底藏了些什么？
说到
shared_ptr
的魔法，我觉得它的控制块（Control Block）是真正值得深挖的地方。它可不仅仅是简单地存了个数字那么简单。这个小小的结构体，是
shared_ptr
能如此智能地管理内存的关键。
通常，一个控制块至少会包含以下几个核心元素：
强引用计数（Strong Reference Count）：这就是我们一直在说的，有多少个
std::shared_ptr
实例正在“拥有”这个对象。每当一个
shared_ptr
被创建或复制，这个计数就加一；当
shared_ptr
被销毁或重置，这个计数就减一。当它归零时，
shared_ptr
会触发对象的析构和内存释放。这是对象生命周期管理的主宰。
弱引用计数（Weak Reference Count）：这个是为
std::weak_ptr
准备的。
weak_ptr
不拥有对象，所以它不会增加强引用计数。但它会增加弱引用计数。即使强引用计数降到零，只要弱引用计数不为零，控制块本身就不会被销毁。这允许
weak_ptr
在对象被销毁后仍然能判断对象是否存活，并安全地返回空指针。
指向被管理对象的原始指针：控制块需要知道它到底管理的是哪个对象。这个指针就是指向我们用
new
或
make_shared
创建的那个实际对象。
自定义删除器（Custom Deleter）：这是一个可选但非常强大的特性。有时，我们管理的资源不是通过
new
分配的，或者需要特殊的清理逻辑（比如文件句柄、数据库连接、C风格的
malloc
分配的内存）。
shared_ptr
允许你在创建时传入一个函数对象或lambda表达式作为删除器。当强引用计数归零时，
shared_ptr
会调用这个自定义删除器来释放资源，而不是简单地调用
delete
。这极大地扩展了
shared_ptr
的应用范围。
自定义分配器（Custom Allocator）：同样是可选的，用于在创建对象或控制块时使用特定的内存分配策略。这在某些高性能或内存受限的场景下会很有用。
所以，控制块远不止一个计数器。它是一个包含了所有必要信息和回调的枢纽，确保了对象生命周期的正确管理，并提供了高度的灵活性。
为什么
std::shared_ptr
std::shared_ptr
能解决循环引用问题，但又不能完全避免？
这是一个非常经典的问题，也是
shared_ptr
使用中一个常见的陷阱。我觉得理解这一点，是真正掌握智能指针的关键一步。
std::shared_ptr
本身确实无法解决循环引用问题。当两个对象通过
shared_ptr
相互持有对方时，它们会形成一个“闭环”。比如，对象A有一个
shared_ptr
指向B，对象B有一个
shared_ptr
指向A。这时，A的强引用计数至少是1（被B持有），B的强引用计数至少是1（被A持有）。即使外部所有指向A和B的
shared_ptr
都销毁了，A和B的强引用计数也永远不会降到零，因为它们彼此互相持有。结果就是，这两个对象永远不会被析构，内存也就泄漏了。
这就像两个人都握着对方的手，谁都不肯先松开，结果就是谁也走不了。
那么，我们怎么解决呢？答案是引入
std::weak_ptr
。
weak_ptr
被称为“弱引用”或“非拥有引用”，它扮演的角色是“观察者”而不是“拥有者”。
weak_ptr
的妙处在于：
它指向一个由
shared_ptr
管理的对象，但它不会增加对象的强引用计数。它允许你检查所指向的对象是否仍然存活。如果对象已经被销毁，
weak_ptr
会知道这一点。你可以尝试通过
weak_ptr::lock()
方法获取一个
shared_ptr
。如果对象还存活，
lock()
会返回一个有效的
shared_ptr
（并临时增加强引用计数）；如果对象已被销毁，它会返回一个空的
shared_ptr
。
所以，解决循环引用的策略就是：在构成循环引用的两个对象中，让其中一个指针变成
std::weak_ptr
。
举个例子，假设我们有
Parent
和
Child
两个类，
Parent
包含
shared_ptr
，
Child
也需要一个指向
Parent
的引用。如果
Child
也用
shared_ptr
，那就会形成循环。正确的做法是：
Parent
拥有
Child
（
shared_ptr
），而
Child
观察
Parent
（
weak_ptr
）。这样，
Child
对
Parent
的引用不会增加
Parent
的强引用计数，从而打破了循环。当所有外部对
Parent
的
shared_ptr
都销毁后，
Parent
的强引用计数会归零，它会被正常析构，然后
Parent
的析构函数会销毁它所持有的
Child
对象。
所以，
std::shared_ptr
本身并不能自动避免循环引用，它只是提供了一个工具——
std::weak_ptr
——来让我们手动解决这个问题。这要求我们在设计类关系时，需要仔细思考对象之间的所有权关系，哪些是“拥有”，哪些只是“观察”。
std::make_shared
std::make_shared
比直接
new
和
shared_ptr
构造有什么优势？
这其实是我在日常开发中，几乎总是推荐使用
std::make_shared
的原因。它不仅仅是代码看起来更简洁，背后还有实实在在的性能和安全性考量。
当你这样做时：
std::shared_ptr ptr(new MyClass());
这里发生了两次独立的内存分配：
new MyClass()
：为
MyClass
对象本身分配内存。
std::shared_ptr(...)
：为
shared_ptr
的控制块分配内存。
而当你使用
std::make_shared
时：
auto ptr = std::make_shared();
这里通常只发生一次内存分配。
std::make_shared
被设计成可以一次性分配足够的内存，来同时容纳
MyClass
对象和
shared_ptr
所需的控制块。
这种“一次分配”带来的优势是多方面的：
性能提升：减少了一次系统调用（内存分配通常是开销较大的操作），这在大量创建
shared_ptr
的场景下，可以带来显著的性能提升。更好的缓存局部性：对象本身和它的控制块在内存中是紧邻的，这有助于CPU缓存的利用率，提升程序的整体性能。异常安全：这是一个非常关键的优势。考虑一个函数调用：
some_function(std::shared_ptr(new MyClass()), another_function());
在C++标准中，函数参数的求值顺序是不确定的。编译器可能按以下顺序执行：a.
new MyClass()
b.
another_function()
c.
std::shared_ptr(...)
如果
new MyClass()
成功了，但在
std::shared_ptr
构造完成之前，
another_function()
抛出了一个异常，那么
new
出来的
MyClass
对象将永远不会被
shared_ptr
接管，从而导致内存泄漏。而使用
std::make_shared
：
some_function(std::make_shared(), another_function());
std::make_shared
会原子性地完成对象和控制块的分配与构造。如果它成功了，那么
shared_ptr
就完全拥有了对象。如果
another_function()
抛出异常，
make_shared
创建的对象也能被正确清理，避免了泄漏。
所以，除非你有非常特殊的需求（比如需要自定义删除器来处理非
new
分配的内存，或者需要一个特殊的分配器只用于对象本身而不用在控制块上），我个人总是倾向于使用
std::make_shared
。它是一个简单但强大的优化和安全实践。
以上就是C++的std::shared_ptr是如何通过引用计数来管理内存的的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1474944.html
微信扫一扫 
支付宝扫一扫 
