C++ shared_ptr怎么避免循环引用导致的内存泄漏-C++-PHP中文网

shared_ptr循环引用必然导致内存泄漏，因强引用计数不归零则析构不触发，双方互持使计数恒为1；须将非拥有关系一端改为weak_ptr并lock()安全访问。

c++ shared_ptr怎么避免循环引用导致的内存泄漏

因为析构只发生在强引用计数归零时，而两个对象互相用shared_ptr持有对方，就等于各自给对方“搭了一只手”——哪怕外部所有shared_ptr都离开了作用域，它们内部的引用仍让计数卡在1，析构函数永远不会执行。

典型现象是：程序跑一段时间后内存持续上涨，valgrind或LeakSanitizer报告对象未释放，但use_count()查出来不是0；对象的析构日志完全不打印。

weak_ptr本身不解决泄漏，它只是把“我拥有你”改成“我可能用到你，但不决定你生死”。关键动作是：把非拥有关系那一端明确换成weak_ptr，再配合lock()安全访问。

比如父子结构中，子节点回引父节点属于典型的非拥有关系——父节点销毁，子节点不该跟着活下来；反之，父节点管理子节点生命周期，必须用shared_ptr。

改写Node::parent为std::weak_ptr<node></node>，保留Node::children为std::shared_ptr<node></node>
使用前必须调用parent.lock()，返回shared_ptr或空指针，不能直接解引用weak_ptr
expired()只是快速检查，真正要用还得lock()，否则存在竞态（对象可能在检查后、使用前被析构）

weak_ptr::lock()返回的是shared_ptr，但它可能是空的——说明目标对象已经被析构。跳过这步直接解引用，行为未定义，轻则崩溃，重则静默错误。

C++14

C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。

下载

正确写法不是if (wp.expired()) return;然后直接用wp.lock().get()，而是：

if (auto sp = wp.lock()) {
    // 安全使用 sp
    sp->do_something();
} else {
    // 对象已销毁，按业务逻辑处理（如清理缓存、重试、返回错误）
}

很多人以为只要用了shared_ptr就安全了，结果在std::vector<:shared_ptr>></:shared_ptr>里塞了一堆对象，其中某些对象又通过shared_ptr回指容器本身（比如回调注册），照样形成跨容器的循环引用。

更隐蔽的是闭包捕获：lambda里捕获[ptr = shared_from_this()]并注册进某个长期存活的服务，服务又把lambda存进自己的shared_ptr容器——这时候ptr和该服务就互持了。

回调场景优先考虑weak_ptr捕获：[weak_self = weak_from_this()]() { if (auto self = weak_self.lock()) { ... } }
避免在容器元素内部持有指向容器本身的shared_ptr，改用索引、ID 或外部管理的weak_ptr
std::vector<:unique_ptr>></:unique_ptr>比std::vector<:shared_ptr>></:shared_ptr>更不容易出循环引用，除非你主动把它传给别的对象

循环引用不是代码写错了，而是所有权关系没想清楚。用weak_ptr不是加个修饰符就完事，得先回答一个问题：“这个指针，是决定对方生死的关键一票，还是只在需要时临时借个光？”——答案决定了该用shared_ptr还是weak_ptr，也决定了lock()之后敢不敢直接用。