C++ shared_ptr 智能指针：引用计数、循环引用与线程安全实践

1. 从裸指针的痛说起：shared_ptr 到底解决了什么问题

刚入行那会儿，我对智能指针是有点抗拒的。理由很朴素：new和delete成对出现，代码读起来清清楚楚，为什么要引入一堆模板类把简单的事情搞复杂？直到有一次排查一个线上服务的内存泄漏，整整两天时间，最后定位到是一段异常分支里漏了delete——那一刻我才真正理解，裸指针的问题不在于"能不能管好"，而在于"人总会犯错"，而内存泄漏的代价往往在几个月后才爆发。

shared_ptr是 C++11 引入的共享所有权智能指针，头文件是<memory>。它要解决的核心问题只有一个：当一块堆内存可能被多个对象或函数同时持有、且谁也无法确定自己是不是最后一个使用者时，怎么保证这块内存恰好被释放一次。传统的裸指针做不到这一点，你只能靠约定——"这块内存谁申请谁释放"或者"使用者不能超过申请者的生命周期"——而约定在跨模块、跨线程、异步回调的场景下几乎必然被打破。

举几个大家肯定都遇到过的场景。一个网络连接对象，被业务逻辑层、日志模块、心跳检测定时器同时引用，任何一个模块先退出都可能把连接给关了；一棵树形结构里，父节点持有子节点，子节点又需要反向访问父节点做状态上报，如果两边都用unique_ptr就会形成循环依赖，内存永远释放不掉；一个异步任务提交到线程池，主线程早就返回了，任务回调还在用捕获的数据。这些场景的共同特征就是所有权是模糊的、共享的、动态变化的，shared_ptr就是为这种模糊性量身定做的。

它的核心机制是引用计数（reference count）。每块被shared_ptr管理的内存，都额外带一个计数器，记录当前有多少个shared_ptr指向它。拷贝一个shared_ptr，计数加一；析构或重置一个shared_ptr，计数减一；当计数归零，说明再也没有人持有这块内存了，此时自动调用删除器释放。这个过程对使用者完全透明，你不需要在任何地方手写delete。

不过这里有个关键认知，很多人学了半年都没转过弯来：shared_ptr本身是一个对象，它的拷贝是有成本的。它的 sizeof 通常是裸指针的两倍（一个指向对象，一个指向控制块），拷贝时的引用计数增减是原子操作，比普通整数自增要慢一个数量级。所以"到处都用shared_ptr"绝对不是好习惯，它的定位应该是确实需要共享所有权的场景，而默认的、表示"独占"的语义，应该优先考虑unique_ptr。

那么这篇文章适合谁看？如果你刚学完 C++ 基础语法，正被各种智能指针的用法搞晕，这篇能帮你把shared_ptr的用法和原理一次理顺；如果你已经用了几年但总觉得心里没底——比如不确定make_shared和new到底差在哪、不知道循环引用怎么破、不明白线程安全到底安全在哪——这篇应该能把那些模糊的地带一个个填上。我会从最基础的用法讲起，一路讲到引用计数的内存布局、控制块的实现、循环引用的成因和破解，最后给出我自己在项目中踩过的坑和常用的排查手段。

2. 语法层用法全解：从创建到销毁的完整链路

2.1 创建 shared_ptr 的三种方式与选型逻辑

创建shared_ptr的方式主要有三种，每一种背后的语义和开销都不一样，选错了要么浪费性能，要么埋下隐患。

第一种是裸指针直接构造：

std::shared_ptr<Widget> sp(new Widget());

这种写法能用，但有个致命问题：new Widget()这个表达式先执行，分配了内存、构造了对象；然后才把裸指针交给shared_ptr的构造函数，此时shared_ptr才会去分配控制块。这两个步骤之间如果发生异常（比如构造函数本身抛异常属于另一回事，这里是说控制块分配失败），那块已经分配好的Widget内存就泄漏了。虽然实际中控制块分配失败的概率极低，但这个写法还有更现实的问题——它把"两次内存分配"这个事实暴露在了代码里，而这两次分配其实是完全可以合并的。

