一文带你掌握C++中智能指针如何自定义删除器_C/C++

为什么需要自定义删除器

智能指针的核心作用是“自动管理资源”，其底层逻辑是：当智能指针对象生命周期结束时，自动调用析构函数释放其托管的资源。但默认的析构逻辑是调用delete，这在很多场景下并不适用。

典型适用场景

c语言库资源：比如hiredis库的rediscontext，创建用redisconnect()，释放必须用redisfree()，而非delete；又如文件操作，fopen()创建的file*，必须用fclose()释放。
非new分配的内存：用malloc/calloc分配的内存，需要用free()释放，无法用delete。
自定义释放逻辑：释放资源时需要额外操作，比如关闭socket前发送终止信号、解锁互斥锁、注销资源等。
避免资源泄漏：如果不指定自定义删除器，智能指针会用delete释放非new创建的资源，导致未定义行为（崩溃、内存泄漏）。

反面案例

以redis连接为例，若直接使用默认智能指针，会导致严重问题：

#include <hiredis/hiredis.h>
#include <memory>

// 错误写法：未指定自定义删除器
std::unique_ptr<rediscontext> ctx(redisconnect("127.0.0.1", 6379));

// 析构时会调用delete释放rediscontext，而非redisfree()
// 后果：内存泄漏、连接未关闭、程序可能崩溃

这就是自定义删除器的核心价值：告诉智能指针“如何正确释放资源”。

自定义删除器的两种核心实现方式

自定义删除器的本质是“给智能指针传递一个可调用对象”，让智能指针在析构时调用该对象，完成资源释放。常用的实现方式有两种：函数指针型和仿函数型，二者各有优劣，适用于不同场景。

方式一：函数指针型

将释放资源的函数（如redisfree）作为函数指针，传递给智能指针，作为删除器。

实现步骤

定义智能指针类型时，指定“托管类型”和“函数指针类型”（用decltype获取函数指针类型）。
创建智能指针对象时，传入“资源指针”和“删除器函数指针”。
注意：返回空智能指针时，必须显式传入删除器函数指针，否则会出现未定义行为。

实战代码（redis连接池片段）

#include <hiredis/hiredis.h>
#include <memory>

// 1. 定义带函数指针删除器的智能指针
using redisptr = std::unique_ptr<rediscontext, decltype(&redisfree)>;

// 2. 创建智能指针（必须传入删除器）
rediscontext* raw_ctx = redisconnect("127.0.0.1", 6379);
redisptr ctx(raw_ctx, redisfree); // 正确：传入资源指针+删除器

// 3. 返回空智能指针（必须显式传入删除器）
redisptr getemptyconn() {
    // 错误：return nullptr; （未传入删除器，函数指针为野指针，析构崩溃）
    return redisptr{nullptr, redisfree}; // 正确
}

优缺点分析

优点：实现简单，无需额外定义类/结构体，直接复用现有释放函数。

缺点：

智能指针会额外存储函数指针，增加内存开销；
不能直接return nullptr；
函数指针无法捕获额外上下文（如需自定义释放逻辑，不够灵活）。

更推荐的写法：方式二：仿函数型

定义一个结构体（或类），重载()运算符（仿函数），将释放资源的逻辑写在运算符重载函数中。这种方式是企业级开发的首选，无额外内存开销，且灵活安全。

实现步骤

定义仿函数结构体，重载()运算符，参数为“托管资源的指针”，函数体内实现释放逻辑。
定义智能指针类型时，指定“托管类型”和“仿函数类型”。
创建智能指针对象时，只需传入资源指针，无需显式传入删除器（仿函数作为类型一部分，自动绑定）。
返回空智能指针时，可直接return nullptr，无需额外操作。

实战代码（redis连接池完整片段）

#include <hiredis/hiredis.h>
#include <memory>
#include <queue>
#include <mutex>

// 1. 定义仿函数删除器（核心：重载()运算符）
struct redisdeleter {
    // 释放逻辑：判断指针非空，调用redisfree释放
    void operator()(rediscontext* ptr) const {
        if (ptr) {
            redisfree(ptr);
        }
    }
};

// 2. 定义带仿函数删除器的智能指针（无额外内存开销）
using redisptr = std::unique_ptr<rediscontext, redisdeleter>;

