第30章内存泄漏常见模式

课程目录第30章内存泄漏常见模式

30. 内存泄漏常见模式：回调函数中的this指针

回调函数，这玩意儿在C++里太常见了。事件驱动、异步操作、消息分发……到处都有它的身影。但你知道吗？回调函数也是内存泄漏的温床，尤其是当你把this指针直接丢进去的时候。

我个人习惯在写回调逻辑时，会多问自己一句：这个对象的生命周期，能撑到回调执行完吗？如果答案不确定，那八成要出问题。

问题出在哪？

先看一个典型的错误写法：

class Downloader {
public:
    void startDownload(const std::string& url) {
        // 发起异步下载，回调中直接使用 this
        async_download(url, [this](const Result& res) {
            this->onDownloadComplete(res);
        });
    }

    void onDownloadComplete(const Result& res) {
        // 处理下载结果
        data_ = res.data;
    }

private:
    std::string data_;
};

void someFunction() {
    auto* dl = new Downloader();
    dl->startDownload("https://example.com/file");
    // 忘记 delete dl，或者提前 delete 了
    // delete dl;  // 如果这里提前释放，回调执行时 this 就悬空了
}

这里有两个问题：

内存泄漏：dl是裸指针，没人负责delete它。
悬空指针：就算你记得delete，如果回调在对象销毁之后才执行，this指向的内存已经释放了——程序直接崩溃。

我在项目中遇到过类似的情况。当时是一个网络库的异步回调，对象在请求完成后被销毁，但回调因为线程调度延迟了几毫秒……嗯，那几毫秒让我排查了整整一个下午。

为什么this指针这么危险？

说白了，this就是一个裸指针。它不参与对象的生命周期管理。你把this捕获到lambda里，lambda不会延长对象的生命期。对象一旦被销毁，this就成了野指针。

你想想看，回调函数往往在未来的某个时间点执行。这个时间点可能是：

几毫秒后（定时器）
用户操作后（UI事件）
网络响应到达时（异步IO）

在这段时间里，对象可能已经被销毁了。回调执行时，this指向的内存可能已经被重新分配给其他对象了。这时候访问成员变量，轻则读到脏数据，重则直接段错误。

警告：永远不要假设回调会在对象销毁之前执行。异步操作的执行时机是不确定的，尤其是在多线程环境下。

解决方案：用shared_ptr管理生命周期

最直接的办法：用std::shared_ptr管理对象，然后在lambda里捕获shared_ptr而不是裸this。

class Downloader : public std::enable_shared_from_this<Downloader> {
public:
    void startDownload(const std::string& url) {
        // 捕获 shared_from_this() 而不是 this
        async_download(url, [self = shared_from_this()](const Result& res) {
            self->onDownloadComplete(res);
        });
    }

    void onDownloadComplete(const Result& res) {
        data_ = res.data;
    }

private:
    std::string data_;
};

void someFunction() {
    auto dl = std::make_shared<Downloader>();
    dl->startDownload("https://example.com/file");
    // dl 离开作用域，但回调中持有 shared_ptr，对象不会被销毁
}

关键点：

类继承自std::enable_shared_from_this<Downloader>
在lambda中通过shared_from_this()获取shared_ptr
lambda捕获这个shared_ptr，延长对象生命周期

这样，只要回调还没执行，对象就不会被销毁。回调执行完后，shared_ptr引用计数归零，对象自动释放。

提示：使用shared_from_this()的前提是对象必须由shared_ptr管理。如果对象是栈上分配的或者用unique_ptr管理，调用shared_from_this()会抛出std::bad_weak_ptr异常。

另一种方案：weak_ptr + 检查

有时候你不想延长对象的生命周期，而是希望在回调中检查对象是否还活着。这时候可以用std::weak_ptr。

class Downloader : public std::enable_shared_from_this<Downloader> {
public:
    void startDownload(const std::string& url) {
        std::weak_ptr<Downloader> weak_self = shared_from_this();
        async_download(url, [weak_self](const Result& res) {
            if (auto self = weak_self.lock()) {
                self->onDownloadComplete(res);
            } else {
                // 对象已经销毁，忽略回调
                std::cerr << "Downloader已销毁，忽略回调" << std::endl;
            }
        });
    }
    // ... 其余代码同上
};

这种方式的好处是：如果对象已经销毁，回调不会访问无效内存。坏处是：回调仍然会被执行（只是内部做了检查），如果回调有副作用（比如写日志、更新UI），你可能需要处理这些情况。

我个人更倾向于第一种方案（shared_ptr延长生命周期），因为它更简单、更安全。除非你有明确的理由不希望延长对象生命周期（比如对象占用了大量资源），否则就用shared_ptr。

避坑指南：我曾经踩过的坑

我曾经在一个项目中，用裸this捕获到lambda里，然后把这个lambda注册为定时器回调。定时器每100ms触发一次，而对象在某个条件下会被销毁。结果就是：对象销毁后，定时器仍然在触发，每次触发都访问野指针。程序崩溃得毫无规律，有时候几分钟，有时候几个小时。

排查过程极其痛苦。因为崩溃的堆栈指向的是回调函数内部，根本看不出是对象已经被销毁了。最后是通过AddressSanitizer（ASan）才定位到问题。

从那以后，我给自己定了个规矩：只要lambda的生命周期可能超过当前作用域，就绝对不用裸this。要么用shared_from_this()，要么用weak_ptr做检查。

知识结构图

总结一下

回调函数中的this指针问题，说白了就是生命周期不匹配。回调的执行时机和对象的销毁时机是独立的，用裸this就是在赌博。

解决方案其实就两条路：

延长对象生命周期：用shared_ptr + shared_from_this()，让对象活到回调执行完。
检查对象是否存活：用weak_ptr + lock()，在回调中做安全检查。

我个人推荐第一种，代码更简洁，心智负担更小。但如果你对性能有极致要求，或者对象占用了大量资源不想延长生命周期，那就用第二种。

嗯，记住一点：别偷懒。每次写回调的时候，多花10秒钟想想生命周期的问题，能省下你未来几个小时的调试时间。

    核心原则：回调中捕获的指针，必须能保证在回调执行时指向的对象仍然存在。做不到这一点，就用智能指针。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录

30. 内存泄漏常见模式：回调函数中的this指针

问题出在哪？

为什么this指针这么危险？

解决方案：用shared_ptr管理生命周期

另一种方案：weak_ptr + 检查

避坑指南：我曾经踩过的坑

知识结构图

总结一下