如何正确使用C++的std::weak_ptr来观察对象是否存在

P粉602998670

发布时间：2025-09-08 09:53:01

139人浏览过

来源于php中文网

原创

std::weak_ptr通过lock()方法安全观察由std::shared_ptr管理的对象，避免循环引用和内存泄漏。其核心是：调用lock()时若对象仍存在，则返回有效std::shared_ptr并延长其生命周期；否则返回空指针，确保不会访问已销毁对象。多线程下lock()为原子操作，保证安全性。使用时需始终检查lock()返回值，避免直接解引用或依赖expired()判断对象状态，防止崩溃或竞态条件。频繁调用lock()可能带来性能开销，需权衡使用。

如何正确使用c++的std::weak_ptr来观察对象是否存在

std::weak_ptr

在C++中扮演着一个“观察者”的角色，它允许你安全地引用一个由

std::shared_ptr

管理的对象，而不会影响该对象的生命周期。简单来说，要正确使用它来观察对象是否存在，你需要先将

std::weak_ptr

尝试提升（lock）为一个

std::shared_ptr

。如果提升成功，说明对象仍然存在且有效；如果提升失败（返回一个空的

std::shared_ptr

），则表明原始对象已经被销毁了。这是它最核心的用法。

解决方案

使用

std::weak_ptr

来观察对象，其核心机制在于它的

lock()

成员函数。当你从一个

std::shared_ptr

构造一个

std::weak_ptr

时，你实际上是创建了一个不拥有资源所有权的指针。这个弱指针仅仅是记录了它所指向资源的控制块信息。当你想访问这个资源时，必须通过调用

weak_ptr::lock()

来获取一个临时的

std::shared_ptr

。

这个

lock()

操作是原子性的，它会检查资源是否仍然存在。如果资源还在，它会增加资源控制块中的

shared_ptr

计数，并返回一个新的

std::shared_ptr

，这样你就安全地持有了该资源。如果资源已经被销毁（即所有

std::shared_ptr

都已释放），

lock()

会返回一个空的

std::shared_ptr

。

下面是一个简单的例子，展示了如何使用它：

立即学习“C++免费学习笔记（深入）”；

#include 
#include 
#include 
#include 
#include 

class MyObject {
public:
    std::string name;
    MyObject(const std::string& n) : name(n) {
        std::cout << "MyObject " << name << " created." << std::endl;
    }
    ~MyObject() {
        std::cout << "MyObject " << name << " destroyed." << std::endl;
    }
    void doSomething() {
        std::cout << "MyObject " << name << " is doing something." << std::endl;
    }
};

void observe(std::weak_ptr weakObj, const std::string& observerName) {
    std::cout << "[" << observerName << "] Trying to observe..." << std::endl;
    if (std::shared_ptr sharedObj = weakObj.lock()) {
        // 对象存在，可以安全访问
        std::cout << "[" << observerName << "] Object " << sharedObj->name << " is alive!" << std::endl;
        sharedObj->doSomething();
    } else {
        // 对象已被销毁
        std::cout << "[" << observerName << "] Object no longer exists." << std::endl;
    }
}

int main() {
    std::shared_ptr strongObj = std::make_shared("Alpha");
    std::weak_ptr weakRef = strongObj; // weak_ptr 观察 strongObj

    // 第一次观察：对象存在
    observe(weakRef, "Observer A");

    std::cout << "\nReleasing strong reference..." << std::endl;
    strongObj.reset(); // 释放 strongObj，此时 MyObject "Alpha" 被销毁

    // 第二次观察：对象已被销毁
    observe(weakRef, "Observer B");

    // 演示在多线程环境下的观察（虽然这里没有实际并发销毁）
    std::shared_ptr anotherObj = std::make_shared("Beta");
    std::weak_ptr weakRef2 = anotherObj;

    std::thread t1([&]() {
        std::this_thread::sleep_for(std::chrono::milliseconds(50)); // 模拟一些延迟
        observe(weakRef2, "Thread Observer 1");
    });

    std::thread t2([&]() {
        std::this_thread::sleep_for(std::chrono::milliseconds(10)); // 模拟一些延迟
        std::cout << "[Main Thread] Releasing anotherObj..." << std::endl;
        anotherObj.reset(); // 在t1可能观察之前或之后销毁
    });

    t1.join();
    t2.join();

    return 0;
}

