c++如何使用std::shared_ptr_c++引用计数智能指针详解【核心】

std::shared_ptr通过独立控制块管理引用计数，强引用归零时析构对象并释放控制块；make_shared更高效且防异常泄漏，但需避免裸指针重复构造、循环引用及this误用。

std::shared_ptr 是怎么管理引用计数的

它不是靠指针本身存计数，而是额外分配一块控制块（control block），里面放引用计数、弱引用计数、析构器、分配器等信息。每次拷贝 std::shared_ptr，控制块里的强引用计数就 +1；每次离开作用域或被赋值为 nullptr，就 -1；减到 0 时，自动 delete 所管理的对象，并释放控制块。

• 控制块和对象可以分开分配（默认行为），也可能合并在一次 new 中（用 std::make_shared 时）——后者更高效，但要注意：如果对象构造抛异常，控制块仍会泄漏（c++17 起已修复）
• 引用计数操作是原子的，所以 std::shared_ptr 可在多线程中安全拷贝/赋值，但指向的 *对象本身不自动线程安全*
• 不要混用裸指针初始化：int* p = new int(42); auto sp1 = std::shared_ptr(p); auto sp2 = std::shared_ptr(p); ——这会创建两个独立控制块，双重 delete

什么时候必须用 std::make_shared 而不是 new + 构造函数

绝大多数情况都该用 std::make_shared：它把对象和控制块一次分配，避免两次内存申请，也杜绝了因异常导致的资源泄漏风险（比如构造函数抛异常时，裸 new 分配的内存可能没被接管）。

• 例外：需要自定义删除器且不能默认构造（std::make_shared 不接受删除器参数），此时只能用 std::shared_ptr(new T, my_deleter)
• 注意：不能对数组用 std::make_shared() ——C++17 前不支持，即使支持，std::shared_ptr 也不带 [] 删除语义，应改用 std::shared_ptr + 自定义删除器
• std::make_shared 完转发参数给 T 的构造函数，完美支持 explicit 构造、初始化列表、移动语义

std::shared_ptr 和 std::weak_ptr 配合破循环引用的关键点

循环引用不是“两个 shared_ptr 互相持有”，而是“两个对象通过 shared_ptr 成员彼此持有对方”，导致引用计数永远不归零。解决方式是其中一方改用 std::weak_ptr ——它不增加强引用计数，只在需要时调用 lock() 升级为 shared_ptr。

• std::weak_ptr 的 lock() 返回 std::shared_ptr，若原对象已被销毁，则返回空 shared_ptr；别直接解引用 weak_ptr，它没有 operator->
• 判断是否过期：用 wptr.expired() 比 wptr.lock() != nullptr 稍快，但语义一致；真正使用前仍建议先 lock() 再判空，避免竞态
• 注意：std::weak_ptr 本身也参与控制块的弱引用计数，控制块生命周期由强+弱引用共同决定；只有强引用为 0 且弱引用也为 0 时，控制块才释放

常见崩溃和误用场景（附错误信息提示）

很多 segfault 或 double-free 其实源于对控制块生命周期或所有权转移的理解偏差。

立即学习“C++免费学习笔记（深入）”；

• 崩溃点：对已 reset 的 shared_ptr 调用 get() 后解引用 → nullptr 解引用，报 Segmentation fault (core dumped)
• 崩溃点：用同一个裸指针重复初始化多个 shared_ptr → 控制块独立，最终 double free，报 double free or corruption
• 陷阱：从 this 构造 shared_ptr（如 std::shared_ptr(this)）——除非类继承自 std::enable_shared_from_this 并用 shared_from_this()，否则极大概率重复管理
• 性能坑：频繁调用 use_count() ——它是原子读，但无必要；仅用于调试，禁止用于逻辑分支（如 if (sp.use_count() == 1)）

控制块的存在形式、跨线程安全性边界、以及 weak_ptr 的“临时升级”机制，是理解 std::shared_ptr 行为差异的核心；实际写代码时，优先用 make_shared，禁用裸指针构造，循环引用必须显式拆解——这些不是最佳实践建议，而是避免 undefined behavior 的硬性约束。