std::shared_ptr是最实用的引用计数方案，因其线程安全、支持自定义删除器、分离式计数存储、weak_ptr破循环引用等特性，远超手写易出错的简易实现。
纯 C++ 标准库不提供自动垃圾回收（GC），但引用计数是一种可手动实现、轻量且确定性释放的内存管理方式——它不是 GC，但能解决大部分悬空指针和内存泄漏问题。
为什么 std::shared_ptr 是最实用的引用计数方案
自己手写引用计数容易出错：多线程竞争、构造/析构顺序、循环引用等。而 std::shared_ptr 已在标准库中被充分验证：
- 引用计数存储在堆上（与所管对象分离），避免对象大小膨胀
- 拷贝/赋值时原子更新计数（默认启用，可禁用以换性能）
- 支持自定义删除器，能管理非
new分配的资源（如mmap内存、C 风格句柄） -
std::weak_ptr可打破循环引用，这是手写计数器最难安全实现的部分
手写简易引用计数类会踩哪些坑
若出于学习或嵌入式限制必须手写，以下问题几乎必然出现：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 未将引用计数变量声明为
std::atomic<int>→ 多线程下计数错乱，提前释放或永不释放 - 在构造函数里直接 new 计数器，但构造抛异常 → 计数器泄露，且对象未建好
- 把计数器和对象放在同一块内存（intrusive design），却没对齐或忽略虚函数表偏移 → 读写越界
- 拷贝构造时先增计数再赋值，但赋值过程抛异常 → 计数已加，但指针未保存，泄漏
- 没有
release()或reset()接口 → 无法主动交出所有权，灵活性极差
std::shared_ptr 和 std::unique_ptr 怎么选
引用计数不是银弹。是否启用共享语义，决定了底层开销和行为：
立即学习“C++免费学习笔记（深入）”；
- 仅单所有者场景（如树节点、配置对象）→ 用
std::unique_ptr：零运行时代价，移动语义清晰，无原子操作 - 需多处临时持有、异步传递、缓存共享 → 用
std::shared_ptr：但注意，每次拷贝都触发原子加减，高频拷贝有可观开销 - 若只是观察不干预生命周期 → 优先用裸指针或
std::observer_ptr（C++17 起），避免无谓计数 - 循环引用风险高（如父子节点互相持
shared_ptr）→ 必须一方改用std::weak_ptr，且访问前调用lock()
真正需要“垃圾回收”的场景，C++ 通常该怎么做
比如游戏引擎中大量短生命周期对象、脚本对象绑定、或不可预测的引用图——这时引用计数也不够用：
- 不要自己实现标记-清除 GC：缺乏语言运行时支持（如栈根扫描、精确 GC），极易漏根导致悬挂
- 考虑分层策略：核心逻辑用
unique_ptr/shared_ptr；脚本层用第三方 GC 库（如Boehm GC），但需禁用其扫描 C++ 栈（易误判） - 更常见的是“伪 GC”：对象池 + 延迟销毁（帧末批量清理），配合
std::shared_ptr管理外部引用，既可控又高效 - 所有方案都绕不开一个事实：C++ 的内存管理权始终在程序员手上，所谓“自动”，只是把释放时机从显式
delete换成隐式计数归零——而计数归零那一刻，你依然得确保析构函数是安全的。