第二种是**std::make_shared**，也是我强烈推荐的默认方式：

auto sp = std::make_shared<Widget>();

make_shared的内部实现会一次性分配一块足够大的内存，前半部分放控制块，后半部分放Widget对象，然后在这块内存上做 placement new 构造对象。一次分配代替两次分配，这是它最直接的性能优势。在内存局部性上它也更友好，对象和控制块挨在一起，CPU 缓存命中率更高。而且它天然异常安全，不存在上面的中间态问题。

第三种是从unique_ptr转移：

std::unique_ptr<Widget> up = std::make_unique<Widget>(); std::shared_ptr<Widget> sp = std::move(up);

这种场景不多但很实用：某个对象在创建阶段是独占的，只有最终确定要共享时才转成shared_ptr。转移之后unique_ptr变成空，所有权完成交接，这也是唯一能把unique_ptr转成shared_ptr的方式（shared_ptr不能隐式接收裸指针，必须显式）。

那make_shared是不是万能？不是。它有两个明确的短板。第一，无法自定义删除器。如果你管理的是一个需要特殊释放逻辑的资源（比如fclose、自定义的池化回收），只能走裸指针构造的路径，因为删除器必须作为构造参数传入，而make_shared没有这个入口。第二，内存延迟回收。因为对象和控制块是同一块内存，即使所有shared_ptr都析构了、引用计数归零了，只要还有weak_ptr存活，控制块就得保留，而对象内存因为和控制块绑定在一起，也无法释放。如果对象很大，这个延迟可能是致命的。这种情况就得用new构造，让对象和控制块分开，计数归零时对象内存立刻归还。

总结一下选型：默认用make_shared，需要自定义删除器或者存在大量weak_ptr且对象很大时，用裸指针构造。

2.2 引用计数的三种接口：use_count、unique 与操作符语义

shared_ptr提供了一些查询接口，理解它们对调试很有帮助，但更重要的是理解哪些能用、哪些不该用。

use_count()返回当前共享同一对象的所有shared_ptr数量（严格说是强引用计数）。这个接口在多线程环境下几乎是不可用的——你拿到返回值的一瞬间，别的线程可能已经拷贝或销毁了，返回值立刻过期。所以它只适合在单线程调试场景下打日志，绝对不要用它来做业务逻辑判断，比如"count 为 1 就说明我是独占的"——这个判断在多线程下必然出错。

unique()判断强引用计数是否为 1，等价于use_count() == 1。同样有多线程问题，同样只推荐调试用。

operator bool判断是否持有对象，即get()是否为空，这个是真正常用的：

if (sp) { sp->doSomething(); }

解引用有operator*和operator->两个，前者拿对象引用，后者拿成员访问指针，和裸指针语义一致：

Widget& w = *sp; w.method(); sp->method();

这里有个新手容易困惑的点：shared_ptr的operator*返回的是T&，而裸指针的*p返回的是T。看起来shared_ptr更"安全"，因为它不会因为加个&和*的差别而出现解引用拷贝。但要注意，shared_ptr不检查空指针，*sp在sp为空时是未定义行为，和裸指针一样会崩，所以解引用前必须确保非空。

还有一个特殊用法是别名构造（aliasing constructor），这个知道的人不多但非常好用：

struct Node { int data; int payload[100]; }; auto sp = std::make_shared<Node>(); std::shared_ptr<int> alias(sp, &sp->payload[0]);

别名构造产生的alias和sp共享同一个控制块（即共享引用计数），但alias.get()指向的是payload[0]而不是Node对象。这意味着alias可以安全地指向Node内部的成员，只要alias活着，整个Node就不会被销毁。这在返回"对象内部某成员的智能指针"时非常有用，避免了"返回内部裸指针"的生命周期陷阱。

2.3 销毁与重置：reset、swap 的实践细节

