C++中，
shared_ptr引发的循环引用问题，通常通过引入
weak_ptr来巧妙且安全地解决，它允许对象之间相互引用，同时避免内存泄漏，确保资源在不再被需要时能被正确释放。 解决方案
要解决
shared_ptr的循环引用，核心思路是打破其中一个引用链的“所有权”关系。我们通常会选择将循环中的一个
shared_ptr替换为
weak_ptr。
weak_ptr是一种不增加引用计数的智能指针，它仅仅是对一个
shared_ptr所管理对象的“弱引用”或“观察者”。当
weak_ptr所指向的对象不再存在时，它会自动失效。
假设我们有两个类
A和
B，它们各自持有一个指向对方的
shared_ptr，这将导致循环引用：
#include <iostream>
#include <memory>
class B; // 前向声明
class A {
public:
std::shared_ptr<B> ptrB;
A() { std::cout << "A constructor" << std::endl; }
~A() { std::cout << "A destructor" << std::endl; }
void setB(std::shared_ptr<B> b) { ptrB = b; }
};
class B {
public:
std::shared_ptr<A> ptrA; // 这里是问题所在
B() { std::cout << "B constructor" << std::endl; }
~B() { std::cout << "B destructor" << std::endl; }
void setA(std::shared_ptr<A> a) { ptrA = a; }
};
// 循环引用示例
void demonstrate_circular_reference() {
std::shared_ptr<A> a = std::make_shared<A>();
std::shared_ptr<B> b = std::make_shared<B>();
a->setB(b);
b->setA(a);
// 当a和b离开作用域时，它们的引用计数都无法降到0
// 导致A和B的析构函数都不会被调用，内存泄漏
} 为了解决这个问题，我们将其中一个
shared_ptr改为
weak_ptr。通常，我们会选择在“子”或“从属”关系的一方持有对“父”或“主”关系的
weak_ptr。在这个例子中，我们可以让
B持有对
A的
weak_ptr：
#include <iostream>
#include <memory>
class B_fixed; // 前向声明
class A_fixed {
public:
std::shared_ptr<B_fixed> 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_fixed> b) { ptrB = b; }
};
class B_fixed {
public:
std::weak_ptr<A_fixed> 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_fixed> 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_fixed> a = std::make_shared<A_fixed>();
std::shared_ptr<B_fixed> b = std::make_shared<B_fixed>();
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都会自动失效（变为空）。
PIA
全面的AI聚合平台，一站式访问所有顶级AI模型
226
查看详情
那么，我们如何通过
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())要头疼多了。
以上就是C++shared_ptr与weak_ptr结合解决循环引用的详细内容，更多请关注知识资源分享宝库其它相关文章！
相关标签： access ai c++ ios 作用域 为什么 red if count 析构函数 auto 循环 指针 数据结构 线程 空指针 对象 作用域 事件 ui 大家都在看： C++weak_ptr解决循环引用问题技巧 C++weak_ptr锁定对象并获取shared_ptr实例 如何正确使用C++的std::weak_ptr来观察对象是否存在 C++内存管理基础中weak_ptr避免循环引用的技巧 C++weak_ptr与事件回调结合使用技巧
发表评论:
◎欢迎参与讨论，请在这里发表您的看法、交流您的观点。