C++的std::shared_ptr是如何通过引用计数来管理内存的

P粉602998670

发布时间：2025-09-07 10:16:02

430人浏览过

来源于php中文网

原创

std::shared_ptr通过引用计数机制自动管理内存，每个实例共享一个控制块，内含强弱引用计数、对象指针、自定义删除器等，确保对象在无拥有者时自动析构；循环引用需用std::weak_ptr打破；std::make_shared提升性能与异常安全。

c++的std::shared_ptr是如何通过引用计数来管理内存的

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

的控制块里到底藏了些什么？

说到

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）：同样是可选的，用于在创建对象或控制块时使用特定的内存分配策略。这在某些高性能或内存受限的场景下会很有用。

Metafox企业内容管理系统0.9.1
Metafox 是一个企业内容管理系统，使用一个特别的模板系统，你可通过一些特定的设计和代码来轻松创建 Web 网站，内容存储在 SQL 关系数据库，通过 Web 进行管理，简单、快速而且高效。 Metafox 0.9.1 发布，该版本改用一种更棒的 URL 风格，实现了 RSS 源（可包含远端网站内容到 Metafox 段中），重定向老的访问密钥到新的密钥，增加 RotateAntispam 技

下载

所以，控制块远不止一个计数器。它是一个包含了所有必要信息和回调的枢纽，确保了对象生命周期的正确管理，并提供了高度的灵活性。

为什么

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

比直接

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
```
创建的对象也能被正确清理，避免了泄漏。