智能指针在STL中应用 shared_ptr使用场景分析-C++-PHP中文网

shared_ptr是内存管理的理想选择，因为它通过引用计数机制实现共享所有权，允许多个指针安全地共享同一资源，当最后一个shared_ptr销毁时资源自动释放，避免内存泄漏和悬空指针；在多所有权场景下，如缓存、图形渲染或事件系统，它能自动管理复杂生命周期；为防止循环引用导致内存泄漏，应使用weak_ptr打破引用环，weak_ptr不增加引用计数，仅作为观察者通过lock()安全访问对象；相比unique_ptr（独占所有权，轻量高效，适用于单一所有者场景）和原始指针（无所有权管理，易出错，仅用于性能敏感或非拥有观察），shared_ptr适用于资源被多方共享且生命周期不确定的场景，三者应根据所有权模型合理选用。

智能指针在STL中应用 shared_ptr使用场景分析

shared_ptr

登录后复制

在STL中，本质上是一种智能指针，它以引用计数的方式管理动态分配对象的生命周期，确保当没有任何

shared_ptr

登录后复制

实例指向该对象时，对象能够被安全地自动销毁。它的核心价值在于实现了“共享所有权”的概念，让多个指针可以安全地共同管理同一个资源，而无需手动追踪谁是最终的责任人。

解决方案

使用

std::shared_ptr

登录后复制

来管理资源非常直接。最推荐的方式是使用

std::make_shared

登录后复制

来创建对象，因为它能够一次性分配内存，同时用于对象本身和

shared_ptr

登录后复制

内部的控制块（包含引用计数等信息），这通常比先

new

登录后复制

再构造

shared_ptr

登录后复制

更高效且更安全，可以避免一些异常安全问题。

当你复制一个

shared_ptr

登录后复制

，或者将其赋值给另一个

shared_ptr

登录后复制

时，引用计数会自动增加。当一个

shared_ptr

登录后复制

实例离开其作用域（比如函数返回、局部变量销毁），或者被重新赋值指向另一个对象时，引用计数会自动减少。当引用计数降到零时，

shared_ptr

登录后复制

会自动调用其内部指向对象的析构函数，并释放内存。

#include <iostream>
#include <memory>
#include <vector>

class MyResource {
public:
    MyResource(int id) : id_(id) {
        std::cout << "MyResource " << id_ << " created.\n";
    }
    ~MyResource() {
        std::cout << "MyResource " << id_ << " destroyed.\n";
    }
    void doSomething() {
        std::cout << "MyResource " << id_ << " doing something.\n";
    }
private:
    int id_;
};

void processResource(std::shared_ptr<MyResource> res) {
    std::cout << "Inside processResource, ref count: " << res.use_count() << "\n";
    res->doSomething();
} // res 离开作用域，引用计数减一

int main() {
    // 推荐使用 make_shared
    auto res1 = std::make_shared<MyResource>(1);
    std::cout << "res1 ref count after creation: " << res1.use_count() << "\n";

    // 复制 shared_ptr，引用计数增加
    std::shared_ptr<MyResource> res2 = res1;
    std::cout << "res1 ref count after copy to res2: " << res1.use_count() << "\n";

    processResource(res1); // 传递 shared_ptr，临时增加引用计数

    std::cout << "res1 ref count after processResource: " << res1.use_count() << "\n";

    // 将 shared_ptr 放入容器
    std::vector<std::shared_ptr<MyResource>> resources;
    resources.push_back(res1);
    std::cout << "res1 ref count after push_back: " << res1.use_count() << "\n";

    // 当所有 shared_ptr 都离开作用域，对象才会被销毁
    // 比如 res1, res2, 以及 resources 向量中的元素都销毁后
    // MyResource 1 才会被销毁
    return 0;
}

登录后复制

为什么在多所有权场景下，

shared_ptr

登录后复制

是内存管理的理想选择？

在我看来，

shared_ptr

登录后复制

最闪耀的舞台，就是那些资源需要被多个“所有者”同时使用，且这些所有者对资源的生命周期都有发言权，但又无法确定谁是最后一个使用者的场景。这和那种“一个萝卜一个坑”的独占式所有权（

unique_ptr

登录后复制

的领域）完全不同。

想象一下，你有一个缓存系统，里面存放着一些从数据库加载进来的数据对象。这些数据对象可能会被UI层、业务逻辑层、甚至后台任务同时访问。如果用原始指针，你很难判断什么时候可以安全地释放这些数据：是UI关闭了？还是业务逻辑处理完了？如果某个后台任务还在异步处理它呢？这时，

shared_ptr

登录后复制

的引用计数机制就显得非常优雅了。每个需要访问这个数据的地方都持有一个

shared_ptr

登录后复制

，只要有一个

shared_ptr

登录后复制

还“活着”，数据就不会被销毁。只有当所有持有者都放弃了对它的引用，数据才会自动清理。这极大地简化了复杂的资源生命周期管理，避免了手动释放可能带来的悬空指针或重复释放的问题。

再比如，在图形渲染中，一个纹理资源可能被多个渲染对象共享，每个对象都需要这个纹理，但谁也不是它的唯一拥有者。或者在事件驱动系统中，一个事件对象可能被多个监听器订阅，每个监听器都可能在处理它。这些都是

shared_ptr

登录后复制

