c++中shared_ptr的循环引用问题会导致内存泄漏，解决方法是使用weak_ptr。①循环引用发生在两个或多个shared_ptr相互持有对方，引用计数无法归零；②weak_ptr不增加引用计数，仅用于临时访问对象，通过lock()获取shared_ptr；③修改类定义，将其中一个shared_ptr改为weak_ptr即可打破循环；④使用weak_ptr时应注意不能直接操作对象、避免频繁调用lock()、合理判断是否需要强引用；⑤常见踩坑场景包括观察者模式、树形结构回指和缓存系统，应优先考虑是否需要强引用以避免不必要的依赖。
C++中，
shared_ptr的循环引用问题是个常见但容易忽视的陷阱。简单来说，就是两个或多个
shared_ptr互相持有对方，导致引用计数始终不为0，最终造成内存泄漏。
解决办法是使用
weak_ptr来打破这种循环。它不会增加对象的引用计数，只是一个“弱引用”，可以用来观察对象是否还活着，同时避免了强引用带来的循环依赖。
为什么会出现循环引用？
最典型的场景就是两个类之间相互持有
shared_ptr：
立即学习“C++免费学习笔记（深入）”；
class B; // 前向声明
class A {
public:
shared_ptr<B> ptr;
};
class B {
public:
shared_ptr<A> ptr;
};如果创建两个对象并让它们互指：
auto a = make_shared<A>(); auto b = make_shared<B>(); a->ptr = b; b->ptr = a;
这时候，
a和
b的引用计数都是1（外部有一个），但因为彼此也持有一个，所以即使外部不再使用，引用计数也不会变成0，无法释放资源。
weak_ptr 是怎么解决这个问题的？
用一句话说：weak_ptr
不会影响引用计数，只用于临时访问对象。
修改上面的例子很简单，把其中一个改为
weak_ptr即可：
class B; // 前向声明
class A {
public:
shared_ptr<B> ptr;
};
class B {
public:
weak_ptr<A> ptr; // 改成 weak_ptr
};这样，当
a被释放时，
b中的
ptr虽然还在，但它只是个“弱引用”，不会阻止
a被销毁。之后如果想访问这个对象，需要通过
lock()方法获取一个临时的
shared_ptr：
if (auto aPtr = b->ptr.lock()) {
// aPtr 是一个有效的 shared_ptr，可以安全使用
} else {
// 对象已经被释放
}使用 weak_ptr 的注意事项
-
不能直接操作对象：
weak_ptr
没有operator->
和operator*
，必须先调用lock()
转成shared_ptr
- 每次 lock() 都会产生一个新的 shared_ptr，所以要注意不要频繁调用，否则可能影响性能
-
不是万能药：如果逻辑本身就需要保持对象存活，那就不适合用
weak_ptr
，得重新设计结构
比如下面这段代码就有点滥用：
for (int i = 0; i < 100000; ++i) {
auto tmp = myWeakPtr.lock(); // 每次都 lock，效率低
if (tmp) tmp->doSomething();
}应该改成：
if (auto tmp = myWeakPtr.lock()) {
for (int i = 0; i < 100000; ++i) {
tmp->doSomething(); // 只 lock 一次
}
}实际开发中哪些地方容易踩坑？
-
观察者模式：订阅者保存的是
shared_ptr
，发布者又反过来持有订阅者，容易形成循环 -
树形结构：父子节点互相引用，父节点用
shared_ptr
，子节点也应该考虑用weak_ptr
回指 -
缓存系统：缓存项持有对象的
shared_ptr
，而其他模块也可能有同样的引用，如果不小心反过来引用缓存，就会出问题
遇到这些情况时，不妨多问一句：我这里真的需要一个强引用吗？如果不是必须的，就该换成
weak_ptr。
基本上就这些。
weak_ptr不是什么高级技巧，但用得好可以避免很多隐藏的内存泄漏问题。只要记住一点：不需要控制生命周期的地方，就尽量别用
shared_ptr。
