标准C++未内置引用计数GC，因其违背“不为不用功能付费”原则；std::shared_ptr仅为RAII智能指针，非GC，需配合weak_ptr破循环引用，手动实现GC易陷注册/注销时机与线程安全陷阱。
为什么标准 C++ 没有内置引用计数 GC？
因为 C++ 的设计哲学是“不为不用的功能付费”，而引用计数需要在每次拷贝、赋值、析构时更新计数器，带来运行时开销和线程安全负担。标准库只提供 std::shared_ptr 这种**手动管理生命周期的智能指针**，它不是 GC，只是 RAII 封装；它不自动扫描对象图，也不回收循环引用。
如果你真想模拟一个轻量 GC，得自己补上两个关键能力：全局对象注册 + 周期性可达性分析。但注意：这会显著改变内存模型，且无法兼容裸指针或栈对象。
如何用 std::shared_ptr 避免常见循环引用崩溃？
循环引用是引用计数方案最典型的失效场景——比如 A 持有 std::shared_ptr<b></b>，B 又持有 std::shared_ptr<a></a>，两者引用计数永远 > 0，内存永不释放，最终导致泄漏甚至 OOM。
- 用
std::weak_ptr打破强引用环：只在需要临时访问时调用lock()，返回std::shared_ptr；若对象已销毁，则返回空指针 - 避免在类内部用
shared_ptr<this></this>：改用enable_shared_from_this<t></t>，通过shared_from_this()安全获取 - 检查
use_count()和expired()是调试利器，但别在生产逻辑里依赖它们做流程判断
示例：
立即学习“C++免费学习笔记（深入）”；
struct Node : std::enable_shared_from_this<Node> {
std::shared_ptr<Node> parent;
std::weak_ptr<Node> child; // 不增加引用计数
};
手写简易引用计数 GC 的核心陷阱
真要自己实现，最容易翻车的地方不是计数逻辑，而是**对象注册与注销时机**。你无法靠构造/析构函数自动完成注册——因为对象可能栈分配、可能 new 出来但没交给你管、也可能被 std::unique_ptr 管理。
- 必须要求所有受管对象继承自一个基类（如
GCObject），并在其构造函数里调用全局注册器 - 析构函数不能直接从注册表移除自身——此时虚函数表可能已失效；应改用延迟清理或标记-清除阶段统一处理
- 多线程下，
std::atomic<int></int>是底线，但std::shared_ptr内部的引用计数本身已是原子操作，重复加锁反而拖慢性能 - 没有写屏障（write barrier）机制，无法感知指针字段的修改，所以“可达性分析”只能靠定期遍历所有注册对象 + 手动维护引用图
什么情况下不如直接用 std::shared_ptr + std::weak_ptr？
绝大多数应用不需要额外 GC 层。只要结构清晰、明确所有权边界，RAII + 智能指针组合已经足够健壮。
- 游戏逻辑层的对象池管理
- 网络请求回调中跨作用域传递资源
- GUI 控件树中父子关系（父持子强引用，子持父弱引用）
真正需要“自动回收不可达对象”的场景极少，而且往往意味着架构已复杂到该引入更成熟的内存模型（比如 arena allocator 或借用检查器）。硬加一层 GC，容易变成既没解决循环引用，又拖慢所有指针操作的负优化。
引用计数不是银弹，它把释放时机从“确定点”变成了“不确定点”，而 C++ 开发者通常更信任确定性。
