首页 > 后端开发 > C++ > 正文

C++如何使用智能指针与容器结合管理内存

P粉602998670
发布: 2025-09-04 12:50:02
原创
221人浏览过
在C++中,应优先使用智能指针管理容器中的动态对象,以避免内存泄漏和悬空指针。std::unique_ptr适用于独占所有权场景,性能高且无引用计数,适合std::vector等线性容器存储多态对象;而std::shared_ptr用于共享所有权,通过引用计数管理生命周期,适用于std::map等需共享资源的场景,但需警惕循环引用。混合使用原始指针与智能指针会导致双重释放、悬空指针和所有权混乱等风险,应避免。通过定制删除器,智能指针可管理文件句柄、C风格数组等非内存资源,实现RAII的通用资源管理。

c++如何使用智能指针与容器结合管理内存

在C++中,将智能指针与容器结合使用是管理动态内存、避免内存泄漏和确保资源安全的关键实践。它通过RAII(资源获取即初始化)原则,让对象在离开作用域时自动释放所持有的资源,极大地简化了内存管理,并提高了代码的健壮性。简单来说,就是把那些需要手动

new
登录后复制
出来的对象,用
std::unique_ptr
登录后复制
std::shared_ptr
登录后复制
包装起来,再把这些智能指针放入容器,让智能指针替你操心内存的生老病死。

解决方案

说实话,每次看到代码里大量裸指针在容器里跳来跳去,我心里都会咯噔一下。这不光是代码美观的问题,更是潜在的灾难。C++11之后,智能指针的引入简直是福音。

核心思路是:当你的容器需要存储动态分配的对象时,不要直接存储原始指针,而是存储智能指针。这解决了几个老大难的问题:

  1. 内存泄漏:容器销毁时,智能指针会自动释放其管理的内存。
  2. 异常安全:即使在函数执行过程中抛出异常,智能指针也能保证内存被正确释放。
  3. 所有权语义清晰
    std::unique_ptr
    登录后复制
    明确表示独占所有权,
    std::shared_ptr
    登录后复制
    则表示共享所有权,这让代码意图一目了然。

使用

std::unique_ptr
登录后复制

立即学习C++免费学习笔记(深入)”;

当你确定容器中的每个元素都拥有其所管理对象的唯一所有权时,

std::unique_ptr
登录后复制
是首选。它的开销非常小,因为它不涉及引用计数。它最适合用在
std::vector
登录后复制
std::list
登录后复制
std::deque
登录后复制
这种线性容器中,尤其是当你需要存储多态对象时。

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

class Base {
public:
    virtual void greet() const { std::cout << "Hello from Base!" << std::endl; }
    virtual ~Base() { std::cout << "Base destructor called." << std::endl; }
};

class Derived : public Base {
public:
    void greet() const override { std::cout << "Hello from Derived!" << std::endl; }
    ~Derived() { std::cout << "Derived destructor called." << std::endl; }
};

// 示例:使用 unique_ptr 存储多态对象
std::vector<std::unique_ptr<Base>> objects;
objects.push_back(std::make_unique<Derived>()); // 推荐使用 make_unique
objects.push_back(std::make_unique<Base>());

for (const auto& obj_ptr : objects) {
    obj_ptr->greet();
}
// 当 objects 离开作用域时,所有 Base 和 Derived 对象都会被正确销毁
登录后复制

使用

std::shared_ptr
登录后复制

如果你需要多个智能指针共同拥有同一个对象,并且在所有拥有者都消失后才释放对象,那么

std::shared_ptr
登录后复制
是你的选择。它通过引用计数来管理对象的生命周期,当引用计数降为零时,对象才会被销毁。这在
std::map
登录后复制
std::set
登录后复制
这种需要共享对象引用的场景中特别有用,或者在构建复杂的图结构时。

#include <map>
#include <memory>
#include <string>
#include <iostream>

class Resource {
public:
    std::string name;
    Resource(std::string n) : name(std::move(n)) {
        std::cout << "Resource " << name << " created." << std::endl;
    }
    ~Resource() {
        std::cout << "Resource " << name << " destroyed." << std::endl;
    }
};

// 示例:使用 shared_ptr 存储共享资源
std::map<std::string, std::shared_ptr<Resource>> shared_resources;

// 创建一个共享资源
auto r1 = std::make_shared<Resource>("DatabaseConnection");
shared_resources["db_conn_1"] = r1;
shared_resources["db_conn_2"] = r1; // 两个键共享同一个 Resource 对象