reset()的语义是：放弃当前持有的对象（引用计数减一，可能触发销毁），转而持有新对象或变为空。

std::shared_ptr<Widget> sp = std::make_shared<Widget>(); sp.reset(); // 变为空，原对象计数减一 sp.reset(new Widget()); // 持有新对象 sp.reset(new Widget(), customDeleter); // 带删除器

注意：reset(new Widget())同样是两次分配，且存在和裸指针构造一样的异常安全问题，能用make_shared就别这么写。

swap交换两个shared_ptr持有的对象，这个操作是无异常的、常数的，只交换内部两个指针，不涉及引用计数的原子操作变化（各自的计数从头到尾没变过，只是换了持有者）。高性能场景下用它来交换数据比拷贝赋值高效得多。

还有一个经常被忽略的点：shared_ptr的赋值是线程安全的，但不是原子的。两个线程同时对同一个shared_ptr对象赋值（比如一个shared_ptr成员变量被多个线程写），会产生数据竞争，必须加锁。但两个线程各自拷贝同一个shared_ptr（各自的局部变量）是安全的，因为引用计数的增减是原子的。这个区分非常关键，很多线上崩溃就来源于此。

3. 引用计数背后的实现原理拆解

3.1 控制块的内存布局与两个计数

要真正理解shared_ptr，必须搞清楚控制块（control block）。每个被shared_ptr管理的对象，都对应一个控制块，它至少包含三样东西：强引用计数（shared count）、弱引用计数（weak count）、以及删除器和分配器。

强引用计数记录当前有多少个shared_ptr指向该对象。弱引用计数记录有多少个weak_ptr指向该控制块。注意：弱引用计数并不独立存在，只要强引用计数大于零，弱引用计数就至少是 1——因为所有shared_ptr内部也隐含地"持有"着这个控制块。这个设计是为了让shared_ptr析构时能够访问控制块，如果强计数归零就立刻释放控制块，那weak_ptr就没地方判断"对象是否已销毁"了。

释放时机是这样的：强引用计数归零时，对象被销毁（调用删除器释放对象），但控制块不一定释放；只有当强引用计数和弱引用计数都为 0 时，控制块才真正被释放。这就是为什么存在weak_ptr时，用make_shared创建的对象内存无法及时回收——对象和控制块在同一块内存上，控制块不能释放，对象内存也就跟着被占着。

删除器的存储位置也值得说一句。删除器不是存在shared_ptr里的，而是存在控制块里的。这意味着即使shared_ptr被复制无数份，删除器也只存一份，每份shared_ptr只是持有指向控制块的指针。这也是为什么shared_ptr的拷贝必须是同类型——两边的删除器类型必须一致，因为要共享同一个控制块。

3.2 引用计数的原子操作与线程安全边界

强引用计数的增减必须用原子操作实现，这是shared_ptr线程安全的基础。但"引用计数原子"和"shared_ptr线程安全"是两回事，需要精确区分。

标准明确规定：多个线程可以同时操作不同的shared_ptr实例，即使它们指向同一个对象，这是安全的。比如线程 A 拷贝sp1，线程 B 拷贝sp2，两个sp都指向同一对象，这是安全的，因为引用计数的增减在控制块内是原子的。

但多个线程同时对同一个shared_ptr实例读写，是数据竞争，不安全。比如一个全局的shared_ptr，线程 A 在sp = other，线程 B 在sp->method()，这就是未定义行为。这种场景必须用锁或者std::atomic<std::shared_ptr<T>>（C++20）保护。

为什么这个区分这么重要？因为很多人的错误认知是"shared_ptr是线程安全的智能指针"，然后放心地多线程读写同一个实例，结果偶发崩溃。正确的理解是：引用计数是线程安全的，shared_ptr实例本身不是。就像int是类型，int的加减不是天生线程安全的，shared_ptr同理。

