shared_ptr循环引用通过weak_ptr打破，将其中一个shared_ptr改为weak_ptr，避免引用计数无法归零，确保对象析构时内存正确释放，如B类用weak_ptr指向A类，解除所有权依赖，解决内存泄漏。
C++中，
shared_ptr引发的循环引用问题，通常通过引入
weak_ptr来巧妙且安全地解决，它允许对象之间相互引用，同时避免内存泄漏，确保资源在不再被需要时能被正确释放。
解决方案
要解决
shared_ptr的循环引用，核心思路是打破其中一个引用链的“所有权”关系。我们通常会选择将循环中的一个
shared_ptr替换为
weak_ptr。
weak_ptr是一种不增加引用计数的智能指针，它仅仅是对一个
shared_ptr所管理对象的“弱引用”或“观察者”。当
weak_ptr所指向的对象不再存在时，它会自动失效。
假设我们有两个类
A和
B，它们各自持有一个指向对方的
shared_ptr，这将导致循环引用：
#include#include class B; // 前向声明 class A { public: std::shared_ptr ptrB; A() { std::cout << "A constructor" << std::endl; } ~A() { std::cout << "A destructor" << std::endl; } void setB(std::shared_ptr b) { ptrB = b; } }; class B { public: std::shared_ptr ptrA; // 这里是问题所在 B() { std::cout << "B constructor" << std::endl; } ~B() { std::cout << "B destructor" << std::endl; } void setA(std::shared_ptr a) { ptrA = a; } }; // 循环引用示例 void demonstrate_circular_reference() { std::shared_ptr a = std::make_shared(); std::shared_ptr b = std::make_shared(); a->setB(b); b->setA(a); // 当a和b离开作用域时，它们的引用计数都无法降到0 // 导致A和B的析构函数都不会被调用，内存泄漏 }
为了解决这个问题，我们将其中一个
shared_ptr改为
weak_ptr。通常，我们会选择在“子”或“从属”关系的一方持有对“父”或“主”关系的
weak_ptr。在这个例子中，我们可以让
B持有对
A的
weak_ptr：
立即学习“C++免费学习笔记（深入）”；
#include#include class B_fixed; // 前向声明 class A_fixed { public: std::shared_ptr ptrB; A_fixed() { std::cout << "A_fixed constructor" << std::endl; } ~A_fixed() { std::cout << "A_fixed destructor" << std::endl; } void setB(std::shared_ptr b) { ptrB = b; } }; class B_fixed { public: std::weak_ptr ptrA; // 关键改变：使用weak_ptr B_fixed() { std::cout << "B_fixed constructor" << std::endl; } ~B_fixed() { std::cout << "B_fixed destructor" << std::endl; } void setA(std::shared_ptr a) { ptrA = a; } // 访问ptrA时需要先lock() void accessA() { if (auto sharedA = ptrA.lock()) { // 尝试获取shared_ptr std::cout << "A_fixed object still exists and is accessible." << std::endl; } else { std::cout << "A_fixed object no longer exists." << std::endl; } } }; // 解决循环引用后的示例 void demonstrate_no_circular_reference() { std::shared_ptr a = std::make_shared (); std::shared_ptr b = std::make_shared (); a->setB(b); b->setA(a); // 当a和b离开作用域时： // 1. a的引用计数为1 (外部持有a) // 2. b的引用计数为1 (a->ptrB持有b) // 3. b->ptrA (weak_ptr) 不增加a的引用计数 // 当a离开作用域时，a的引用计数从1变为0，A_fixed析构 // 此时b->ptrA失效 // 当b离开作用域时，b的引用计数从1变为0，B_fixed析构 // 内存得到正确释放 } int main() { std::cout << "--- Demonstrating circular reference (will leak) ---" << std::endl; demonstrate_circular_reference(); std::cout << "--- End of circular reference demo ---" << std::endl << std::endl; std::cout << "--- Demonstrating no circular reference with weak_ptr ---" << std::endl; demonstrate_no_circular_reference(); std::cout << "--- End of no circular reference demo ---" << std::endl; return 0; }
运行上述
main函数，你会发现
demonstrate_circular_reference部分不会打印析构函数的消息，而
demonstrate_no_circular_reference部分会正确打印。这清晰地展示了
weak_ptr在解决循环引用方面的有效性。
为什么shared_ptr会引发循环引用问题？
shared_ptr的设计理念是基于“共享所有权”的。它通过维护一个引用计数（reference count）来跟踪有多少个
shared_ptr实例共同拥有同一个对象。每当一个
shared_ptr被创建或复制时，引用计数就增加；当一个
shared_ptr被销毁或重新赋值时，引用计数就减少。只有当引用计数降到零时，
shared_ptr才会自动释放其管理的对象（调用对象的析构函数）。
问题就出在这里：如果两个或更多个对象，通过
shared_ptr相互持有对方，形成一个闭环，那么这个环中的所有
shared_ptr的引用计数将永远无法降到零。举个例子，对象A持有一个指向对象B的
shared_ptr，同时对象B也持有一个指向对象A的
shared_ptr。当最初创建A和B的
shared_ptr离开作用域时，它们各自的引用计数会减少，但不会降到零，因为A内部的
shared_ptr仍在引用B，B内部的
shared_ptr仍在引用A。这就像两个人都握着对方的手，谁也无法先松开，最终导致这两个对象及其占用的内存永远无法被回收，形成内存泄漏。在我看来，这有点像一个死锁，只不过发生在内存管理层面，而不是线程同步。
weak_ptr是如何巧妙地打破循环引用的？
weak_ptr的巧妙之处在于它不参与对象的引用计数。它仅仅是
shared_ptr所管理对象的一个“非拥有型”观察者。你可以把它想象成一个侦察兵，它能看到目标，但目标的存在与否与它无关，它也不会去干预目标的生命周期。当一个
weak_ptr被创建时，它会指向一个
shared_ptr所管理的对象，但并不会增加该对象的引用计数。
这就意味着，即使存在一个
weak_ptr指向某个对象，只要所有
shared_ptr都放弃了对该对象的所有权（即引用计数降为零），该对象就会被销毁。此时，所有指向该对象的
weak_ptr都会自动失效（变为空）。
那么，我们如何通过
weak_ptr访问它所指向的对象呢？
weak_ptr提供了一个
lock()方法。调用
lock()会尝试返回一个
shared_ptr。如果它所观察的对象仍然存在（即还有
shared_ptr在管理它），
lock()就会成功返回一个有效的
shared_ptr，并且这个
shared_ptr会临时增加对象的引用计数。如果对象已经被销毁，
lock()就会返回一个空的
shared_ptr。这种机制完美地解决了“悬空指针”的问题，你总能安全地判断对象是否还存活。这种设计，我认为，是C++智能指针体系里非常优雅的一笔，既解决了复杂问题，又保持了安全性。
在实际项目中，何时选择使用weak_ptr？
weak_ptr不仅仅是解决循环引用的“解药”，它在很多其他场景下也扮演着重要的角色，尤其是在需要观察对象但又不希望拥有其所有权的场景。
父子/层级关系中子节点引用父节点： 这是一个非常经典的场景。比如一个UI控件（子）需要访问它的父容器（父），但父容器才是真正管理子控件生命周期的。如果子控件持有父容器的
shared_ptr
，就会形成循环引用。此时，子控件持有父容器的weak_ptr
是最佳选择。当父容器被销毁时，子控件的weak_ptr
会自动失效，避免了悬空引用。观察者模式（Observer Pattern）： 在事件驱动或观察者模式中，一个被观察者（Subject）可能需要持有多个观察者（Observer）的列表。如果被观察者持有观察者的
shared_ptr
，那么即使观察者本身已经不再被外部引用，它也无法被销毁。更糟糕的是，如果观察者又持有被观察者的shared_ptr
，就又回到了循环引用的老路。正确的做法是，被观察者持有观察者的weak_ptr
。这样，当观察者不再被外部需要时，它就能被正确销毁，被观察者列表中的weak_ptr
也会随之失效，被清理掉。缓存管理： 在一些缓存系统中，你可能希望缓存中的对象在没有其他地方引用它们时自动过期。如果缓存直接持有对象的
shared_ptr
，那么对象将永远不会被释放。如果缓存持有对象的weak_ptr
，那么当外部所有对该对象的shared_ptr
都释放后，对象就会被销毁，缓存中的weak_ptr
失效，下次访问时就能发现对象已不在，从而实现“弱缓存”。大型数据结构中的节点回溯： 想象一个图结构或者复杂的树，节点可能需要引用其邻居或父节点。如果所有引用都是
shared_ptr
，很容易形成意想不到的循环。weak_ptr
提供了一种安全的回溯机制，允许节点查询其关联对象是否存在，而不会强行延长其生命周期。
选择
weak_ptr时，需要稍微权衡一下。每次访问对象都需要调用
lock()并检查返回的
shared_ptr是否为空，这会带来一点点额外的开销和代码复杂度。但考虑到它带来的内存安全和逻辑清晰，这通常是非常值得的。毕竟，内存泄漏排查起来可比多写几行
if (auto shared_ptr_obj = weak_ptr_obj.lock())要头疼多了。
