自定义删除器在std::shared_ptr中的作用是让用户完全掌控资源销毁方式,解决非new/delete资源管理问题。1. 它允许传入函数、lambda或函数对象作为删除逻辑,确保如malloc内存、文件句柄等资源能正确释放;2. 避免new/delete不匹配导致的未定义行为;3. 支持raii机制管理c api资源,防止资源泄漏;4. 适配跨模块或数组等特殊释放需求。其核心价值在于使shared_ptr从内存管理工具升级为通用资源管理器。

自定义删除器在
std::shared_ptr中,本质上是让你能完全掌控
shared_ptr所管理对象的销毁方式,不仅仅局限于默认的
delete操作。这对于管理那些不是通过
new在堆上分配的资源,比如文件句柄、网络套接字、C 风格的
malloc内存,甚至是某个库内部的特殊资源,都显得尤为关键。它赋予了
shared_ptr更大的灵活性和通用性,让智能指针的“智能”真正延伸到各种资源类型上。

解决方案
std::shared_ptr允许你在构造时传入一个额外的参数,这个参数就是一个“删除器”(deleter)。这个删除器可以是一个普通的函数、一个 Lambda 表达式,或者一个函数对象(functor)。当
shared_ptr的引用计数归零时,它会调用这个自定义的删除器来释放资源,而不是简单地执行
delete。
一个非常典型的场景是管理 C 风格的内存分配,比如
malloc出来的内存。如果直接用
new对应的
delete去释放
malloc的内存,那肯定会出问题。这时候,自定义删除器就派上用场了:
立即学习“C++免费学习笔记(深入)”;

#include <iostream>
#include <memory>
#include <cstdio> // For fopen, fclose
// 示例1: 使用lambda作为删除器,管理malloc分配的内存
void example_malloc_deleter() {
std::cout << "--- 示例1: malloc内存管理 ---" << std::endl;
// 分配10个int的内存
int* data = (int*)std::malloc(sizeof(int) * 10);
if (!data) {
std::cerr << "malloc failed!" << std::endl;
return;
}
// 使用shared_ptr管理,并提供一个lambda作为删除器
// 当shared_ptr销毁时,这个lambda会被调用,执行free(data)
std::shared_ptr<int> sp_data(data, [](int* p) {
std::cout << "Lambda deleter: Freeing malloc'd memory at " << p << std::endl;
std::free(p);
});
// 可以在这里使用sp_data...
sp_data.get()[0] = 100;
std::cout << "Data[0]: " << sp_data.get()[0] << std::endl;
// sp_data离开作用域时,lambda删除器会被调用
std::cout << "sp_data about to go out of scope." << std::endl;
}
// 示例2: 使用函数对象(Functor)作为删除器,管理文件句柄
struct FileCloser {
void operator()(FILE* fp) {
if (fp) {
std::cout << "Functor deleter: Closing file handle " << fp << std::endl;
std::fclose(fp);
}
}
};
void example_file_deleter() {
std::cout << "\n--- 示例2: 文件句柄管理 ---" << std::endl;
// 尝试打开一个文件
FILE* file_ptr = std::fopen("test.txt", "w");
if (!file_ptr) {
std::cerr << "Failed to open test.txt!" << std::endl;
return;
}
// 使用shared_ptr管理文件句柄,并提供FileCloser作为删除器
std::shared_ptr<FILE> sp_file(file_ptr, FileCloser());
// 写入一些内容
std::fprintf(sp_file.get(), "Hello from shared_ptr!\n");
std::cout << "Wrote to test.txt." << std::endl;
// sp_file离开作用域时,FileCloser::operator()会被调用
std::cout << "sp_file about to go out of scope." << std::endl;
}
// 示例3: 使用普通函数作为删除器
void custom_array_deleter(int* arr) {
std::cout << "Function deleter: Deleting int array at " << arr << std::endl;
delete[] arr; // 注意这里是delete[],因为是new int[]分配的
}
void example_array_deleter() {
std::cout << "\n--- 示例3: 数组内存管理 ---" << std::endl;
// new int[10]分配的数组
int* arr = new int[10];
// 使用shared_ptr管理,并提供custom_array_deleter函数作为删除器
std::shared_ptr<int> sp_array(arr, custom_array_deleter);
sp_array.get()[0] = 200;
std::cout << "Array[0]: " << sp_array.get()[0] << std::endl;
// sp_array离开作用域时,custom_array_deleter会被调用
std::cout << "sp_array about to go out of scope." << std::endl;
}
int main() {
example_malloc_deleter();
example_file_deleter();
example_array_deleter();
std::cout << "\nAll examples finished." << std::endl;
return 0;
}可以看到,无论是 Lambda、函数对象还是普通函数,核心思想都是一样的:提供一个可调用对象,当
shared_ptr不再拥有资源时,它就会执行这个可调用对象来完成清理工作。选择哪种方式,通常取决于你的需求:Lambda 最简洁,适合一次性、内联的删除逻辑;函数对象适合需要维护状态或者更复杂、可复用的删除逻辑;普通函数则适合那些全局性的、无状态的清理函数。
值得一提的是,自定义删除器会作为
shared_ptr的一部分被存储起来,这意味着
shared_ptr的大小可能会比不带删除器时稍大一些,因为需要存储删除器的类型信息和可能的捕获状态。但这通常不是性能瓶颈,其带来的灵活性远超这点开销。