原子操作也有性能代价。每次拷贝一个shared_ptr，都要做一次原子自增；每次析构，都要做一次原子自减。在单线程场景下，这个开销是白付的。如果你的对象从头到尾只在一个线程里用，unique_ptr或者裸指针（配合清晰的 RAII 范围）性能会更好。shared_ptr的价值在于跨线程共享所有权，不是万能钥匙。

3.3 为什么 make_shared 更高效：一次分配的秘密

前面说了make_shared一次分配、new两次分配，这里展开说说为什么这个差异值得重视。

用new构造时，流程是：new Widget()先在堆上分配Widget大小的内存，构造对象；然后shared_ptr构造函数需要在堆上再分配一块控制块，把裸指针、删除器、分配器都存进去，同时初始化两个计数为 1。两次malloc意味着两次堆管理开销、两次可能的锁竞争（多线程堆分配通常要加锁）。

make_shared的实现则是：malloc(sizeof(ControlBlock) + sizeof(Widget))——当然实际实现会考虑对齐，用一个足够大的块装下两者。然后控制块放在前面，Widget放在后面（或反过来，取决于实现），用 placement new 在上面构造对象。一次 malloc，一次构造，异常安全，缓存友好。

缓存友好这点值得单独说。现代 CPU 的缓存行通常是 64 字节。当shared_ptr解引用对象时，如果对象和控制块在同一块内存，那么访问控制块（读引用计数）和访问对象数据很可能落在相邻的缓存行里，减少了一次缓存未命中。在高频访问shared_ptr的场景下，这个差异是能测出来的。

代价前面也提了：内存延迟回收和无法自定义删除器。还有一个隐藏代价是内存碎片——大块连续分配的失败概率比小块高，虽然现代分配器处理得不错，但如果对象尺寸不一，make_shared可能加剧外部碎片。这个通常不是决定因素，知道就好。

3.4 自定义删除器与数组支持的两个坑

shared_ptr支持自定义删除器，形式是构造时传入一个可调用对象：

auto deleter = [](Widget* w) { w->cleanup(); delete w; }; std::shared_ptr<Widget> sp(new Widget(), deleter); // 管理 C 风格资源 FILE* fp = fopen("data.txt", "r"); std::shared_ptr<FILE> filePtr(fp, [](FILE* f) { if (f) fclose(f); });

这里有个坑：删除器是控制块的一部分，不同删除器类型会导致不同的shared_ptr类型。上面的filePtr类型是shared_ptr<FILE>，但它的删除器类型是 lambda 类型，所以它的完整类型是shared_ptr<FILE>（删除器不体现在模板参数里，但构造时决定）。这带来的实际影响是：如果两个shared_ptr用不同的删除器构造，它们的类型虽然相同，但不能互相赋值。因为控制块不兼容。

另一个经典坑是数组支持。在 C++17 之前，shared_ptr<T[]>没有特化，用shared_ptr<Widget>(new Widget[10])会导致delete而不是delete[]，这是未定义行为。C++17 引入了shared_ptr<T[]>特化，可以用std::make_shared<Widget[]>(10)，但为了兼容性，更稳妥的做法还是自定义删除器：

std::shared_ptr<Widget> sp(new Widget[10], [](Widget* p) { delete[] p; });

或者直接用标准容器代替数组，把数组需求转成std::vector或std::array的shared_ptr，语义更清晰：

auto sp = std::make_shared<std::vector<Widget>>(10);

提示：数组是 C 的遗产，能用容器就用容器。真要用shared_ptr管数组，务必确认删除器是delete[]，否则内存泄漏的锅很难查。

4. 循环引用：shared_ptr 唯一的硬伤与三种破解

4.1 循环引用是怎么形成的：一个双向链表案例

循环引用是shared_ptr最著名的问题，也是面试必问。它的成因很简单：两个对象互相用shared_ptr持有对方，各自的引用计数都至少是 1，谁也不会先归零，于是都不释放。

最经典的例子是双向链表或树形结构的父子节点：