std::cout << "Reference count for r1: " << r1.use_count() << std::endl;

// 另一个 shared_ptr 也可以指向它
std::shared_ptr<Resource> another_ref = shared_resources["db_conn_1"];
std::cout << "Reference count for r1 after another_ref: " << r1.use_count() << std::endl;

// 当所有 shared_ptr 都离开作用域或被重置时,Resource 才会被销毁
登录后复制

记住,

std::make_unique
登录后复制
std::make_shared
登录后复制
是创建智能指针的最佳实践,它们不仅能避免重复的类型书写,还能提供异常安全保证和性能优化。

在C++容器中,何时选择
std::unique_ptr
登录后复制
而非
std::shared_ptr
登录后复制

这其实是个老生常谈的问题,但总有人会踩坑。我的经验是,能用

unique_ptr
登录后复制
就尽量用
unique_ptr
登录后复制
,除非你真的需要共享所有权。

选择

std::unique_ptr
登录后复制
的场景:

  1. 独占所有权:这是最核心的理由。如果一个对象在容器中被创建,并且它的生命周期完全由这个容器中的智能指针来管理,没有其他地方会“拥有”它,那么
    unique_ptr
    登录后复制
    是完美的。比如,一个
    std::vector<std::unique_ptr<MyObject>>
    登录后复制
    ,每个
    MyObject
    登录后复制
    实例都只属于
    vector
    登录后复制
    中的一个位置。
  2. 性能考量
    unique_ptr
    登录后复制
    的开销非常小,因为它不涉及引用计数。这意味着更快的创建、销毁和赋值操作。在性能敏感的场景下,或者容器中对象数量非常庞大时,这点差异可能会累积起来。
    shared_ptr
    登录后复制
    需要维护一个引用计数器,这会带来额外的内存开销和原子操作的性能成本。
  3. 移动语义
    unique_ptr
    登录后复制
    是可移动但不可复制的。这意味着你可以高效地将对象的所有权从一个
    unique_ptr
    登录后复制
    转移到另一个
    unique_ptr
    登录后复制
    ,或者从容器中取出
    unique_ptr
    登录后复制
    并转移所有权。这对于很多现代C++编程模式来说非常自然。
  4. 避免循环引用
    shared_ptr
    登录后复制
    最让人头疼的问题之一就是循环引用,这会导致内存泄漏(两个或多个对象相互持有
    shared_ptr
    登录后复制
    ,导致引用计数永远不为零)。
    unique_ptr
    登录后复制
    根本没有引用计数,所以不存在这个问题。

什么时候你可能不得不考虑

std::shared_ptr
登录后复制

当你确实需要多个智能指针共同管理同一个对象的生命周期时。例如,你有一个图形场景,多个节点可能引用同一个纹理或模型数据;或者在一个缓存系统中,多个用户可能同时访问同一个数据块。在这种情况下,

shared_ptr
登录后复制
是必要的,但也要警惕
std::weak_ptr
登录后复制
来打破潜在的循环引用。

我个人觉得,很多人一开始会滥用

shared_ptr
登录后复制
,因为它听起来“更安全”,似乎什么都能管。但实际上,它带来了额外的复杂性和开销。所以,我的建议是:从
unique_ptr
登录后复制
开始考虑,只有当
unique_ptr
登录后复制
无法满足你的所有权需求时,才转向
shared_ptr
登录后复制

将原始指针与智能指针混合使用会带来哪些风险?

这简直是C++内存管理中的“雷区”,一不小心就会踩爆。混合使用原始指针和智能指针,尤其是当它们指向同一个动态分配的对象时,会引入一系列难以调试的严重问题。

BibiGPT-哔哔终结者
BibiGPT-哔哔终结者

B站视频总结器-一键总结 音视频内容

