17370845950

shared_ptr循环引用发生在两个对象互相用shared_ptr持有对方，导致引用计数无法归零而内存泄漏；weak_ptr通过不增加引用计数来打破循环，需用lock()安全访问对象。

shared_ptr 循环引用到底怎么发生的

当两个 shared_ptr 互相持有对方管理的对象时，引用计数永远无法归零，对象就不会析构——这不是死锁，是资源泄漏。典型场景是双向链表节点、父子对象（如树节点中 parent 和 children 互相存 shared_ptr）。

比如 A 持有 shared_ptr，B 内部又持有 shared_ptr，两者构造完成后，各自的引用计数至少为 1，且彼此依赖，析构顺序失效。

weak_ptr 怎么打破这个循环

weak_ptr 不增加引用计数，只“观察”对象是否还活着。把它用在非拥有关系的一端（通常是反向指针），就能让引用计数回归真实所有权模型。

关键点：weak_ptr 不能直接访问对象，必须调用 lock() 转成 shared_ptr 才能使用；如果原对象已析构，lock() 返回空 shared_ptr。

• 只在需要“可能访问”的地方用 weak_ptr，比如 parent 指针、缓存句柄、回调上下文
• 不要对 weak_ptr 调用 get() 或解引用——它没有 operator->
• weak_ptr 构造开销极小，但 lock() 有原子操作成本，别在热路径频繁调用

一个可运行的父子节点循环引用修复示例

#include 
#include 

struct Child;
struct Parent {
    std::shared_ptr child;
    ~Parent() { std::cout << "Parent destroyed\n"; }
};

struct Child {
    std::weak_ptr parent; // ← 关键：这里用 weak_ptr
    ~Child() { std::cout << "Child destroyed\n"; }
};

int main() {
    auto p = std::make_shared();
    auto c = std::make_shar
ed();
    p->child = c;
    c->parent = p; // 不增加 p 的引用计数

    // 安全访问 parent（需检查 lock 是否成功）
    if (auto locked_p = c->parent.lock()) {
        std::cout << "Parent still alive\n";
    }

    return 0; // 输出：Child destroyed → Parent destroyed
}

注意：c->parent = p 这行不会延长 p 的生命周期；离开作用域后，c 先析构（无引用残留），接着 p 引用计数降为 0，正常析构。

weak_ptr 不是万能解药，这些坑得避开

用错位置反而引入空指针或竞态——weak_ptr 只解决循环引用，不解决线程安全或生命周期误判。

• 不要把 weak_ptr 存在全局容器里长期持有，容易变成悬空观察者
• 多线程中 lock() + 使用必须是原子逻辑，否则 lock() 成功后对象仍可能被其他线程释放
• 不能用 weak_ptr 替代原始指针做性能敏感的遍历（比如 vector 中大量 weak_ptr），lock() 的原子开销明显高于裸指针
• 调试时注意：weak_ptr.use_count() 返回的是它所观察的 shared_ptr 的当前引用计数，不是自己数量

最常被忽略的其实是语义：weak_ptr 表达的是“我不要所有权，只临时借用”，如果业务逻辑本质要求强持有，硬套 weak_ptr 只会让代码更难懂、更易出错。