大展身手的地方。它提供了一种透明且自动的资源管理方式，让开发者可以更专注于业务逻辑本身，而不是纠结于内存的分配与释放。

使用

shared_ptr

登录后复制

时如何避免循环引用导致的内存泄漏？

这是一个非常经典且容易踩的坑，也是

shared_ptr

登录后复制

设计中一个不得不面对的副作用。当两个或多个对象通过

shared_ptr

登录后复制

互相引用时，它们会形成一个引用环。例如，对象A持有一个指向对象B的

shared_ptr

登录后复制

，同时对象B又持有一个指向对象A的

shared_ptr

登录后复制

。在这种情况下，即使外部已经没有其他

shared_ptr

登录后复制

指向A或B，它们的引用计数也永远不会降到零（因为它们互相引用），从而导致这两个对象及其关联的内存永远不会被释放，造成内存泄漏。

解决这个问题的“利器”就是

std::weak_ptr

登录后复制

。

weak_ptr

登录后复制

是一种非拥有型的智能指针。它指向一个由

shared_ptr

登录后复制

管理的对象，但它本身不增加对象的引用计数。这意味着

weak_ptr

登录后复制

不会阻止对象被销毁。你可以把

weak_ptr

登录后复制

想象成一个“观察者”或者“旁观者”，它知道某个对象存在，但它不参与对象的生命周期管理。

AppMall应用商店

AI应用商店，提供即时交付、按需付费的人工智能应用服务

查看详情

当你想访问

weak_ptr

登录后复制

指向的对象时，你需要先调用它的

lock()

登录后复制

方法。

lock()

登录后复制

会尝试返回一个

shared_ptr

登录后复制

。如果对象仍然存在（即引用计数大于零），

lock()

登录后复制

会成功返回一个有效的

shared_ptr

登录后复制

，此时引用计数会临时增加；如果对象已经被销毁，

lock()

登录后复制

会返回一个空的

shared_ptr

登录后复制

。通过检查

lock()

登录后复制

的返回值是否为空，你就可以安全地判断对象是否仍然有效。

在设计数据结构时，特别是涉及到父子关系、观察者模式或图结构时，如果存在循环引用，通常的做法是让强所有权（

shared_ptr

登录后复制

）指向下游或被观察者，而让上游或观察者持有对下游的

weak_ptr

登录后复制

。例如，一个父节点拥有子节点的

shared_ptr

登录后复制

，但子节点如果需要引用父节点，则应该使用

weak_ptr

登录后复制

。这样，当父节点被销毁时，子节点的引用计数会减少，最终子节点也会被销毁，从而打破循环。这种模式既能确保对象被正确管理，又能有效避免内存泄漏。

shared_ptr

登录后复制

与

unique_ptr

登录后复制

、原始指针相比，各自的适用场景是什么？

选择哪种指针，很多时候取决于你对资源“所有权”的理解和设计。这三者各有各的优势和适用范围，没有绝对的优劣之分。

std::unique_ptr

登录后复制

代表的是“独占所有权”。顾名思义，一个资源只能被一个

unique_ptr

登录后复制

拥有。当这个

unique_ptr

登录后复制

被销毁时，它所管理的资源也会被销毁。它的特点是轻量级，几乎没有运行时开销（除了可能的析构函数调用），因为它不需要维护引用计数。它的所有权是可转移的，但不可复制。这使得它非常适合实现RAII（Resource Acquisition Is Initialization）原则，比如管理文件句柄、网络连接、或者只在特定作用域内使用的动态内存。如果你明确知道一个对象只有一个所有者，并且这个所有者的生命周期就是对象的生命周期，那么

unique_ptr

登录后复制

无疑是最佳选择。它比

shared_ptr

登录后复制

更高效，也更明确地表达了设计意图。

std::shared_ptr

登录后复制

，如前所述，代表的是“共享所有权”。它允许多个

shared_ptr

登录后复制

实例共同管理同一个资源。它的开销相对

unique_ptr

登录后复制

要大一些，因为它需要维护一个引用计数，并且引用计数的增减通常涉及到原子操作（为了线程安全）。它适用于资源需要被多个模块或对象共享，且其生命周期由所有引用它的模块共同决定的场景。当最后一个

shared_ptr

登录后复制

被销毁时，资源才会被释放。这种模式在构建复杂的系统，尤其是需要缓存、对象池、或者多线程环境下共享数据时非常有用。

至于原始指针（raw pointer），它不具备任何所有权语义。它仅仅是一个内存地址。使用原始指针时，内存的管理完全由程序员手动负责。这意味着你需要自己去

new

登录后复制

和

delete

登录后复制

，并确保每次

new

登录后复制

都有对应的

delete

登录后复制

，且不会出现重复

delete

登录后复制

或

delete

登录后复制

后访问的情况。这无疑是内存管理中最容易出错的方式。然而，原始指针并非一无是处。在某些低层级的、性能敏感的代码中，或者当你只是想“观察”一个对象而不承担其所有权时（比如函数参数只是为了读取数据而不改变其生命周期），原始指针仍然有其用武之地。但即便如此，现代C++编程实践中，也强烈建议尽可能使用智能指针来替代原始指针，以减少内存相关的错误。当你从智能指针中获取原始指针并传递给其他函数时，一定要清楚谁负责资源的生命周期，避免混淆。

总结来说，如果资源是独占的，用