BibiGPT-哔哔终结者 28
查看详情 BibiGPT-哔哔终结者
  1. 双重释放(Double Free):这是最常见的风险。想象一下,你用

    new
    登录后复制
    分配了一个对象,然后用一个
    unique_ptr
    登录后复制
    管理它。接着,你又把这个对象的原始指针传给了一个函数,或者存入了一个容器,并且在某个地方对这个原始指针调用了
    delete
    登录后复制
    。当
    unique_ptr
    登录后复制
    离开作用域时,它会再次尝试
    delete
    登录后复制
    同一个内存地址。这会导致未定义行为,通常表现为程序崩溃。

    MyObject* raw_ptr = new MyObject();
    std::unique_ptr<MyObject> smart_ptr(raw_ptr); // smart_ptr 现在管理 raw_ptr
    
    // 某个地方,不小心又 delete 了
    delete raw_ptr; // 第一次释放
    // smart_ptr 离开作用域时会再次 delete,导致双重释放!
    登录后复制
  2. 悬空指针(Dangling Pointer):当智能指针管理的对象被释放后,如果还有原始指针指向这块内存,那么这些原始指针就变成了悬空指针。对悬空指针的任何解引用操作都是未定义行为,可能导致数据损坏或崩溃。

    std::unique_ptr<MyObject> smart_ptr = std::make_unique<MyObject>();
    MyObject* raw_ptr = smart_ptr.get(); // 获取原始指针
    
    smart_ptr.reset(); // 对象被释放了,raw_ptr 成了悬空指针
    
    raw_ptr->doSomething(); // 糟糕!访问已释放的内存
    登录后复制
  3. 所有权语义混乱:智能指针的核心价值在于明确所有权。

    unique_ptr
    登录后复制
    是独占,
    shared_ptr
    登录后复制
    是共享。一旦引入原始指针,这种清晰的所有权语义就被打破了。谁负责释放内存?谁是最终的拥有者?代码变得模糊不清,维护者需要花费大量精力去推断,极易出错。

  4. 异常安全问题:在异常发生时,智能指针能够保证资源的正确释放。但如果你的代码逻辑依赖于手动管理原始指针,一旦异常抛出,那些本应被

    delete
    登录后复制
    的原始指针可能就永远不会被释放,导致内存泄漏。

我的建议是:

  • 一旦对象被智能指针管理,尽量只通过智能指针来访问它。 如果实在需要传递原始指针(比如给一些遗留C API),请确保那个API不会尝试
    delete
    登录后复制
    这个指针,并且它的生命周期不会超过智能指针所管理对象的生命周期。
  • 不要从原始指针构造多个
    shared_ptr
    登录后复制
    比如
    std::shared_ptr<T> p1(new T); std::shared_ptr<T> p2(p1.get());
    登录后复制
    这会创建两个独立的
    shared_ptr
    登录后复制
    控制块,导致对象被双重释放。正确的做法是
    std::shared_ptr<T> p2 = p1;
    登录后复制
  • 坚持“智能指针优先”的原则。 除非有非常明确的理由,否则不要在容器中存储原始指针,也不要轻易地将智能指针管理的原始指针暴露出去。

如何为
std::unique_ptr
登录后复制
std::shared_ptr
登录后复制
定制删除器以处理特殊资源?

智能指针的强大之处不仅在于管理堆内存,还在于它可以通过定制删除器(Deleter)来管理几乎任何需要“清理”的资源,比如文件句柄、网络套接字、互斥锁等等。这让智能指针成为了一个通用的RAII工具

std::unique_ptr
登录后复制
的定制删除器:

unique_ptr
登录后复制
的删除器是其模板参数的一部分。这意味着如果你使用不同的删除器,那么它们的类型也是不同的。删除器可以是一个函数对象(lambda、仿函数)或者一个函数指针。

#include <memory>
#include <cstdio> // For FILE* and fclose
#include <iostream>
#include <vector>

// 1. 使用函数对象(Lambda表达式)作为删除器
auto file_closer = [](FILE* f) {
    if (f) {
        std::cout << "Closing file with lambda deleter." << std::endl;
        fclose(f);
    }
};
using FilePtr = std::unique_ptr<FILE, decltype(file_closer)>;

// 2. 使用结构体(仿函数)作为删除器
struct SocketCloser {
    void operator()(int* sock_fd) const { // 注意这里,通常传递原始指针类型
        if (sock_fd && *sock_fd != -1) {
            std::cout << "Closing socket with functor deleter: " << *sock_fd << std::endl;
            // 假设这是一个真实的套接字关闭函数
            // close(*sock_fd);
            delete sock_fd; // 释放原始指针本身
        }
    }
};
using SocketPtr = std::unique_ptr<int, SocketCloser>; // 假设 int 是文件描述符