// 3. redis连接池类
class redisconnectpool {
private:
    std::queue<redisptr> connections_; // 队列存智能指针，自动释放
    std::mutex mutex_;
public:
    // 获取连接：直接return nullptr，无需传删除器
    redisptr getconnection() {
        std::lock_guard<std::mutex> lock(mutex_);
        if (connections_.empty()) {
            return nullptr; // 正确：仿函数删除器自动绑定，无未定义行为
        }
        auto conn = std::move(connections_.front());
        connections_.pop();
        return conn;
    }

    // 归还连接：智能指针自动管理，无需手动释放
    void returnconnection(redisptr conn) {
        std::lock_guard<std::mutex> lock(mutex_);
        connections_.push(std::move(conn));
    }
};

优缺点分析

优点：

无额外内存开销（仿函数作为类型一部分，不占额外空间）；
可直接return nullptr，不易踩坑；
仿函数可捕获上下文（比如添加日志、额外释放操作），灵活度高；
类型安全，不易混用。

缺点：需要额外定义一个仿函数结构体（代码量略有增加，但可复用）。

避坑指南

结合笔者在redis连接池开发中的踩坑经验，总结4个高频坑点，避开这些就能写出安全的代码。

坑点1：仿函数重载()的返回值错误

自定义删除器的仿函数，()运算符必须是无返回值（void），因为智能指针调用删除器时，不会处理返回值。若返回bool等类型，会导致编译警告，甚至未定义行为。

// 错误写法：返回bool
struct redisdeleter {
    bool operator()(rediscontext* ptr) { // ❌ 错误，返回值无用且有风险
        if (ptr) redisfree(ptr);
    }
};

// 正确写法：无返回值
struct redisdeleter {
    void operator()(rediscontext* ptr) const { // ✅ 正确
        if (ptr) redisfree(ptr);
    }
};

坑点2：函数指针型删除器直接return nullptr

函数指针型删除器的智能指针，空指针必须显式传入删除器函数指针。因为智能指针需要同时初始化“资源指针”和“删除器函数指针”，只传nullptr会导致删除器为野指针，析构时崩溃。

// 错误（函数指针型）
redisptr getemptyconn() {
    return nullptr; // ❌ 未传入删除器，野指针崩溃
}

// 正确（函数指针型）
redisptr getemptyconn() {
    return redisptr{nullptr, redisfree}; // ✅ 显式传入删除器
}

坑点3：混用不同删除器的智能指针

std::unique_ptr的删除器是“类型的一部分”——不同删除器的智能指针，是不同的类型，不能互相赋值、传递。

// 两种不同删除器的智能指针（不同类型）
using ptr1 = std::unique_ptr<rediscontext, decltype(&redisfree)>;
using ptr2 = std::unique_ptr<rediscontext, redisdeleter>;

ptr1 ptr1(redisconnect("127.0.0.1", 6379), redisfree);
ptr2 ptr2 = ptr1; // ❌ 错误：类型不匹配，无法赋值

坑点4：手动调用reset()后重复释放

智能指针的reset()方法会释放当前托管的资源，若之后再调用pop()（队列中）或让智能指针生命周期结束，会导致双重释放吗？答案是：不会。

原因：reset()释放的是“托管的资源”，智能指针本身还活着；pop()会销毁智能指针，此时智能指针已为空，析构时不会再释放资源。但注意：手动reset()是多余的，智能指针会自动释放。

std::queue<redisptr> q;
q.emplace(redisconnect("127.0.0.1", 6379));

// 多余但安全的写法
q.front().reset(); // 释放资源，智能指针变为空
q.pop(); // 销毁空智能指针，无操作

// 推荐写法（无需reset）
q.pop(); // 直接销毁智能指针，自动释放资源

两种删除器对比与选型建议

对比维度	函数指针型	仿函数型
内存开销	有（存储函数指针）	无（作为类型一部分）
使用复杂度	简单（直接复用释放函数）	略复杂（需定义仿函数）
返回空指针	需显式传入删除器	可直接return nullptr
灵活度	低（无法捕获上下文）	高（可添加自定义逻辑）
工程推荐度	低（仅适用于简单场景）	高（工业级标准写法）