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

P粉602998670

发布时间：2025-09-04 12:50:02

223人浏览过

来源于php中文网

原创

在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之后，智能指针的引入简直是福音。

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

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

使用

std::unique_ptr

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

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

std::unique_ptr

是首选。它的开销非常小，因为它不涉及引用计数。它最适合用在

std::vector

、

std::list

或

std::deque

这种线性容器中，尤其是当你需要存储多态对象时。

#include 
#include 
#include 

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> objects;
objects.push_back(std::make_unique()); // 推荐使用 make_unique
objects.push_back(std::make_unique());

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

使用

std::shared_ptr

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

std::shared_ptr

是你的选择。它通过引用计数来管理对象的生命周期，当引用计数降为零时，对象才会被销毁。这在

std::map

或

std::set

这种需要共享对象引用的场景中特别有用，或者在构建复杂的图结构时。

#include 
#include 
#include 
#include 

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> shared_resources;

// 创建一个共享资源
auto r1 = std::make_shared("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 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

的场景：

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

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

std::shared_ptr

？

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

shared_ptr

是必要的，但也要警惕

std::weak_ptr

来打破潜在的循环引用。

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

shared_ptr

，因为它听起来“更安全”，似乎什么都能管。但实际上，它带来了额外的复杂性和开销。所以，我的建议是：从

unique_ptr

开始考虑，只有当

unique_ptr

无法满足你的所有权需求时，才转向

shared_ptr

。

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

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

Cutout.Pro抠图

AI批量抠图去背景

下载

双重释放（Double Free）：这是最常见的风险。想象一下，你用
```
new
```
分配了一个对象，然后用一个
```
unique_ptr
```
管理它。接着，你又把这个对象的原始指针传给了一个函数，或者存入了一个容器，并且在某个地方对这个原始指针调用了
```
delete
```
。当
```
unique_ptr
```
离开作用域时，它会再次尝试
```
delete
```
同一个内存地址。这会导致未定义行为，通常表现为程序崩溃。
```
MyObject* raw_ptr = new MyObject();
std::unique_ptr smart_ptr(raw_ptr); // smart_ptr 现在管理 raw_ptr

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

smart_ptr.reset(); // 对象被释放了，raw_ptr 成了悬空指针

raw_ptr->doSomething(); // 糟糕！访问已释放的内存
```
所有权语义混乱：智能指针的核心价值在于明确所有权。
```
unique_ptr
```
是独占，
```
shared_ptr
```
是共享。一旦引入原始指针，这种清晰的所有权语义就被打破了。谁负责释放内存？谁是最终的拥有者？代码变得模糊不清，维护者需要花费大量精力去推断，极易出错。
异常安全问题：在异常发生时，智能指针能够保证资源的正确释放。但如果你的代码逻辑依赖于手动管理原始指针，一旦异常抛出，那些本应被
```
delete
```
的原始指针可能就永远不会被释放，导致内存泄漏。

我的建议是：

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

如何为

std::unique_ptr

或

std::shared_ptr

定制删除器以处理特殊资源？

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

std::unique_ptr

的定制删除器：

unique_ptr

的删除器是其模板参数的一部分。这意味着如果你使用不同的删除器，那么它们的类型也是不同的。删除器可以是一个函数对象（lambda、仿函数）或者一个函数指针。

#include 
#include  // For FILE* and fclose
#include 
#include 

// 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;

// 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 是文件描述符

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 
#include 
#include 

// 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 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 managed_buffer(raw_buffer, c_buffer_deleter);
    // managed_buffer 离开作用域时，c_buffer_deleter 会被调用
}

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

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