自定义删除器在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的内存，那肯定会出问题。这时候，自定义删除器就派上用场了：
#include <iostream>
#include <memory>
#include <cstdio> // For fopen, fclose
// 示例1: 使用lambda作为删除器，管理malloc分配的内存
void example_malloc_deleter() {
std::cout sp_data(data, [](int* p) {
std::cout sp_file(file_ptr, FileCloser());
// 写入一些内容
std::fprintf(sp_file.get(), "Hello from shared_ptr!\n");
std::cout sp_array(arr, custom_array_deleter);
sp_array.get()[0] = 200;
std::cout <p>可以看到，无论是 Lambda、函数对象还是普通函数，核心思想都是一样的：提供一个可调用对象，当 </p>
<pre class="brush:php;toolbar:false;">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></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 * vec = new std::vector<int>{1, 2, 3};
// 使用shared_ptr管理vec，并提供一个lambda删除器
// lambda捕获了vec，并在销毁时delete它
std::shared_ptr<:vector>> sp_vec(vec, [](std::vector<int>* p) {
std::cout size() sp_raw_ptr(raw_ptr, [name = resource_name](int* p) {
std::cout <p><strong>优点</strong>：简洁、内联、可以直接捕获上下文变量。
<strong>缺点</strong>：如果删除逻辑复杂且需要复用，可能会导致代码冗余。</p>
<p><strong>2. 函数对象（Functor）</strong></p>
<p>函数对象是一个重载了 </p>
<pre class="brush:php;toolbar:false;">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 sp1(new int(10), file_logger);
std::shared_ptr<double> sp2(new double(20.5), file_logger); // 共享同一个deleter实例
// 使用第二个LoggerDeleter实例
std::shared_ptr<:string> sp3(new std::string("Hello"), db_logger);
std::cout <p><strong>优点</strong>：可以维护状态，删除逻辑可复用，适用于复杂或有状态的清理操作。
<strong>缺点</strong>：相比 Lambda 稍显繁琐，需要定义额外的类。</p>
<p><strong>3. 普通函数</strong></p>
<p>如果删除逻辑非常简单，不需要捕获任何上下文，也没有状态，并且是全局通用的，那么一个普通的 C++ 函数也可以作为删除器。</p>
<pre class="brush:cpp;toolbar:false;">#include <iostream>
#include <memory>
// 普通函数作为删除器
void simple_int_deleter(int* p) {
std::cout sp_val(new int(99), simple_int_deleter);
std::cout <p><strong>优点</strong>：最简单直接，如果删除逻辑是无状态且通用的。
<strong>缺点</strong>：无法捕获上下文，无法维护状态。</p>
<p>选择哪种方式，通常取决于删除逻辑的复杂性、是否需要状态以及复用程度。对于大多数情况，Lambda 表达式因其简洁性而成为首选。当需要更复杂的逻辑或状态管理时，函数对象则更有优势。</p>
<h3>除了自定义删除器，shared_ptr还有哪些高级用法值得关注？</h3>
<p></p>
<pre class="brush:php;toolbar:false;">shared_ptr 的强大之处远不止自定义删除器。它构建了一个相当完善的智能指针生态，解决了 C++ 中资源管理和对象生命周期控制的诸多痛点。除了我们刚才详细讨论的自定义删除器，还有几个高级用法，我觉得在日常开发中特别值得我们去深入了解和应用。1. std::make_shared
：更安全、更高效的构造方式
你可能会习惯用
std::shared_ptr<t> p(new T());</t>这样的方式来构造
shared_ptr。但说实话，这并不是最优解。
std::make_shared<t>()</t>才是推荐的做法。
它的优势在于：
-
效率提升：
make_shared
通常只进行一次内存分配，同时为对象本身和shared_ptr
内部的控制块（包含引用计数等信息）分配内存。而new T()
之后再shared_ptr<t>(...)</t>
，则需要两次独立的内存分配。这在性能敏感的场景下，尤其对于大量小对象的创建，差异会很明显。 -
异常安全：在
shared_ptr<t> p(new T(), func());</t>
这种形式中，如果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); // 第二次分配（控制块）</myobject></myobject>
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_ptr; // 使用 weak_ptr
B() { std::cout 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 是</b></b></a></b></memory></iostream>C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
