自定义删除器在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 是