void demo_unique_ptr_custom_deleter() {
    // 示例1: 管理文件句柄
    FILE* f = fopen("test.txt", "w");
    if (f) {
        FilePtr managed_file(f, file_closer);
        fprintf(f, "Hello from unique_ptr!\n");
        // managed_file 离开作用域时,file_closer 会被调用
    } else {
        std::cerr << "Failed to open file." << std::endl;
    }

    // 示例2: 管理一个假想的套接字描述符
    int* sock_fd = new int(123); // 假设这是从某个 API 获取的
    SocketPtr managed_socket(sock_fd, SocketCloser{});
    // managed_socket 离开作用域时,SocketCloser() 会被调用
}
登录后复制

可以看到,

unique_ptr
登录后复制
的删除器类型是其类型签名的一部分,这在模板编程时可能需要注意。

std::shared_ptr
登录后复制
的定制删除器:

shared_ptr
登录后复制
的定制删除器是通过其构造函数传入的,它不需要作为模板参数。这意味着所有使用相同类型对象的
shared_ptr
登录后复制
,即使有不同的删除器,它们的类型也是相同的。

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

// 1. 使用函数指针作为删除器
void custom_array_deleter(int* p) {
    std::cout << "Custom array deleter called. Deleting int array." << std::endl;
    delete[] p;
}

// 2. 使用 Lambda 表达式作为删除器
void demo_shared_ptr_custom_deleter() {
    // 示例1: 管理C风格动态数组
    std::shared_ptr<int> arr_ptr(new int[10], custom_array_deleter);
    arr_ptr.get()[0] = 100;
    std::cout << "Array element: " << arr_ptr.get()[0] << std::endl;
    // arr_ptr 离开作用域时,custom_array_deleter 会被调用

    // 示例2: 管理一个通过 C API 分配的内存
    // 假设有一个 C 函数 `void* allocate_buffer(size_t size)`
    // 和一个 `void free_buffer(void* ptr)`
    auto c_buffer_deleter = [](void* p) {
        std::cout << "Custom C buffer deleter called." << std::endl;
        // free_buffer(p); // 假设调用 C API 的释放函数
        std::free(p); // 这里用 std::free 模拟
    };

    void* raw_buffer = std::malloc(128); // 模拟 C API 分配
    std::shared_ptr<void> managed_buffer(raw_buffer, c_buffer_deleter);
    // managed_buffer 离开作用域时,c_buffer_deleter 会被调用
}
登录后复制

什么时候需要定制删除器?

  • 管理非堆内存资源:比如文件句柄(
    FILE*
    登录后复制
    ),数据库连接,网络套接字,
    malloc
    登录后复制
    分配的内存(需要
    free
    登录后复制
    而不是
    delete
    登录后复制
    )。
  • C风格数组
    new T[N]
    登录后复制
    分配的内存需要用
    delete[]
    登录后复制
    释放,而
    std::unique_ptr<T>
    登录后复制
    默认只调用
    delete T
    登录后复制
    。所以,对于
    std::unique_ptr<T[]>
    登录后复制
    ,它会自动使用
    delete[]
    登录后复制
    ,但如果你写的是
    std::unique_ptr<T>
    登录后复制
    去管理
    new T[N]
    登录后复制
    ,就需要定制删除器了。
    std::shared_ptr
    登录后复制
    则总是需要定制删除器来处理C风格数组。
  • 资源池管理:如果你从一个资源池中获取对象,释放时需要将其归还到池中,而不是真正销毁。定制删除器可以实现这种“回收”逻辑。

定制删除器是一个非常强大的特性,它让智能指针的应用场景远超简单的内存管理。它真正体现了RAII的精髓,将资源的生命周期管理抽象化,让你的代码更干净、更安全。

以上就是C++如何使用智能指针与容器结合管理内存的详细内容,更多请关注php中文网其它相关文章!

最佳 Windows 性能的顶级免费优化软件
最佳 Windows 性能的顶级免费优化软件

每个人都需要一台速度更快、更稳定的 PC。随着时间的推移,垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是,许多工具可以让 Windows 保持平稳运行。

下载
来源:php中文网
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系admin@php.cn
最新问题
开源免费商场系统广告
热门教程
更多>
最新下载
更多>
网站特效
网站源码
网站素材
前端模板
关于我们 免责申明 举报中心 意见反馈 讲师合作 广告合作 最新更新 English
php中文网:公益在线php培训,帮助PHP学习者快速成长!
关注服务号 技术交流群
PHP中文网订阅号
每天精选资源文章推送
PHP中文网APP
随时随地碎片化学习

Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号