在这个例子中，

observe

函数清晰地展示了如何通过

lock()

来安全地检查和访问对象。当

strongObj

被

reset()

后，

MyObject("Alpha")

的生命周期结束，

weakRef.lock()

便会返回一个空的

std::shared_ptr

，从而安全地指示对象已不存在。

为什么不直接用

std::shared_ptr

来观察对象？

这其实是个很关键的问题，也是

std::weak_ptr

存在的主要原因。如果我们在所有需要“观察”对象的地方都直接使用

std::shared_ptr

，那么这些观察者本身就会成为对象生命周期的一部分。这意味着，只要有一个

std::shared_ptr

还在引用着这个对象，对象就不会被销毁。这听起来好像没什么问题，但它很容易导致一种叫做“循环引用”的内存泄漏。

想象一下，你有两个对象A和B，它们都需要持有对方的

std::shared_ptr

来协同工作。比如，A有一个指向B的

std::shared_ptr

，B也有一个指向A的

std::shared_ptr

。当所有外部对A和B的引用都消失时，A的

shared_ptr

计数会因为B持有它而保持为1，B的

shared_ptr

计数也会因为A持有它而保持为1。结果就是，A和B谁也无法被销毁，它们会永远存在于内存中，造成内存泄漏。

std::weak_ptr

就是为了打破这种僵局而生的。它允许你建立一种非拥有型的引用。当A持有B的

std::shared_ptr

，而B持有A的

std::weak_ptr

时，情况就不同了。A的销毁取决于外部引用和B的

shared_ptr

（如果B持有A的

shared_ptr

）。但如果B只持有A的

std::weak_ptr

，那么A的生命周期完全由外部的

std::shared_ptr

决定，B的引用不会阻止A的销毁。一旦A被销毁，B通过

lock()

尝试获取A的

shared_ptr

时就会失败，从而知道A已经不在了。这种机制有效地解决了循环引用问题，让对象能够按照预期被回收。

如果观察的对象在我尝试访问时被销毁了怎么办？

这是

std::weak_ptr

设计中最精妙和安全的地方。当你调用

weak_ptr::lock()

时，这个操作是线程安全的。它会在内部原子性地检查被观察对象是否还存在。如果对象存在，它会立即增加该对象的

shared_ptr

引用计数，然后返回一个新的

std::shared_ptr

。一旦你获得了这个

std::shared_ptr

，你就安全地“拥有”了该对象的一个引用，保证了在你持有这个

shared_ptr

的整个作用域内，对象都不会被销毁。

如果对象在

lock()

被调用时已经不存在了（即所有

std::shared_ptr

都已释放），

lock()

会直接返回一个空的

std::shared_ptr

。你只需要简单地检查返回的

shared_ptr

是否为空，就能知道对象是否还在。

Type Studio

一个视频编辑器，提供自动转录、自动生成字幕、视频翻译等功能

下载

#include 
#include 
#include 
#include 

class Data {
public:
    int value;
    Data(int v) : value(v) { std::cout << "Data " << value << " created." << std::endl; }
    ~Data() { std::cout << "Data " << value << " destroyed." << std::endl; }
};

void access_data_safely(std::weak_ptr weakData, const std::string& caller) {
    std::this_thread::sleep_for(std::chrono::milliseconds(50)); // 模拟一些工作
    std::cout << "[" << caller << "] Attempting to access data..." << std::endl;
    if (std::shared_ptr strongData = weakData.lock()) {
        std::cout << "[" << caller << "] Data " << strongData->value << " is still here!" << std::endl;
    } else {
        std::cout << "[" << caller << "] Data has been destroyed." << std::endl;
    }
}

