C++实现简单的垃圾回收(GC)机制 _ 智能指针计数原理【详解】
C++没有真正的垃圾回收,其智能指针仅通过引用计数管理内存;shared_ptr遇循环引用会泄漏,需weak_ptr或手动解环;裸指针与智能指针混用将导致double-free或UB;且默认非线程安全。 先说个核心判断:C++ 从来就没有过真正的垃圾回收,也不该有。大家常说的“GC 机制”在 C++
C++没有真正的垃圾回收,其智能指针仅通过引用计数管理内存;shared_ptr遇循环引用会泄漏,需weak_ptr或手动解环;裸指针与智能指针混用将导致double-free或UB;且默认非线程安全。

先说个核心判断:C++ 从来就没有过真正的垃圾回收,也不该有。大家常说的“GC 机制”在 C++ 里,其实就是智能指针那个引用计数逻辑,不是 Ja va 或 Go 里那种运行时自动扫描对象图的方案。 如果谁真把 std::shared_ptr 当成 Ja va 的 GC 来用,那迟早要掉进循环引用或者裸指针混用的坑里,跑都跑不掉。
std::shared_ptr 的引用计数是怎么工作的
它不跟踪所有指针,只跟踪自己创建的 shared_ptr 实例。每次拷贝构造或赋值,内部计数器 +1;每次析构或 reset(),计数器 -1;计数归零时,自动调用 delete 托管对象,并释放计数器本身(独立堆分配)。
关键点有几个:
- 计数器和对象内存是分开的:不能把计数器塞进对象内部(除非侵入式设计),否则
delete obj会连计数器一起干掉 - 原始指针(
new Simple)一旦交给shared_ptr管理,就绝不能再用delete手动释放,也不能再用另一个shared_ptr用同一原始指针初始化(会 double-free) shared_ptr构造必须用make_shared或直接传new表达式,不能传栈地址、临时对象地址、或已由其他智能指针管理的地址
为什么 shared_ptr 不是 GC:循环引用问题
当 A 持有 shared_ptr,B 又持有 shared_ptr,两者引用计数永远 ≥1,析构函数永远不会被调用——这就是内存泄漏,而且没有任何运行时机制能发现或打断它。
解决方式只有两个:
- 一方改用
weak_ptr:它不增加引用计数,访问前需调用lock()转成shared_ptr,失败说明对象已销毁 - 手动打破循环:比如在析构函数中显式清空对方持有的指针,或用回调/信号机制解耦
注意:weak_ptr 不是“弱引用 GC”,它只是避免计数干扰,不提供自动清理能力。
裸指针和智能指针混用的典型 crash 场景
实践中常见的错误现象:
shared_ptr→ double-free,程序大概率崩溃p1(new T); T* raw = p1.get(); delete raw; T* ptr = new T; shared_ptr→ 两个独立计数器,各自 delete 同一块内存p1(ptr); shared_ptr p2(ptr); return &local_obj;然后用shared_ptr包装返回值 → 指向栈内存,析构时delete栈地址,UB(未定义行为)
根本原因在于:C++ 允许任意指针转换(reinterpret_cast)、无统一基类、无运行时类型信息(RTTI 不覆盖所有场景),所以任何“全局扫描指针图”的 GC 方案,在标准 C++ 下都无法安全实现。
如果你真需要类似 GC 的行为,只能妥协
这不是推荐做法,而是现实约束下的权衡:
- 用
std::shared_ptr+std::weak_ptr组合,严格约定所有权边界,禁用裸指针传递对象生命周期 - 对容器类(如树、图)做侵入式引用计数(
intrusive_ptr),把计数器嵌入对象,但要求所有使用者都走同一套接口 - 引入第三方库如
BDW GC(Boehm-Demers-Weiser),但它禁止栈上指针逃逸、不支持placement new、无法处理union中的指针,且与 STL 容器兼容性差
最常被忽略的一点:哪怕用了 shared_ptr,只要存在异常提前退出、或跨线程共享未加锁访问计数器(非原子操作),仍可能触发未定义行为——它默认是非线程安全的,多线程下必须用 std::atomic 或启用编译器的线程安全模式。


































