C++没有真正的垃圾回收，其智能指针仅通过引用计数管理内存；shared_ptr遇循环引用会泄漏，需weak_ptr或手动解环；裸指针与智能指针混用将导致double-free或UB；且默认非线程安全。
C++ 没有、也不该有真正的垃圾回收（GC），所谓“GC 机制”在 C++ 里实际就是智能指针的引用计数逻辑，不是运行时自动扫描对象图的 GC。 试图用 std::shared_ptr 当成 Java 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></b>，B 又持有 shared_ptr<a></a>，两者引用计数永远 ≥1，析构函数永远不会被调用——内存泄漏，且无法被任何运行时机制发现或打断。
立即学习“C++免费学习笔记（深入）”；
解决方式只有两个：
- 一方改用
weak_ptr：它不增加引用计数，访问前需调用lock()转成shared_ptr，失败说明对象已销毁 - 手动打破循环：比如在析构函数中显式清空对方持有的指针，或用回调/信号机制解耦
注意：weak_ptr 不是“弱引用 GC”，它只是避免计数干扰，不提供自动清理能力。
裸指针和智能指针混用的典型 crash 场景
常见错误现象包括：
-
shared_ptr<t> p1(new T); T* raw = p1.get(); delete raw;</t>→ double-free，程序大概率崩溃 -
T* ptr = new T; shared_ptr<t> p1(ptr); shared_ptr<t> p2(ptr);</t></t>→ 两个独立计数器，各自 delete 同一块内存 -
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<size_t></size_t> 或启用编译器的线程安全模式。
