weak_ptr
在C++中扮演了一个非常独特的角色：它允许你“盯着”一个由
shared_ptr
管理的对象，却完全不参与到这个对象的生命周期管理中去。简单来说，它不会增加对象的引用计数。这意味着，当所有
shared_ptr
都不再指向那个对象时，即便还有
weak_ptr
在看着它，对象也会被干净利落地销毁。
weak_ptr
就像一个不持股的股东，只在公司还存在的时候，能看看它的运营情况，一旦公司破产清算，它也跟着失效，不会阻止公司的倒闭。
C++ weak_ptr
的设计初衷，在我看来，就是为了解决
shared_ptr
带来的一个潜在的“甜蜜的负担”——循环引用。当两个或多个对象互相持有对方的
shared_ptr
时，它们的引用计数永远不会降到零，导致它们永远不会被销毁，最终造成内存泄漏。
weak_ptr
正是为了打破这种僵局而生。它提供了一种非拥有（non-owning）的引用机制。一个
weak_ptr
可以从一个
shared_ptr
构造出来，它指向同一个对象，但并不会增加对象的引用计数。
要访问
weak_ptr
所指向的对象，你必须通过它的
lock()
方法。这个方法会尝试将
weak_ptr
提升（promote）为一个
shared_ptr
。如果对象仍然存在（即至少还有一个
shared_ptr
在管理它），
lock()
会成功返回一个有效的
shared_ptr
，并且这个临时的
shared_ptr
会增加对象的引用计数，确保在你使用它的这段时间内，对象不会被销毁。如果对象已经被销毁了，
lock()
就会返回一个空的
shared_ptr
。所以，在使用
weak_ptr
时，总要记得检查
lock()
的返回值是否为空，这是安全访问的关键一步。
weak_ptr
weak_ptr
到底解决了C++智能指针的什么痛点？
在我看来，
weak_ptr
主要解决了
shared_ptr
在处理复杂对象关系时可能出现的“死锁”——也就是我们常说的循环引用。想象一下，你有一个
Parent
类和一个
Child
类。如果
Parent
拥有
Child
的
shared_ptr
，而
Child
也拥有
Parent
的
shared_ptr
，那么当它们各自的
shared_ptr
都超出作用域时，它们的引用计数永远不会降到零，因为它们互相持有对方的强引用。这会导致内存泄漏，这些对象永远不会被析构。
立即学习“C++免费学习笔记（深入）”；
weak_ptr
在这里就扮演了“救星”的角色。我们可以让
Parent
持有
Child
的
shared_ptr
（这是强拥有关系，合情合理），但让
Child
持有
Parent
的
weak_ptr
。这样，
Child
可以观察到它的
Parent
，并在
Parent
还活着的时候访问它，但
Child
的存活与否并不会影响
Parent
的生命周期。当
Parent
的所有
shared_ptr
都释放后，它就会被销毁，此时
Child
持有的
weak_ptr
就会失效。这种设计完美地打破了循环引用，确保了内存能够被正确回收。除了循环引用，
weak_ptr
还在一些需要“非拥有”引用的场景中大放异彩，比如缓存机制或者观察者模式，这些我会在后面详细聊聊。
如何安全地从
weak_ptr
weak_ptr
访问被观察对象？
lock()
方法的工作原理是什么？
从
weak_ptr
安全地访问被观察对象，核心就是使用它的
lock()
方法。这是唯一“合法”的途径。你不能直接解引用
weak_ptr
，它没有提供
operator*
或
operator->
。这本身就是一种设计上的强制，提醒你它不是一个普通的指针。
lock()
方法的工作原理其实挺巧妙的。当你调用
weak_ptr::lock()
时，它会原子性地检查它所观察的对象是否仍然存在（即是否有至少一个
shared_ptr
还在管理这个对象）。
如果对象仍然存在：
lock()
会立即创建一个新的
shared_ptr
并返回。这个新的
shared_ptr
会增加对象的引用计数。这意味着，即使在
lock()
返回之后，所有原始的
shared_ptr
都消失了，只要你持有的这个由
lock()
返回的
shared_ptr
还在，对象就不会被销毁。它为你的操作提供了一个临时的“生命周期保障”。如果对象已经被销毁：
lock()
会返回一个空的
shared_ptr
（即
nullptr
）。这表明你观察的对象已经不存在了，此时你不应该尝试访问它。
因此，安全访问的范式总是这样的：
std::weak_ptr weakPtr = ...; // 从某个shared_ptr初始化if (auto sharedPtr = weakPtr.lock()) { // 对象仍然存在，可以安全地通过 sharedPtr 访问 MyClass 的成员 sharedPtr->doSomething(); // 在这个 if 块内，sharedPtr 确保了对象的存活} else { // 对象已经不存在了，或者说，它已经被销毁了 std::cout << "对象已失效或被销毁。" << std::endl;}
这种模式非常重要，因为它避免了经典的“use-after-free”错误。
lock()
操作本身是线程安全的，但在多线程环境下，一旦你获得了
shared_ptr
，对底层对象的进一步操作（尤其是修改）仍然需要你自行处理同步问题。
lock()
只保证了对象的存在性，不保证其内部状态的线程安全。
在实际项目中，哪些场景是
weak_ptr
weak_ptr
的典型应用？有没有一些容易踩的坑？
在实际的项目开发中，
weak_ptr
的应用场景远不止打破循环引用那么简单，它在一些特定设计模式中简直是不可或缺的。
典型应用场景：
打破循环引用： 这个前面已经提过了，是
weak_ptr
最核心的用武之地。例如，在双向链表或图结构中，如果节点之间互相持有
shared_ptr
，就会出现循环引用。通过让其中一个方向的指针使用
weak_ptr
，可以优雅地解决这个问题。缓存机制： 想象一个缓存系统，你希望缓存中的对象在还有其他地方强引用它们时保留，但一旦没有强引用，它们就应该被清理掉。
weak_ptr
非常适合这个场景。缓存可以存储指向这些对象的
weak_ptr
。当需要从缓存中获取对象时，先尝试
lock()
这个
weak_ptr
。如果
lock()
成功，说明对象还活着，可以返回一个
shared_ptr
供调用者使用；如果
lock()
失败，说明对象已被销毁，缓存就可以清理掉这个失效的
weak_ptr
条目。观察者模式/事件系统： 在观察者模式中，观察者（Observer）通常会注册到被观察者（Subject）上。如果被观察者持有观察者的
shared_ptr
，那么当观察者不再需要时，它可能无法被销毁，因为被观察者还在持有它。反过来，如果观察者持有被观察者的
shared_ptr
，那又可能导致被观察者无法销毁。最好的方式是被观察者持有观察者的
weak_ptr
。这样，被观察者不会阻止观察者被销毁，同时在通知观察者时，可以通过
lock()
检查观察者是否仍然存活。大型对象图的弱引用： 在一些复杂的、由大量对象构成的系统中，有时需要在一个对象内部引用另一个对象，但这种引用不应该影响被引用对象的生命周期。
weak_ptr
提供了一种轻量级的、非侵入性的引用方式。
容易踩的坑：
忘记调用
lock()
： 这是最常见的错误。
weak_ptr
本身不能直接解引用。很多新手会误以为它像原始指针一样可以直接
*weakPtr
或
weakPtr->member
，这是不行的，编译就会报错。你必须通过
lock()
获取一个
shared_ptr
才能进行操作。不检查
lock()
的返回值： 获取到
shared_ptr
后，一定要检查它是否为空。如果不检查，直接对一个空的
shared_ptr
进行解引用操作，就会导致运行时错误（通常是段错误）。这是
weak_ptr
最危险的地方之一，因为它允许对象在任何时候失效。误以为
weak_ptr
能延长对象的生命周期：
weak_ptr
的设计哲学就是“不拥有”。它绝不会增加引用计数，因此也绝不会延长对象的生命周期。它只是一个旁观者。如果你需要确保对象在某个操作期间存活，你必须通过
lock()
获取一个
shared_ptr
，并持有它。在多线程环境中对
lock()
返回的
shared_ptr
所指对象进行非原子操作：
lock()
本身是线程安全的，它会原子地获取
shared_ptr
。但是，一旦你获取到了
shared_ptr
，对它所指向的底层对象的访问（尤其是写操作）仍然需要你自行处理线程同步。
shared_ptr
和
weak_ptr
只管理引用计数和对象的生命周期，不管理底层数据的并发访问。过度使用或滥用
weak_ptr
： 并不是所有非拥有引用都需要
weak_ptr
。如果一个对象的生命周期完全由另一个对象控制，并且没有循环引用的风险，那么一个原始指针或引用可能更简单、性能更好。
weak_ptr
引入了额外的开销（原子操作、控制块），应该在确实需要其特定语义时才使用。
以上就是C++weak_ptr观察对象而不增加引用的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1474381.html
微信扫一扫 
支付宝扫一扫 