int main() {
    std::shared_ptr myData = std::make_shared(100);
    std::weak_ptr weakRef = myData;

    std::thread t1(access_data_safely, weakRef, "Thread A");

    // 主线程稍微等待，然后销毁对象
    std::this_thread::sleep_for(std::chrono::milliseconds(10));
    std::cout << "[Main] Resetting myData..." << std::endl;
    myData.reset(); // 对象在这里可能被销毁，取决于t1的执行速度

    t1.join(); // 等待线程A完成

    // 再次尝试访问，这次肯定会失败
    access_data_safely(weakRef, "Main Thread After Reset");

    return 0;
}

在这个多线程的例子中，

Thread A

在尝试访问

Data

对象时，可能会遇到

myData

已经被主线程

reset()

的情况。但由于

lock()

的原子性，它要么安全地获得一个有效的

shared_ptr

并访问数据，要么获得一个空的

shared_ptr

并知道数据已不存在。它永远不会访问到已经被释放的内存，这就是

std::weak_ptr

提供的主要安全性保障。

使用

std::weak_ptr

时有哪些性能考量和常见陷阱？

std::weak_ptr

虽然解决了循环引用和安全观察的问题，但它并非没有代价。了解这些有助于更高效、更正确地使用它。

性能考量：

lock()
操作的开销：每次调用
```
weak_ptr::lock()
```
都会涉及到对引用计数控制块的原子操作（例如增加
```
shared_ptr
```
计数）。原子操作通常比非原子操作慢，因为它需要确保多线程环境下的数据一致性。如果在一个紧密的循环中频繁调用
```
lock()
```
，可能会引入不小的性能开销。
额外的内存开销：
```
std::weak_ptr
```
本身和它所引用的控制块都会占用一定的内存。控制块存储了
```
shared_ptr
```
和
```
weak_ptr
```
的引用计数，以及自定义删除器等信息。虽然通常可以忽略不计，但在极端内存敏感的场景下也需要考虑。

常见陷阱：

忘记检查
```
lock()
```
的返回值： 这是最常见的错误。有些人可能会直接写成
```
weak_ptr.lock()->doSomething()
```
，如果对象已经被销毁，
```
lock()
```
返回空指针，然后尝试解引用这个空指针就会导致程序崩溃。始终要像前面示例那样，将
```
lock()
```
的结果赋给一个
```
std::shared_ptr
```
并检查其有效性。
```
// 错误示例：可能导致崩溃
// weakPtr.lock()->doSomething();

// 正确做法
if (auto sp = weakPtr.lock()) {
    sp->doSomething();
} else {
    // 处理对象已不存在的情况
}
```
误用
```
expired()
```
：
```
weak_ptr::expired()
```
函数可以告诉你当前
```
weak_ptr
```
是否已过期（即它指向的对象是否已销毁）。然而，
```
expired()
```
本身不是线程安全的，它只在你调用它的那一刻给出状态。在多线程环境中，你调用
```
expired()
```
返回
```
false
```
后，对象可能在下一微秒就被其他线程销毁了。因此，
```
expired()
```
主要用于调试或作为一种快速但非严格的检查，真正安全的做法仍然是通过
```
lock()
```
。
```
// 尽管 expired() 返回 false，对象也可能在下一刻被销毁
if (!weakPtr.expired()) {
    // 这里不能保证对象仍然存在，如果此时对象被销毁，lock() 会返回 nullptr
    if (auto sp = weakPtr.lock()) {
        sp->doSomething();
    }
}
```
试图直接解引用
```
std::weak_ptr
```
：
```
std::weak_ptr
```
没有提供
```
operator*
```
或
```
operator->
```
。你不能直接解引用一个
```
weak_ptr
```
，这是为了强制你通过
```
lock()
```
来安全地访问底层对象。这种设计就是为了避免在对象生命周期不确定的情况下进行不安全的访问。
在循环中频繁创建
```
std::shared_ptr
```
：如果你在一个循环中反复调用
```
lock()
```
并将其结果存储在一个
```
std::shared_ptr
```
中，而这个
```
shared_ptr
```
的作用域超出了循环的单次迭代，你可能会不必要地延长对象的生命周期。确保
```
lock()
```
返回的
```
shared_ptr
```
在不再需要时尽快销毁，让引用计数及时下降。