为什么我们需要自定义删除器?它解决了哪些常见问题?
说实话,一开始我接触自定义删除器的时候,也觉得有点绕,不就是个
delete吗?但后来才发现它能解决多少实际问题,简直是
shared_ptr从“智能指针”升级到“资源管理器”的关键一步。
最根本的原因是,C++ 世界里,资源的获取和释放方式是多种多样的,远不止
new和
delete这一对。想象一下,你可能从 C 库里
malloc了一块内存,那对应的是
free;你可能打开了一个文件句柄
FILE*,那对应的是
fclose;你可能获取了一个互斥锁
HANDLE,那对应的是
CloseHandle;甚至是你从某个工厂函数拿到一个对象,但这个对象需要通过一个特定的
release()方法来销毁。如果
shared_ptr只能无脑地调用
delete,那它就无法管理这些非
new/delete模式的资源,而这些资源在实际项目中比比皆是。
具体来说,自定义删除器解决了几个非常常见且棘手的问题:
-
new
与delete
的不匹配:这是最直接的。比如你用了malloc
分配内存,就不能用delete
释放,必须用free
。没有自定义删除器,shared_ptr
遇到malloc
出来的指针就会束手无策,或者说,强行使用会导致未定义行为甚至崩溃。 -
管理 C API 返回的资源:很多 C 语言库(比如文件操作、图形库、网络库)返回的都是裸指针,这些指针需要通过特定的 C 函数来释放。例如
fopen
对应fclose
,socket
对应closesocket
。shared_ptr
加上自定义删除器,就能完美地将这些 C 风格的资源管理封装进 C++ 的 RAII 机制中,大大简化了资源生命周期的管理,避免了手动释放的遗漏。 -
避免资源泄漏:这是 RAII(Resource Acquisition Is Initialization)的核心思想。没有自定义删除器,你可能不得不手动调用
fclose(fp)
或者free(ptr)
。一旦代码路径复杂,比如有异常抛出,或者有多个返回点,就很容易忘记释放资源,导致泄漏。shared_ptr
配合自定义删除器,确保了无论程序如何退出当前作用域,资源都能被正确、及时地释放。 - 处理跨模块或跨语言边界的资源:在一些复杂的系统中,你可能从一个动态链接库(DLL/SO)或者其他语言(通过 FFI)获取资源。这些资源可能需要通过特定于该模块或语言的函数来释放。自定义删除器提供了这种桥接能力。
-
数组的正确释放:
new T[N]
分配的数组需要用delete[]
来释放,而不是delete
。虽然shared_ptr<T[]>
可以在 C++17 后直接支持数组,但在此之前,或者当你需要更精细控制时,自定义删除器是确保delete[]
被调用的方式。
在我看来,自定义删除器是
shared_ptr成为一个真正通用的“智能资源管理器”的基石。它让
shared_ptr不再只是一个内存管理工具,而是一个能管理任何“拥有生命周期”的资源的利器。
自定义删除器的实现方式有哪些?代码示例详解
自定义删除器的实现方式主要有三种:Lambda 表达式、函数对象(Functor)和普通函数。每种方式都有其适用场景和优缺点。理解它们,就能在实际开发中灵活选择。
1. Lambda 表达式
这是现代 C++ 中最常用、最简洁的方式,尤其适合那些删除逻辑相对简单,且只在特定
shared_ptr实例中使用的场景。Lambda 可以捕获上下文变量,这在某些需要额外信息的删除操作中非常有用。
#include <iostream>
#include <memory>
#include <vector>
void demo_lambda_deleter() {
std::cout << "\n--- Lambda 表达式作为删除器 ---" << std::endl;
// 假设我们有一个从某个库获取的原始指针,需要特殊清理
// 这里用简单的new模拟,但想象它来自其他地方
std::vector<int>* vec = new std::vector<int>{1, 2, 3};
// 使用shared_ptr管理vec,并提供一个lambda删除器
// lambda捕获了vec,并在销毁时delete它
std::shared_ptr<std::vector<int>> sp_vec(vec, [](std::vector<int>* p) {
std::cout << "Lambda deleter: Deleting vector at " << p << std::endl;
delete p; // 确保是delete,而不是delete[]
});
std::cout << "Vector size: " << sp_vec->size() << std::endl;
// lambda也可以捕获外部变量
std::string resource_name = "My_Special_Resource";
int* raw_ptr = new int(42);
std::shared_ptr<int> sp_raw_ptr(raw_ptr, [name = resource_name](int* p) {
std::cout << "Lambda deleter for " << name << ": Deleting int at " << p << std::endl;
delete p;
});
std::cout << "sp_raw_ptr value: " << *sp_raw_ptr << std::endl;
std::cout << "Shared pointers about to go out of scope." << std::endl;
}优点:简洁、内联、可以直接捕获上下文变量。 缺点:如果删除逻辑复杂且需要复用,可能会导致代码冗余。
2. 函数对象(Functor)
函数对象是一个重载了
operator()的类实例。它非常适合需要维护状态,或者删除逻辑比较复杂且需要在多个地方复用的场景。因为函数对象是一个类,它可以拥有成员变量来存储状态。
#include <iostream>
#include <memory>
#include <string>
// 定义一个函数对象类
class LoggerDeleter {
private:
std::string log_prefix;
int counter;
public:
LoggerDeleter(const std::string& prefix) : log_prefix(prefix), counter(0) {}
// 重载operator(),这就是删除器被调用的地方
template<typename T>
void operator()(T* p) {
if (p) {
std::cout << log_prefix << " (Count: " << ++counter << "): Deleting object at " << p << std::endl;
delete p; // 假设是new出来的对象
}
}
};
void demo_functor_deleter() {
std::cout << "\n--- 函数对象作为删除器 ---" << std::endl;
// 创建两个LoggerDeleter实例,每个都有自己的状态
LoggerDeleter file_logger("FILE_CLEANUP");
LoggerDeleter db_logger("DB_CONN_CLOSE");
// 使用第一个LoggerDeleter实例
std::shared_ptr<int> sp1(new int(10), file_logger);
std::shared_ptr<double> sp2(new double(20.5), file_logger); // 共享同一个deleter实例
// 使用第二个LoggerDeleter实例
std::shared_ptr<std::string> sp3(new std::string("Hello"), db_logger);
std::cout << "Pointers created, about to go out of scope." << std::endl;
// 当sp1, sp2, sp3销毁时,各自的deleter会被调用,且可以看到counter的变化
}优点:可以维护状态,删除逻辑可复用,适用于复杂或有状态的清理操作。 缺点:相比 Lambda 稍显繁琐,需要定义额外的类。
3. 普通函数
如果删除逻辑非常简单,不需要捕获任何上下文,也没有状态,并且是全局通用的,那么一个普通的 C++ 函数也可以作为删除器。
#include <iostream>
#include <memory>
// 普通函数作为删除器
void simple_int_deleter(int* p) {
std::cout << "Normal function deleter: Deleting int at " << p << std::endl;
delete p;
}
void demo_function_deleter() {
std::cout << "\n--- 普通函数作为删除器 ---" << std::endl;
// 使用simple_int_deleter作为删除器
std::shared_ptr<int> sp_val(new int(99), simple_int_deleter);
std::cout << "Value: " << *sp_val << std::endl;
std::cout << "Shared pointer about to go out of scope." << std::endl;
}优点:最简单直接,如果删除逻辑是无状态且通用的。 缺点:无法捕获上下文,无法维护状态。
选择哪种方式,通常取决于删除逻辑的复杂性、是否需要状态以及复用程度。对于大多数情况,Lambda 表达式因其简洁性而成为首选。当需要更复杂的逻辑或状态管理时,函数对象则更有优势。
除了自定义删除器,shared_ptr还有哪些高级用法值得关注?
shared_ptr的强大之处远不止自定义删除器。它构建了一个相当完善的智能指针生态,解决了 C++ 中资源管理和对象生命周期控制的诸多痛点。除了我们刚才详细讨论的自定义删除器,还有几个高级用法,我觉得在日常开发中特别值得我们去深入了解和应用。
1. std::make_shared
:更安全、更高效的构造方式
你可能会习惯用
std::shared_ptr<T> p(new T());这样的方式来构造
shared_ptr。但说实话,这并不是最优解。
std::make_shared<T>()才是推荐的做法。
它的优势在于:
-
效率提升:
make_shared
通常只进行一次内存分配,同时为对象本身和shared_ptr
内部的控制块(包含引用计数等信息)分配内存。而new T()
之后再shared_ptr<T>(...)
,则需要两次独立的内存分配。这在性能敏感的场景下,尤其对于大量小对象的创建,差异会很明显。 -
异常安全:在
shared_ptr<T> p(new T(), func());
这种形式中,如果func()
抛出异常,而new T()
已经成功,那么new T()
分配的内存就可能泄漏,因为shared_ptr
还没来得及接管它。make_shared
则避免了这种中间状态,保证了更强的异常安全性。
// 推荐 auto sp1 = std::make_shared<MyObject>(arg1, arg2); // 不推荐(可能两次分配,异常不安全) // MyObject* raw_ptr = new MyObject(arg1, arg2); // 第一次分配 // std::shared_ptr<MyObject> sp2(raw_ptr); // 第二次分配(控制块)
2. std::weak_ptr
:解决循环引用问题的利器
shared_ptr最大的“坑”之一就是循环引用。如果对象 A 持有对象 B 的
shared_ptr,同时对象 B 也持有对象 A 的
shared_ptr,那么它们的引用计数永远不会归零,导致内存泄漏。
std::weak_ptr就是为了解决这个问题而生的。它是一种“弱引用”智能指针,它不增加所指向对象的引用计数。它更像是一个观察者,可以检查它所指向的对象是否仍然存在。
#include <iostream>
#include <memory>
class B; // 前向声明
class A {
public:
std::shared_ptr<B> b_ptr;
A() { std::cout << "A constructed" << std::endl; }
~A() { std::cout << "A destroyed" << std::endl; }
};
class B {
public:
std::weak_ptr<A> a_ptr; // 使用 weak_ptr
B() { std::cout << "B constructed" << std::endl; }
~B() { std::cout << "B destroyed" << std::endl; }
void observe_a() {
if (auto sharedA = a_ptr.lock()) { // 尝试将 weak_ptr 提升为 shared_ptr
std::cout << "A is still alive!" << std::endl;
} else {
std::cout << "A is gone!" << std::endl;
}
}
};
void demo_weak_ptr() {
std::cout << "\n--- weak_ptr 解决循环引用 ---" << std::endl;
std::shared_ptr<A> sp_a = std::make_shared<A>();
std::shared_ptr<B> sp_b = std::make_shared<B>();
sp_a->b_ptr = sp_b;
sp_b->a_ptr = sp_a; // 此时不会形成循环引用,因为 a_ptr 是










