1. 引言为什么 C 需要 shared_ptrC 以强大的性能和极致的资源控制能力著称但长期以来手动内存管理带来的「悬挂指针」「重复释放」「内存泄漏」三大灾难一直是大型 C 项目中最令人头疼的问题。一个对象可能被多个模块、多个线程、多个容器同时持有到底谁负责在最后一个使用完成后释放它往往没有明确的答案。于是「引用计数」这一经典思想被引入 C 标准库每当有一个新的管理者接管对象时计数加一每当一个管理者不再需要对象时计数减一当计数归零时说明世界上再也没有任何人需要这个对象了此时安全地销毁它。shared_ptr 正是这一思想的工业化实现。假设有下面这段朴素的代码// 手动管理隐患重重 class Connection { public: ~Connection() { close(); } void close() { /* 关闭底层连接 */ } }; void process(Connection* conn) { // conn 到底该不该由我释放调用者还在用吗 } void caller() { Connection* conn new Connection(); process(conn); // 如果 process 已经 delete 了 conn这里继续使用就是悬挂指针 // 如果 process 没有 delete这里忘了 delete 就是内存泄漏。 delete conn; }上面的问题在于所有权不明确。而 shared_ptr 的核心价值就是用一个可见的、可追踪的计数器把「谁持有、谁释放」的模糊约定变成机器可验证的客观事实。caller和process各自持有一份 shared_ptr对象会在最后一个 shared_ptr 离开作用域时自动释放不再需要任何一方承担「我是最后一个吗」的猜测。本文将从零开始由浅入深地拆解 shared_ptr 引用计数的原理控制块到底存在哪里、强引用与弱引用为什么是两套计数、每次拷贝和赋值背后发生了什么、原子操作为什么必不可少、make_shared 与直接构造有何差别、enable_shared_from_this 为什么能安全地返回 this以及隐藏在实现细节中的性能开销和典型陷阱。2. shared_ptr 概述它到底持有了什么很多初学者会以为 shared_ptr 只是「一个带计数的指针」实际上它比这复杂得多也正因如此理解它需要先明确两个基础概念被管理对象和控制块。2.1 被管理对象被管理对象就是用户真正关心其生命周期的那个对象。它可以是堆上分配的对象也可以是任意资源甚至可以通过自定义删除器来管理非堆资源如文件句柄、socket、自定义内存池。shared_ptr 并不关心被管理对象是谁分配的它只关心两点如何访问它以及最终如何销毁它。2.2 控制块控制块是 shared_ptr 引用的第二个堆对象它是引用计数的真正载体。一个典型的控制块至少包含以下内容强引用计数shared count记录当前有多少个 shared_ptr 指向被管理对象。弱引用计数weak count记录当前有多少个 weak_ptr 指向被管理对象以及一些实现中的特殊计数。删除器知道应该如何销毁被管理对象。分配器知道控制块本身应该如何释放与删除器对应的分配器。被管理对象指针指向真正要销毁的对象。因此一个 shared_ptr 实例内部通常只包含两个裸指针指向被管理对象的指针和指向控制块的指针。逻辑结构如下图所示shared_ptr 实例 ------------------- --------------------- | 对象指针 (ptr) | ------ | 被管理对象 | ------------------- | (user object) | | 控制块指针 (cb) | --- --------------------- ------------------- | | --------------------- --- | 控制块 (control block)| | - shared count | | - weak count | | - deleter | | - allocator | | - object pointer | ---------------------正是因为有了独立控制块多个 shared_ptr 才能共享同一份计数状态它们各自保存对象指针和控制块指针而对计数的任何修改都落到同一个控制块上从而保证全局唯一的引用计数视图。2.3 为什么需要 weak count如果只有 shared count那么当 shared count 归零时被管理对象被销毁。但此时如果有 weak_ptr 还活着它仍然需要访问控制块去查询「对象是否还活着」。于是控制块本身不能被立即释放。标准规定当 shared count 归零时销毁被管理对象当 weak count 也归零时才释放控制块本身。这正是两套计数存在的根本原因后续章节会详细展开。3. 引用计数的核心模型3.1 经典引用计数的三条规则任何引用计数机制都遵循三条最基本的规则构造时计数加一每当一个新的 shared_ptr 指向某个对象时该对象的强引用计数增加 1。析构时计数减一每当一个 shared_ptr 不再指向该对象离开作用域、被 reset、被重新赋值等强引用计数减少 1。计数归零时销毁对象当强引用计数变成 0说明没有任何 shared_ptr 还指向对象此时销毁被管理对象当弱引用计数也变成 0销毁控制块。用一个最简单的示例演示这个变化过程#include memory #include iostream struct Widget { int value; explicit Widget(int v) : value(v) { std::cout Widget constructed\n; } ~Widget() { std::cout Widget destroyed\n; } }; int main() { std::shared_ptrWidget p1(new Widget(42)); // shared count 1weak count 0 { std::shared_ptrlt;Widgetgt; p2 p1; // shared count 2weak count 0 } // p2 析构shared count 1 p1.reset(); // p1 析构shared count 0Widget 被销毁 return 0; }输出结果会是先打印构造信息最后打印析构信息中间显式展示引用计数的增减。可以使用use_count()在调试阶段观察计数的实时变化。3.2 引用计数的原子性朴素引用计数最大的问题是如果两个线程同时操作同一个 shared_ptr 的控制块普通的count和--count会发生数据竞争。C 标准明确要求shared_ptr 对控制块中计数的所有修改都必须是线程安全的通常通过std::atomic或平台原语实现。这意味着多个线程可以安全地同时拷贝同一个 shared_ptr、析构各自持有的副本而不会造成计数错乱。但需要注意的是线程安全性只针对控制块的计数操作并不保证被管理对象本身的线程安全也不保证同一个 shared_ptr 实例被多个线程同时写时的安全。这一点在第 9 章会专门讨论。3.3 强引用与弱引用的协同控制块中的两个计数不是孤立的。weak_ptr 的存在会延长控制块的生命周期但不会延长被管理对象的生命周期。这种设计允许我们安全地做「弱持有」观察一个对象是否还存在但不妨碍它被正常销毁。下面的状态转换表总结了不同操作对两个计数的影响假定初始状态为 shared count Sweak count W操作shared count 变化weak count 变化对象销毁控制块释放创建 shared_ptr 指向新对象S 1W 不变或 1视实现否否拷贝构造 shared_ptrS 1不变否否移动构造 shared_ptr不变不变否否销毁 shared_ptrS - 1不变S 归零时是W 也归零时是从 weak_ptr 创建 shared_ptrlockS 1不变否否销毁 weak_ptr不变W - 1否W 归零时是这张表是理解后续所有行为的基础。值得特别注意的是某些实现中从裸指针创建第一个 shared_ptr 时weak count 也会被初始化为 1用来表示「至少有一个 shared_ptr 存在」这一事实直到 shared count 归零后再由析构逻辑递减 weak count。不同的标准库实现细节略有差异但语义等价。4. 控制块Control Block的完整解剖4.1 控制块的标准与实现差异C 标准只规定了 shared_ptr 的语义并没有规定控制块的具体内存布局。因此 libstdcGCC、libcClang和 MSVC STL 三家实现的控制块结构各不相同但它们都必须能支持同样的功能集合。一个典型控制块需要解决以下问题强引用计数和弱引用计数的原子操作。被管理对象指针的保存。删除器的类型擦除shared_ptr 在编译期知道删除器的类型但控制块要用统一的接口在运行期调用它。分配器的类型擦除同理控制块自身销毁时需要按用户提供的分配器释放。虚函数机制通过虚函数或函数指针实现多态销毁而无需把 shared_ptr 本身做成模板的多态基类。4.2 一个简化的控制块实现下面给出一个教学用途的简化实现帮助读者建立直观认识。实际标准库实现比这复杂得多尤其是为了优化大小、避免虚表、优化原子操作和实现 make_shared 的单块分配。#include atomic struct ControlBlockBase { std::atomiclong shared_count; std::atomiclong weak_count; explicit ControlBlockBase(long sc, long wc) : shared_count(sc), weak_count(wc) {} virtual ~ControlBlockBase() default; // 销毁被管理对象 virtual void destroy_object() noexcept 0; // 销毁控制块自身 virtual void destroy_control_block() noexcept 0; void add_shared() noexcept { shared_count.fetch_add(1, std::memory_order_relaxed); } void release_shared() noexcept { if (shared_count.fetch_sub(1, std::memory_order_acq_rel) 1) { destroy_object(); release_weak(); } } void add_weak() noexcept { weak_count.fetch_add(1, std::memory_order_relaxed); } void release_weak() noexcept { if (weak_count.fetch_sub(1, std::memory_order_acq_rel) 1) { destroy_control_block(); } } }; template typename T, typename Deleter, typename Alloc struct ControlBlockImpl : ControlBlockBase { T* object; Deleter deleter; Alloc allocator; ControlBlockImpl(T* obj, Deleter d, Alloc a) : ControlBlockBase(1, 1), object(obj), deleter(std::move(d)), allocator(a) {} void destroy_object() noexcept override { deleter(object); } void destroy_control_block() noexcept override { using cb_alloc typename std::allocator_traitslt;Allocgt; ::template rebind_alloclt;ControlBlockImplgt;; cb_alloc cb_allo(allocator); this-gt;~ControlBlockImpl(); cb_allo.deallocate(this, 1); } };这段代码展示了几个核心设计原子计数std::atomiclong保证多线程增减安全。虚函数类型擦除基类提供统一的销毁接口子类持有具体的删除器和分配器。延迟销毁控制块release_shared在 shared count 归零时先销毁对象再调用release_weak递减 weak count只有 weak count 也归零时才销毁控制块本身。4.3 为什么必须用原子操作引用计数的增减操作必须满足「读-改-写」的原子性。假设没有原子操作两个线程同时执行p1和p2的析构线程 A 读取 count 2准备减一写回 1。线程 B 也读取 count 2准备减一写回 1。两个线程都把 1 写回最终 count 1但实际上两个 shared_ptr 都已经析构对象的强引用应该是 0。这种经典的「丢失更新」会直接导致内存泄漏或对象永远不销毁。原子操作通过底层硬件指令如 x86 的lock前缀或 ARM 的ldxr/stxr保证读-改-写过程不会被其他核心穿插。内存序的选择也有讲究计数增减通常使用memory_order_relaxed或memory_order_acq_rel。单纯计数不需要建立与其他数据的顺序关系时用 relaxed 即可而在 shared count 从 1 变为 0 的那个操作中需要确保其他线程之前对被管理对象的所有写操作都已完成同步因此最后一次递减往往使用 release 语义并在销毁对象前使用 acquire 语义。5. 引用计数的生命周期构造、拷贝、移动与赋值5.1 从裸指针构造从裸指针构造 shared_ptr 是最常见也最危险的入口。标准会创建一个新的控制块并将 shared count 初始化为 1std::shared_ptrWidget sp(new Widget(42)); // 控制块shared 1, weak 1 // 对象指针指向 Widget危险在于如果同一个裸指针被用来构造两个独立的 shared_ptr就会产生两个控制块每个控制块都认为自己是唯一的管理者最终造成对象被重复释放Widget* raw new Widget(42); std::shared_ptrWidget sp1(raw); // 控制块 Ashared 1 std::shared_ptrWidget sp2(raw); // 控制块 Bshared 1 // sp1 析构时销毁 Widgetsp2 析构时再次销毁同一 Widget —— 未定义行为这条规则必须牢记同一裸指针只能用于构造一次 shared_ptr。如果需要多个管理者应该从第一个 shared_ptr 拷贝构造而不是重复使用裸指针。5.2 拷贝构造与拷贝赋值拷贝一个 shared_ptr 不会创建新的控制块而是共享原控制块并将 shared count 加一std::shared_ptrWidget a(new Widget(1)); // shared 1 std::shared_ptrWidget b a; // shared 2 std::shared_ptrWidget c(a); // shared 3拷贝赋值的语义稍微复杂一点它相当于「先让右侧对象加一再让左侧对象减一」std::shared_ptrWidget x(new Widget(10)); // control block X: shared 1 std::shared_ptrWidget y(new Widget(20)); // control block Y: shared 1 x y; // 1. y 的 shared count 加一变为 2 // 2. x 原来指向的 control block X 的 shared count 减一变为 0 // 3. Widget(10) 被销毁 // 4. x 现在与 y 共享 control block Yshared count 2特别要注意顺序标准实现会先递增右侧计数再递减左侧计数。这样可以处理「自我赋值」的情况虽然自我赋值在 shared_ptr 中无害更重要的是保证在异常安全的情况下右侧对象的引用不会被提前释放。5.3 移动构造与移动赋值移动操作是 shared_ptr 性能优化的关键。移动构造不改变引用计数只是把源 shared_ptr 的「对象指针」和「控制块指针」直接转移给目标然后把源 shared_ptr 置空std::shared_ptrWidget src(new Widget(99)); // shared 1 std::shared_ptrWidget dst std::move(src); // shared 1不增不减 // src 现在为空dst 持有原对象由于没有原子操作移动构造比拷贝构造快得多。移动赋值则等价于「先释放当前持有的对象再接管源对象的指针」。移动操作的引用计数变化表操作源 shared count目标 shared count原子操作次数拷贝构造不变1至少 1 次移动构造不变不变0 次拷贝赋值1-1若有旧对象最多 2 次移动赋值不变可能 -1若有旧对象最多 1 次5.4 reset 与 use_countreset()相当于让当前 shared_ptr 放弃所有权。不带参数时它递减当前控制块的 shared count带参数时它相当于「先释放旧对象再接管新对象」std::shared_ptrWidget sp(new Widget(1)); // shared 1 sp.reset(); // shared 0Widget(1) 销毁 sp.reset(new Widget(2)); // 创建新控制块shared 1use_count()返回当前的强引用计数主要用于调试和断言。需要注意的是在use_count()返回之后到实际使用这个数值之间的时间窗口内其他线程可能已经改变了计数因此它不能用于任何需要精确定义的运行期逻辑。6. weak_ptr 与弱引用计数的深入剖析6.1 weak_ptr 的定位不拥有只观察weak_ptr 是 shared_ptr 的「旁观者」。它指向同一个控制块但不会增加 shared count因此不会阻止被管理对象被销毁。它解决的核心问题是循环引用#include memory #include iostream struct Node; struct Node { std::shared_ptrNode next; // 强引用 std::weak_ptrNode prev; // 弱引用打破循环 ~Node() { std::cout Node destroyed\n; } }; int main() { auto a std::make_sharedNode(); auto b std::make_sharedNode(); a-next b; // b 的 shared count 2 b-prev a; // a 的 shared count 1weak_ptr 不增加 // a 离开作用域时 shared count 归零a 被销毁 // a 被销毁后 b 的 shared count 从 2 变成 1 // b 离开作用域时 shared count 归零b 被销毁。 return 0; }如果把prev也改成 shared_ptr那么a和b互相持有强引用两者离开作用域后计数都不会归零形成经典的内存泄漏。weak_ptr 正是通过「不增加 shared count只增加 weak count」来打破这种循环。6.2 从 shared_ptr 构造 weak_ptr当我们从 shared_ptr 构造 weak_ptr 时控制块的 weak count 加一shared count 不变。这保证了控制块会一直存活到所有 weak_ptr 也销毁为止。std::shared_ptrWidget sp std::make_sharedWidget(); // control block: shared 1, weak 1 std::weak_ptrWidget wp sp; // control block: shared 1, weak 26.3 lock 与 expiredweak_ptr 不能直接访问对象必须通过lock()尝试提升为 shared_ptr。这个操作是原子的解决了著名的「检查后使用」竞态问题if (!wp.expired()) { // 危险在这两步之间对象可能已经被其他线程销毁 auto sp wp.lock(); } // 正确写法lock 本身就是原子的检查 提升 if (auto sp wp.lock()) { // 现在 sp 持有强引用对象保证存活 sp-do_something(); }lock()的内部逻辑是以原子方式读取 shared count如果 shared count 是 0对象已经销毁或正在销毁返回空 shared_ptr否则尝试将 shared count 加一并返回一个新的 shared_ptr。这个检查和加一必须是原子的否则在检查和加一之间对象可能被销毁使得返回的 shared_ptr 指向已死对象。// 简化的 lock 语义 std::shared_ptrT weak_ptrT::lock() const { auto* cb control_block; if (!cb) return {}; long cur cb-shared_count.load(std::memory_order_relaxed); while (cur 0) { if (cb-shared_count.compare_exchange_weak( cur, cur 1, std::memory_order_acquire, std::memory_order_relaxed)) { return std::shared_ptrT(ptr, cb); // 构造成功 } } return {}; }这个循环是必须的compare_exchange_weak可能在「其他线程同时修改了 shared count」的情况下偶发失败因此需要在循环中重试。每次失败后cur会被更新为最新的计数值循环重新判断cur 0是否成立。6.4 weak count 的销毁时机经典规则是shared count 归零即销毁对象weak count 归零即销毁控制块。但在实际实现中还有一种特殊计数某些库会用「shared count 1」作为弱计数其中额外的一个 1 代表「至少有一个 shared_ptr 存在」。当 shared count 从 1 减到 0 时析构逻辑同时执行一次 weak count 递减以抵消最初虚增的那一个。这种实现让「有 shared_ptr 活着时控制块一定不能释放」这一约束自然地得到满足读者在阅读不同标准库源码时会看到这种细节差异。7. enable_shared_from_this安全地返回 this7.1 问题的起源在编写对象自身需要「给自己创建 shared_ptr」的场景时最常见的错误是直接在成员函数里写class Widget : public std::enable_shared_from_thisWidget { public: std::shared_ptrWidget get_shared() { return std::shared_ptrWidget(this); // 灾难 } }; int main() { auto sp1 std::make_sharedWidget(); // control block A auto sp2 sp1-get_shared(); // control block B // sp1 和 sp2 各自拥有独立的控制块最终 Widget 被析构两次 —— 未定义行为 }问题的本质还是「一个裸指针被两次交给 shared_ptr 构造」只不过这次this扮演了裸指针的角色。直接用this构造 shared_ptr 会创建一个全新的控制块与外部已有的控制块脱钩。7.2 enable_shared_from_this 的原理enable_shared_from_this 解决了「如何从对象内部拿到那个已存在的控制块」的问题。它内部通常持有一个weak_ptr在对象第一次被 shared_ptr 接管时标准库会把对象的 weak_ptr 指向同一个控制块。之后在成员函数里就可以通过这个 weak_ptr 安全地提升出新的 shared_ptrclass Widget : public std::enable_shared_from_thisWidget { public: std::shared_ptrWidget get_shared() { return shared_from_this(); // 内部调用 weak_ptr::lock() } }; int main() { auto sp1 std::make_sharedWidget(); // 控制块 A auto sp2 sp1-get_shared(); // 仍然使用控制块 Ashared 2 // 一切正常对象只析构一次 }关键在于make_shared或 shared_ptr 构造函数在创建时需要检测T是否派生自enable_shared_from_this如果是就把内部 weak_ptr 初始化为指向当前控制块。标准库通过std::enable_shared_from_this的基类与模板元编程如is_convertible来完成这一检测。7.3 使用前提与注意事项对象必须已经被 shared_ptr 管理之后才能调用shared_from_this()否则内部 weak_ptr 为空或已经过期调用会抛出std::bad_weak_ptr或产生未定义行为。优先使用make_shared创建对象直接new后再构造 shared_ptr 虽然标准库也会初始化 weak_ptr但会有额外的控制块分配。不要在构造函数或析构函数中调用shared_from_this()构造时 weak_ptr 尚未初始化析构时对象可能已经处于销毁流程中。派生类应当公开继承enable_shared_from_this并注意基类中调用时的 static type 与 dynamic type 的正确性。8. 线程安全模型shared_ptr 到底安全在哪里8.1 标准保证的范围C 标准对 shared_ptr 的线程安全给出了非常精确的限定可以总结为三层不同 shared_ptr 实例操作同一个控制块是线程安全的多个线程可以同时拷贝同一个 shared_ptr、析构自己的副本控制块的计数增减由原子操作保证。同一个 shared_ptr 实例被多个线程同时读拷贝构造是安全的因为拷贝只是读取对象指针和控制块指针不修改实例本身。同一个 shared_ptr 实例被多个线程同时写赋值、reset是不安全的这会导致实例内部两个指针的读写竞态需要外部同步。8.2 直观的理解可以把 shared_ptr 理解为一个「只读句柄的共享计数器」控制块是全局安全的数据结构而每个 shared_ptr 实例本身只是两个裸指针。多个线程读写不同的 shared_ptr 实例时它们实际争抢的是同一个控制块因此原子计数保护了它们。但如果多个线程读写同一个 shared_ptr 实例那么争抢的对象变成了这个实例本身的两个裸指针成员原子计数就无能为力了。std::shared_ptrWidget global_sp; // 全局实例 // 线程 1 和线程 2 同时执行 void reader() { // 安全只读 global_sp拷贝构造是 const 操作 std::shared_ptrWidget local global_sp; } void writer() { // 与 reader 并发执行时不安全写 global_sp 的两个指针成员 global_sp std::make_sharedWidget(); }如果需要多个线程同时读写同一个 shared_ptr 实例应使用std::atomicstd::shared_ptrTC20或外部互斥锁保护。8.3 被管理对象本身的线程安全性即便所有 shared_ptr 操作都安全被管理对象的成员函数仍然需要自己保证线程安全。shared_ptr 只负责「对象什么时候被销毁」不负责「对象内部数据的并发访问」。另一个容易被忽略的问题是当最后一个 shared_ptr 在某线程析构、对象开始销毁的同时其他线程可能仍然持有着指向对象内部数据的裸指针。由于 shared_ptr 的线程安全保证不包括对「已开始销毁的对象」的访问这种场景必须通过业务层的生命周期协议来避免。9. make_shared 与内存布局优化9.1 两次分配的问题直接使用new构造 shared_ptr 会发生两次堆分配一次分配被管理对象一次分配控制块。两次分配增加了内存碎片、缓存未命中和分配器压力std::shared_ptrWidget sp(new Widget(42)); // 分配 1Widget 对象 // 分配 2控制块9.2 make_shared 的单块分配make_shared通过一次分配同时容纳对象和控制块。标准库会分配一块足够大的连续内存在内存头部放置控制块紧接着放置被管理对象auto sp std::make_sharedWidget(42); // 仅一次分配 // ---------------------------------- // | 控制块 | Widget 对象 | // ---------------------------------- // 对象指针指向右侧首地址这种布局带来显著优势堆分配次数从 2 次降为 1 次减少分配器调用和内存管理开销。控制块和对象在内存中相邻缓存局部性更好访问对象时控制块可能已经在同一缓存行。异常安全更简单一次分配成功就表示对象和控制块都已就绪。9.3 make_shared 的代价单块分配的代价是当 shared count 归零时对象被销毁但内存块不能释放因为控制块仍然和对象共享同一块内存。直到 weak count 也归零时整块内存才能还给分配器。如果存在大量 weak_ptr 长期持有make_shared 会导致对象虽然已销毁但其占用的内存仍然无法回收。对于对象内存占用非常大的场景这个代价可能超过它带来的收益此时可以改用直接new的方式让控制块和对象分离使对象内存可以尽快释放。9.4 何时使用哪种方式场景推荐方式原因一般对象创建make_shared一次分配、缓存友好、异常安全对象巨大且可能有大量 weak_ptrnew shared_ptr对象销毁后内存可立即回收需要自定义删除器new shared_ptrmake_shared 不支持自定义删除器需要自定义分配器allocate_shared控制块和对象都使用用户分配器对象构造参数可能抛出异常make_shared异常时自动清理无需手动 delete10. 引用计数带来的性能开销10.1 原子操作的真实成本引用计数并非免费的午餐。每一次拷贝、每一次析构、每一次赋值都涉及对控制块的原子操作。在多核处理器上原子操作虽然比早期的锁廉价但依然比普通加减法昂贵得多因为它需要阻止指令重排内存屏障。获取缓存行的独占权可能触发缓存一致性协议 MESI 的状态转换。在争用激烈时产生自旋或总线锁。在单线程性能敏感的循环里频繁拷贝 shared_ptr 可能成为热点// 每次迭代都触发一次原子递增和一次原子递减 for (int i 0; i 100000; i) { std::shared_ptrWidget tmp global_sp; // 原子 process(tmp); } // 原子 --优化手法是在循环外拷贝一次循环内通过引用或裸指针传递或者优先使用移动语义减少原子操作。std::shared_ptrWidget local global_sp; // 只递增一次 for (int i 0; i 100000; i) { process(local); // 通过引用传递无原子操作 }10.2 空间开销一个 shared_ptr 实例通常是两个裸指针的大小在 64 位系统上是 16 字节。控制块本身的典型大小在 24 到 48 字节之间取决于实现和是否包含删除器、分配器及 weak count。对于大量小对象的场景控制块的空间开销可能接近甚至超过对象本身。10.3 缓存局部性shared_ptr 每一次操作都要访问控制块而控制块和被管理对象通常不在同一缓存行除非使用 make_shared。大量 shared_ptr 操作会导致频繁的缓存未命中。在需要极致性能的场景可以考虑使用侵入式引用计数对象内部自带计数其缓存局部性通常优于外挂控制块。11. 常见陷阱与最佳实践11.1 陷阱一裸指针多重构造同一个裸指针构造多个 shared_ptr是引用计数体系中最典型的错误必须铭刻于心Widget* raw new Widget(); std::shared_ptrWidget a(raw); std::shared_ptrWidget b(raw); // 两个控制块双重释放正确做法是创建一个 shared_ptr 后所有后续 shared_ptr 都从它拷贝或移动构造。11.2 陷阱二循环引用导致泄漏两个对象互相持有 shared_ptr 会在离开作用域后计数无法归零。应使用 weak_ptr 打破循环但前提是业务逻辑允许其中一方不拥有对方。11.3 陷阱三在构造函数中调用 shared_from_thisenable_shared_from_this 的内部 weak_ptr 只在对象被 shared_ptr 接管后才初始化构造函数内调用shared_from_this()会抛出bad_weak_ptr。正确的模式是使用工厂函数或延迟到其他成员函数中调用。11.4 陷阱四在析构过程中访问过期的 weak_ptr当 shared count 已经归零、对象正在析构时其他线程可能持有 weak_ptr 并尝试lock()。lock 会失败并返回空指针这个行为是安全的但业务代码必须正确处理空结果不能假设 lock 成功。11.5 陷阱五误用 use_countuse_count()的返回值在多线程环境下没有任何实时保证。不要用它做任何资源决策它只适合调试和日志。11.6 陷阱六把 shared_ptr 传入需要裸指针的 C 接口void legacy_api(Widget* widget); // C 接口不管理生命周期 std::shared_ptrWidget sp std::make_sharedWidget(); legacy_api(sp.get()); // 可以但要保证 sp 在 legacy_api 返回前一直存活 // 不能把 sp.get() 交给一个会在后续异步持有的接口否则对象可能已销毁11.7 陷阱七shared_ptr 指向栈对象shared_ptr 默认用 delete或自定义删除器销毁对象。如果给它一个栈对象的指针却没有提供不删除的删除器析构时会调用 delete 栈地址这是未定义行为。11.8 最佳实践汇总优先使用make_shared和make_unique创建智能指针。一个裸指针只能交给 shared_ptr 一次。打破循环引用时使用 weak_ptr。返回 this 时使用enable_shared_from_this且不要自己 new 一个 shared_ptr 包 this。参数传递时如果函数只是使用对象而不保存所有权用裸指针或引用如果函数要保存所有权用 shared_ptr 值传递。性能敏感路径尽量减少 shared_ptr 的拷贝优先移动或引用传递。多线程写同一个 shared_ptr 实例时务必使用atomicshared_ptrT或互斥锁。12. 深入实现主流标准库的差异与共同点12.1 三巨头概览特性libstdc (GCC)libc (Clang)MSVC STL原子计数类型atomic 内置atomic 内置atomic 内置控制块释放策略weak count 归零释放weak count 归零释放weak count 归零释放make_shared 单块分配支持支持支持weak count 表示weak count 1weak count 1weak count 1类型擦除方式虚函数虚函数虚函数三家实现虽然细节不同但都遵循标准语义。理解「weak count 1」这个细节很重要初始时 weak count 被设置为 1表示「有一个 shared_ptr 存在」当 shared count 归零后析构流程会额外递减一次 weak count使得控制块可以在所有 weak_ptr 消失后释放。这种表示避免了「有 shared_ptr 但 weak count 为 0」的非法状态。12.2 为什么标准不约束实现C 标准委员会刻意不规定控制块的具体布局原因在于不同的平台和缓存体系下最优的内存布局和原子操作策略可能完全不同。标准只需要保证语义和线程安全留给实现者充分的优化空间。这也是为什么学习 shared_ptr 时理解「语义」比记忆「某个库的源码」更重要的原因。13. 与其他智能指针的对比与选择指南13.1 unique_ptr独占所有权零额外开销unique_ptr 不涉及引用计数它在大多数情况下零开销析构时直接销毁对象。当所有权只有一个时应该优先使用 unique_ptr需要共享时才转换为 shared_ptr。13.2 weak_ptr弱观察者weak_ptr 无法单独管理对象必须依附于 shared_ptr。它适合表达「可选的、不拥有所有权的观察引用」。13.3 shared_ptr共享所有权引用计数开销shared_ptr 只在真正需要多个所有者时才使用。滥用 shared_ptr 会让所有权模型模糊化并带来不必要的原子开销。一个好的经验法则是如果能在编译期确定所有权就不要使用运行期的引用计数。13.4 选择决策流程对象只有一个明确所有者使用unique_ptr。需要多个所有者且生命周期可以共享使用shared_ptr。需要观察但不阻止销毁使用weak_ptr。需要极度性能且对象自身可嵌入计数考虑侵入式引用计数。14. 总结shared_ptr 的引用计数原理可以浓缩为一句话用控制块集中管理两套原子计数shared count 归零销毁对象weak count 归零销毁控制块所有计数修改都通过原子操作保证多线程安全。本文沿这条主线展开详细讨论了控制块的内部结构、构造和拷贝移动赋值过程中的计数变化、weak_ptr 与弱计数的关系、enable_shared_from_this 的原理、线程安全边界、make_shared 的一次分配优化、性能开销来源以及七个常见陷阱。理解 shared_ptr 不只是记住 API更是理解 C 对象所有权模型的精妙之处通过一个看似简单的计数器C 在不引入垃圾回收器的前提下提供了确定性的资源释放时机和安全的共享所有权。掌握了引用计数的原理你就能在大型项目中自信地管理对象生命周期避开双重释放、循环引用和竞态条件等暗礁。延伸阅读建议《Effective Modern C》中关于智能指针的 Item 18-22。C 标准中 shared_ptr 与 atomic 相关的章节。libstdc、libc 或 MSVC STL 的 shared_ptr 源码理解其控制块实现。C20 引入的std::atomicstd::shared_ptrT的使用方式。