weak_ptr 转 shared_ptr 用 lock 方法详解

weak_ptr.lock()是唯一安全的提升方式，返回shared_ptr：对象存活则增加引用计数并返回有效指针，否则返回空；它是原子操作，线程安全，但必须检查返回值是否为空以避免解引用崩溃。

weak_ptr.lock() 是唯一安全的提升方式

直接用 shared_ptr 构造函数或赋值把 weak_ptr 转成 shared_ptr 会编译失败——weak_ptr 不提供隐式转换，也不接受裸指针构造。唯一合法、线程安全的提升方法就是调用 lock()。

它返回一个 shared_ptr：如果原 weak_ptr 指向的对象还活着，就增加引用计数并返回有效指针；如果对象已被释放，就返回空的 shared_ptr（ptr.get() == nullptr）。

• lock() 是原子操作，多线程下调用安全
• 返回的 shared_ptr 和原 shared_ptr 共享同一控制块，引用计数正确同步
• 不要对 lock() 结果做“先判空再用”的假设性解引用——必须检查返回值

不检查 lock() 返回值会导致崩溃

常见错误是忽略 lock() 可能返回空指针，直接解引用：

std::weak_ptr<int> wp = std::make_shared<int>(42);
// ... 期间原始 shared_ptr 被销毁
auto sp = wp.lock(); // 此时 sp 为空
std::cout << *sp; // 未定义行为：解引用空 shared_ptr → 崩溃或随机值

正确做法始终检查：

• 用 if (auto sp = wp.lock()) { /* 安全使用 sp */ }
• 或显式判断：if (sp) { ... }，sp.get() != nullptr 等价但更啰嗦
• 不能只靠 wp.expired() 提前判断——它和 lock() 之间存在竞态窗口（尤其多线程）

lock() 和 expired() 的行为差异与适用场景

expired() 只读取引用计数是否为 0，开销极小；lock() 尝试原子地增加计数，有轻微开销但带回了所有权。

• 仅需知道“对象是否还存在”（比如日志、统计、跳过处理）→ 用 expired()
• 需要访问对象内容或延长其生命周期 → 必须用 lock() 并检查结果
• 二者不是等价替代：即使 !wp.expired() 为 true，wp.lock() 仍可能返回空（极端竞态下控制块被销毁的瞬间）

循环引用中 weak_ptr.lock() 的典型误用

在父-子双向持有场景里，子用 weak_ptr 持父是标准解法。但容易在回调中写错：

struct Parent {
    std::shared_ptr<Child> child;
};
struct Child {
    std::weak_ptr<Parent> parent;
    void onEvent() {
        auto p = parent.lock(); // ✅ 正确：每次需要时都 lock
        if (p) p->doSomething();
    }
};

• 错误：把 lock() 结果缓存为成员变量（如 std::shared_ptr<Parent> cached_parent）——这又引入了强引用，可能复活已销毁对象或干扰析构顺序
• 错误：在构造函数里提前 lock() 并保存——此时父对象可能尚未完全构造完毕，引发未定义行为
• 原则：lock() 应该按需、就近、一次一用

真正容易被忽略的是：lock() 成功不代表对象处于可用状态——比如对象内部已进入析构中途（如虚函数表被清空），此时调用成员函数仍可能崩溃。所以业务逻辑层还需配合状态标记或 RAII 守卫。