struct Node { std::shared_ptr<Node> next; std::shared_ptr<Node> prev; // 循环引用的元凶 ~Node() { std::cout << "Node destroyed\n"; } }; auto a = std::make_shared<Node>(); auto b = std::make_shared<Node>(); a->next = b; b->prev = a; // 此时 a 和 b 的引用计数都变成 2

当a和b这两个局部变量离开作用域时，各减一，计数变成 1。因为a还持有b（通过a->next），b还持有a（通过b->prev），所以两个计数都停在 1，永远不会归零，两个Node对象和它们的控制块全部泄漏。析构函数里的 "Node destroyed" 一个字都不会打印——这就是循环引用最直观的现象。

为什么双向链表要用shared_ptr表达反向指针？其实大多数情况下反向指针根本不需要所有权，只是为了方便访问父节点。这时候用shared_ptr就是过度表达所有权，语义上也错了。正确的做法是反向指针用裸指针或weak_ptr。

4.2 weak_ptr 的正确姿势：lock 与 expired

weak_ptr是破解循环引用的标准工具。它不增加强引用计数，只增加弱引用计数，所以不影响对象的生命周期，也不拥有对象。它的作用是"观察"对象是否还存在。

基本用法：

struct Node { std::shared_ptr<Node> next; std::weak_ptr<Node> prev; // 改为 weak_ptr ~Node() { std::cout << "Node destroyed\n"; } }; auto a = std::make_shared<Node>(); auto b = std::make_shared<Node>(); a->next = b; b->prev = a; // weak_ptr 不增加强引用计数 // 访问时先 lock if (auto parent = b->prev.lock()) { parent->doSomething(); // parent 是 shared_ptr，安全 } else { // 对象已销毁 }

lock()的行为是：如果强引用计数大于零，返回一个指向该对象的shared_ptr（计数加一）；否则返回空shared_ptr。这一步是原子的，不存在"检查时还在、使用时没了"的竞态——这是weak_ptr相比裸指针最大的价值。所以永远不要用weak_ptr裸访问，必须先lock()成shared_ptr再操作。

expired()判断对象是否已被销毁，等价于use_count() == 0。但它同样有多线程问题，因为判断完的瞬间对象可能就没了。实际上expired()基本就是lock() == nullptr的语法糖，需要访问对象时直接lock()，不需要单独expired()。

4.3 三种破解方案对比：weak_ptr、裸指针与所有权重构

除了weak_ptr，还有两种思路可以打破循环，各有适用场景。

方案一：weak_ptr。适用于反向引用、缓存、观察者模式。特点是"我可能随时被销毁，访问前得确认"。缺点是每次访问都要lock()，有原子操作开销，且代码稍微啰嗦。双向链表、树形结构的 parent 指针、观察者列表里的被观察者引用，都适合这个方案。

方案二：裸指针。适用于生命周期明确由外部保证的场景。比如父节点持有子节点的shared_ptr，子节点知道父节点一定比自己活得久（因为父节点销毁时会先销毁所有子节点），这时子节点用裸指针指向父节点是合理的，因为没有所有权语义。裸指针方案零开销，但需要开发者自己保证生命周期，压栈式的对象结构用得多。

方案三：所有权重构。从根本上重新设计数据结构，让所有权是单向无环的。比如双向链表可以改成"只有一个方向用shared_ptr管理，另一个方向通过遍历或其他方式访问"，或者用侵入式链表，把 next/prev 都做成裸指针，由容器统一管理生命周期。环形结构本身就很适合集中管理——用一个大容器持有所有节点，节点之间只做非拥有引用。

三种方案的取舍可以这样看：

注意：判断该用哪种，先问自己"这个引用需不需要表达所有权"。大多数反向引用都不需要，一旦发现某处shared_ptr只是为了"方便拿"，就该考虑换掉。

4.4 enable_shared_from_this：类内部如何安全地返回 shared_ptr

还有一个高频场景：类内部的方法需要返回指向this的shared_ptr。直接用shared_ptr<T>(this)会导致第二套控制块，两个shared_ptr管理同一对象，析构时双重释放，这是必崩的经典错误。

正确做法是继承std::enable_shared_from_this<T>：

class Session : public std::enable_shared_from_this<Session> { public: std::shared_ptr<Session> getSelf() { return shared_from_this(); } void asyncProcess() { // 把自身交给异步回调，保证回调期间对象存活 threadPool.submit([self = shared_from_this()]() { self->handle(); }); } };

shared_from_this()的内部实现是：它查找到对象对应的控制块（通过enable_shared_from_this基类里存的一个weak_ptr），然后lock()出一个shared_ptr。所以它必须在对象已经被shared_ptr管理之后才能调用，如果在构造函数里调用，控制块还没关联上，会抛std::bad_weak_ptr异常。

这个设计在异步编程里几乎是标配：对象提交任务到线程池时，把shared_from_this()捕获进 lambda，任务执行期间持有shared_ptr，即使原持有者提前释放了对象，任务里的引用也能保证对象活到任务结束。这是防止"回调时访问已析构对象"的标准手段，比各种手写的引用计数方案都干净。

5. 高频问题排查与实操避坑清单

5.1 编译期与运行期典型问题速查

实际开发中遇到的shared_ptr问题，大部分集中在下面这几类。我整理成表，方便对照排查。

关于双重释放，这里展开说一个隐蔽场景。下面这段代码看起来没问题，实际是灾难：

Widget* raw = new Widget(); std::shared_ptr<Widget> sp1(raw); std::shared_ptr<Widget> sp2(raw); // 灾难

sp1和sp2各自创建了独立的控制块，引用计数都是 1，互不知晓。当两个都析构时，Widget被 delete 两次。正确的做法是sp2 = sp1，让它们共享控制块。这个错误在"函数返回裸指针、调用方转shared_ptr"的接口设计里特别容易犯——返回值类型最好直接就是shared_ptr，从源头避免。

5.2 性能陷阱：什么时候不该用 shared_ptr

前面反复提过，shared_ptr不是免费的。以下几个场景要警惕：

高频传递的局部对象。如果对象生命周期清晰、不跨模块、不跨线程，用unique_ptr或栈对象。shared_ptr的原子操作在每秒百万次的调用下会变成瓶颈。我实测过一个高频日志路径，把参数从shared_ptr改成引用后，吞吐提升接近两成。

只读共享不需要所有权。如果只是多个线程读同一份配置，传const T&或者T*就够了，不需要shared_ptr。shared_ptr解决的是所有权共享，不是数据共享。数据共享要么用不可变对象配引用，要么用专门的同步结构。

作为函数参数默认按值。按值传shared_ptr会做一次原子自增和一次自减，如果你只是读数据，应该传const shared_ptr<T>&。只有当函数需要延长对象生命周期（比如存进成员变量）时才按值传。

容器里装几百万个shared_ptr。每个shared_ptr16 字节，加控制块至少 16 字节，一个元素至少 48 字节的开销。如果数据本身才 8 字节，这个开销是灾难。这种情况下考虑用索引或unique_ptr配自定义分配器。

5.3 调试引用计数的实战手段

排查shared_ptr相关问题时，引用计数是最直接的线索。我常用的手段有这么几个。

第一，析构打日志。在类析构函数里打一行日志，程序退出时看哪些对象的析构没执行。循环引用的对象析构一定不会打印，这是最快的定位方式。生产环境可以用计数器替代日志，观察计数是否归零。

第二，use_count()辅助定位。在可疑对象的多个生命周期节点打印use_count()（单线程调试场景），观察计数在哪里没减下去。比如预期离开某个作用域后计数应该归零，实际却是 1，说明还有别处持有。

第三，用内存分析工具。带泄漏检测的工具（如 AddressSanitizer 的 leak 检测、Valgrind）能直接告诉你哪块内存泄漏了、分配时的调用栈是什么。shared_ptr的循环引用泄漏在工具里表现为"分配了但没释放"，结合调用栈通常能追到循环引用处。

第四，给控制块加自定义删除器打标记。可以用shared_ptr(new T, [](T* p){ log("deleting"); delete p; })的方式包一层，删除器被调用说明对象真在销毁，没被调用说明卡住了。这招在排查"对象到底是没销毁还是销毁了但没释放内存"时特别有用。

实操心得：use_count()在生产多线程代码里基本只能当参考，别拿它做逻辑分支。我曾经因为用use_count() == 1判断"独占就原地修改"，在多线程下改出了偶发数据竞争，排查了很久才想到这个接口本身就是竞态的。单线程调试用，多线程只信加锁。

6. 从实践出发：一套 shared_ptr 使用规范

6.1 创建与传递的原则清单

用了几年的shared_ptr，我给自己和团队总结了一套简单可执行的规范，落地后相关 bug 明显下降。

创建阶段：默认make_shared；需要自定义删除器才用裸指针构造；构造完成后立即用shared_ptr接管，中间不要留裸指针窗口；绝不用同一个裸指针构造两个shared_ptr。

传递阶段：只读参数传const shared_ptr<T>&；需要延长生命周期才按值传；接口返回值用shared_ptr而非裸指针，避免调用方二次封装；类内部返回自身用enable_shared_from_this。

所有权设计阶段：先问"这个引用需不需要表达所有权"，不需要就用weak_ptr或裸指针；树形、链表的反向指针默认weak_ptr；异步回调捕获shared_from_this()。

多线程阶段：不同shared_ptr实例指向同对象可以无锁并发；同一shared_ptr实例多线程读写必须加锁；use_count()和unique()不用于业务判断。

下面这段是我常用的一个模板，异步任务提交时保证对象存活：

class Task : public std::enable_shared_from_this<Task> { public: void start() { auto self = shared_from_this(); pool.submit([self]() { self->run(); // self 保证 run 期间对象存活 }); } private: void run() { /* 业务逻辑 */ } ThreadPool pool; };

这个模式的关键在于：lambda 按值捕获self，这是一次shared_ptr拷贝，引用计数加一；任务执行期间self持有对象；任务结束 lambda 析构，计数减一。即使外部所有shared_ptr都已释放，任务也能安全执行完。这是异步场景下最不容易出错的生命周期管理方式。

6.2 与 unique_ptr 的边界：什么时候必须共享

最后说一个我经常被问到的问题：到底什么时候该从unique_ptr换成shared_ptr？

我的判断标准是看所有权是否真的无法在编译期确定。unique_ptr表达的是"只有一个所有者，所有权可以转移但不能复制"，这在绝大多数字段、容器元素、工厂返回值场景都成立，而且零开销。只有出现下面这些信号，才说明需要shared_ptr：

• 对象需要在多个不相关的模块间共享，且没有明确的持有主干
• 异步回调、定时器、观察者需要在提交之后仍然保证对象存活
• 缓存场景，对象可能被多个 key 引用，生命周期动态变化
• 对象的持有者数量在运行期动态增减，无法静态确定

反过来，如果只是为了"方便拷贝"而用shared_ptr，或者为了省去设计所有权而用shared_ptr，那就是把编译期的清晰性换成了运行期的原子操作和潜在循环引用。我见过不少代码库把shared_ptr当默认指针用，结果性能上不去、内存泄漏难查，回头重构的成本远高于一开始想清楚。

shared_ptr最舒服的状态，是它出现在真正需要它的少数关键位置——跨模块的共享资源、异步任务的生命周期锚点、缓存的条目——其他地方的裸指针和unique_ptr各司其职。到这一步，你对它的理解就从"会用"变成了"用对"，这两者之间的距离，往往就是几天的调试时间和几周的线上稳定性。

我自己最直接的体会是，把循环引用当成设计信号来看待：一旦发现需要两个shared_ptr互相指向，先别急着上weak_ptr，回头看看这个数据结构的所有权是不是画错了。多数时候，问题出在最初的所有权模型上，weak_ptr只是补丁，不是解药。