Qt deleteLater作用及源码分析

[1.deleteLater() 的作用](#1.deleteLater() 的作用)

[2.为什么要用它？直接 delete 不行吗？](#2.为什么要用它？直接 delete 不行吗？)

3.源码分析

[3.1.deleteLater() 的实现](#3.1.deleteLater() 的实现)

3.2.事件的投递

3.3.事件的处理

[4.核心作用：解决直接 delete 无法处理的安全问题](#4.核心作用：解决直接 delete 无法处理的安全问题)

5.关键特性（必记，避免踩坑）

6.典型必用场景

[7.与直接 delete 的核心区别](#7.与直接 delete 的核心区别)

8.注意事项

1.`deleteLater()` 的作用

根据 Qt 官方文档的描述：

简单概括：

延迟删除：对象不会立即被销毁，而是等到事件循环（event loop）再次回到执行状态时才会被删除。
事件循环未启动 ：如果在调用 exec() 之前调用了 deleteLater()，则对象会在事件循环启动时被删除。
主事件循环已停止 ：调用 deleteLater() 后对象将不会被删除（因为已经没有事件循环来处理延迟删除事件）。
无事件循环的线程：自 Qt 4.8 起，如果对象所属的线程没有运行事件循环，则对象会在线程结束时被销毁。
嵌套事件循环 ：打开模态对话框等操作会进入一个新的事件循环，但并不会导致已调度的删除立即执行；必须返回到最初调用 deleteLater() 的那个事件循环，删除才会发生。不过，如果一个对象在旧的嵌套事件循环中已被调度删除，当新的事件循环启动时，这些对象会被立即删除。

2.为什么要用它？直接 delete 不行吗？

不行！直接 delete 非常容易崩溃。典型危险场景：

对象正在执行自己的槽函数
正在发射信号
正在事件处理中
多线程环境下，你不知道对象是否正在被使用

直接 delete 会造成：

野指针
重复释放
程序崩溃

deleteLater() 巧妙地解决了这个问题：它将删除操作推迟到当前事件处理结束之后，事件循环下次获取事件之前。这样，所有待处理的事件都可以安全完成，对象才被真正销毁。

3.源码分析

3.1.`deleteLater()` 的实现

deleteLater() 是 QObject 的公有成员函数，其定义位于 qobject.cpp 中：

cpp 复制代码

void QObject::deleteLater()
{
    QCoreApplication::postEvent(this, new QDeferredDeleteEvent());
}

代码非常简洁：它通过 QCoreApplication::postEvent() 向对象自身发送一个 QDeferredDeleteEvent 事件。这个事件是 Qt 内部定义的，继承自 QEvent，其类型为 QEvent::DeferredDelete。

3.2.事件的投递

投递异步销毁事件 ：通过线程安全的QCoreApplication::postEvent()，向对象所属线程的事件队列，投递一个优先级为Qt::LowEventPriority的QDeferredDeleteEvent事件。

关键：postEvent是异步投递，仅把事件放入队列末尾，不会立刻执行，这是延迟销毁的核心。

3.3.事件的处理

当事件循环（QEventLoop）获得控制权并处理事件时，会通过 QCoreApplication::notify() 最终调用到 QObject::event() 函数。QObject::event() 中对 QEvent::DeferredDelete 的处理如下（简化自 Qt 5.15 源码）：

cpp 复制代码

bool QObject::event(QEvent *e)
{
    switch (e->type()) {
    // ...
    case QEvent::DeferredDelete:
        // 如果对象正处于"发送事件"的状态（比如正在处理另一个事件的槽函数中），
        // 我们不能立即删除，否则可能会破坏堆栈状态。此时需要再次投递一个 DeferredDelete 事件。
        if (d->isSender) {
            QCoreApplication::postEvent(this, new QEvent(QEvent::DeferredDelete));
            return true;
        }
        // 如果已经有一个待处理的 DeferredDelete 事件，则执行真正的删除。
        if (d->postedDeferredDelete) {
            d->postedDeferredDelete = false;
            delete this;      // 注意：这里直接 delete 对象本身！
        }
        return true;
    // ...
    }
    return false;
}

这段代码有几个要点：

d->isSender 是一个内部标志，指示对象是否正处于信号发送的过程中（即某个槽函数正在执行）。如果在信号发送过程中收到 DeferredDelete 事件，直接删除对象可能会导致正在执行的槽函数访问非法内存，所以 Qt 会再次投递一个相同的事件，延迟到更安全的时机。
d->postedDeferredDelete 标志用来防止重复删除。当第一次收到 DeferredDelete 事件时，该标志被设置，然后再次投递一个新的事件（注意此时事件类型是普通的 QEvent::DeferredDelete 而不是 QDeferredDeleteEvent？实际上 QDeferredDeleteEvent 会在构造时记录当前的循环层级等信息，但最终的删除逻辑仍是这个）。
事件处理函数内部会执行delete this，触发对象的析构函数：自动断开所有信号槽连接、从父对象的子列表中移除、递归销毁所有子对象、最终释放内存。

4.核心作用：解决直接 delete 无法处理的安全问题

Qt 的核心架构是基于事件循环与信号槽机制，直接delete在大量 Qt 特有场景下会触发致命问题，而deleteLater()就是为解决这些场景设计的：

1.解决「对象在自身事件 / 槽函数中销毁自己」的崩溃问题

这是最经典的使用场景。当对象正在执行自己的成员函数（槽函数、事件处理函数）时，直接delete this会导致：

函数后续代码访问已释放的成员变量，触发野指针访问；
Qt 框架后续对该对象的事件传播、信号槽收尾操作，访问已销毁的对象，程序直接崩溃。

deleteLater()会保证当前槽函数 / 事件处理流程完全执行完毕，回到事件循环后再销毁对象，全程对象有效，绝对安全。

2.解决「跨线程销毁 QObject 对象」的线程安全问题

Qt 的QObject有严格的线程亲和性 ：对象只能在它所属的线程（创建它的线程，或moveToThread后的线程）中销毁，在非所属线程直接delete会触发线程竞争、未定义行为，大概率崩溃。

deleteLater()是线程安全的（Qt4.4 及以上全版本支持）：

可在任意线程调用，销毁事件始终会被投递到对象所属线程的事件循环；
销毁操作始终在对象所属的线程执行，完全符合 Qt 的线程安全规则。

3.解决「信号槽链中的野指针问题」

一个信号可能连接多个槽函数，若其中一个槽函数中直接销毁了信号发送者，后续关联的槽函数再访问该发送者，就会触发野指针崩溃。

deleteLater()会等待当前信号触发的所有槽函数全部执行完毕，回到事件循环后再销毁对象，彻底规避该问题。

4.解决「父子对象销毁的时序问题」

Qt 的父子机制规定：父对象销毁时会自动递归销毁所有子对象。若直接delete父对象时，子对象还在处理事件、执行槽函数，会触发时序混乱导致的崩溃。

deleteLater()会保证销毁操作在事件循环的空闲期执行，父对象析构时，所有子对象的事件处理已全部完成，销毁时序完全安全。

5.关键特性（必记，避免踩坑）

异步延迟执行，当前执行流全程有效 调用deleteLater()后，对象在当前函数、槽函数、事件处理的剩余代码中完全有效，直到回到事件循环才会被销毁。
线程安全任意线程均可调用，销毁操作始终在对象所属线程的事件循环中执行，符合 Qt 线程安全规范。
多次调用完全无害 对同一个对象多次调用deleteLater()，只会执行一次销毁。第一次调用后会设置pendingDeletion标记，后续调用不会重复投递事件，不会出现重复释放。
完全兼容 QObject 的析构逻辑 最终销毁时执行的是标准delete，会完整触发析构函数，自动断开信号槽、销毁子对象，和直接delete的析构行为完全一致，仅执行时机不同。
强依赖事件循环 deleteLater()必须依赖对象所属线程的事件循环才能生效。若线程没有启动事件循环、或事件循环已退出，销毁事件不会被处理，对象永远不会被销毁，造成内存泄漏。
本地事件循环也可生效 对话框的QDialog::exec()、菜单的QMenu::exec()等本地事件循环，也会处理QDeferredDeleteEvent，调用deleteLater()依然会正常销毁对象。

6.典型必用场景

1.槽函数中销毁自身 / 信号发送者

cpp 复制代码

// 错误示例：直接delete，大概率崩溃
void MyWidget::onCloseBtnClicked()
{
    delete this; // 销毁后，Qt后续的事件传播、信号槽收尾会访问已释放内存
}

// 正确示例：deleteLater安全销毁
void MyWidget::onCloseBtnClicked()
{
    this->deleteLater(); // 等当前槽、所有关联槽、事件处理全部结束后再销毁
}

2.跨线程销毁工作对象

cpp 复制代码

// 正确的跨线程销毁示例
QThread* workThread = new QThread;
MyWorker* worker = new MyWorker;
worker->moveToThread(workThread);

// 线程结束后，安全销毁对象（必须用deleteLater）
connect(workThread, &QThread::finished, worker, &QObject::deleteLater);
connect(workThread, &QThread::finished, workThread, &QObject::deleteLater);

workThread->start();

// 错误示例：主线程直接delete，worker属于workThread线程，触发线程安全崩溃
// delete worker;

3.临时对象用完即毁（网络请求、弹窗等）

cpp 复制代码

// 临时网络请求，完成后自动销毁，无内存泄漏
QNetworkAccessManager* manager = new QNetworkAccessManager(this);
QNetworkReply* reply = manager->get(QNetworkRequest(QUrl("https://www.qt.io")));
// 请求完成后自动销毁reply
connect(reply, &QNetworkReply::finished, reply, &QObject::deleteLater);

4.避免父子对象销毁时序混乱

cpp 复制代码

// 父窗口销毁时，安全销毁所有子控件，避免子控件还在处理事件
void MainWindow::closeEvent(QCloseEvent *event)
{
    // 先销毁子模块，再销毁自身，时序完全安全
    m_childWidget->deleteLater();
    this->deleteLater();
    event->accept();
}

7.与直接 delete 的核心区别

对比维度	直接 delete	QObject::deleteLater()
执行时机	调用时立刻执行析构，释放内存	延迟到对象所属线程事件循环的下一个空闲时机执行
安全性	事件处理、槽函数、跨线程中调用极易触发野指针、崩溃、未定义行为	保证当前执行流完全结束后再销毁，彻底规避上述问题，线程安全
事件循环依赖	不依赖，任何场景都可执行	必须依赖事件循环，无事件循环时不生效
线程亲和性	必须在对象所属线程调用，否则线程不安全	可在任意线程调用，销毁始终在对象所属线程执行
多次调用	多次调用触发重复释放，程序崩溃	多次调用仅执行一次销毁，完全安全
适用场景	栈上对象、无 Qt 事件机制的普通对象、确定对象未被任何事件 / 信号槽引用的场景	所有 QObject 子类对象，尤其是控件、线程、网络对象、槽函数中销毁、跨线程销毁的场景

8.注意事项

Qt 官方推荐 ：所有QObject子类的动态销毁，优先使用deleteLater()，而非直接delete，这是 Qt 框架最安全的销毁方式。
配合 QPointer 使用 ：QPointer是 Qt 专为QObject设计的弱智能指针，对象销毁后会自动置空，和deleteLater()配合可完美规避野指针：

cpp 复制代码

QPointer<MyWidget> widget = new MyWidget;
widget->show();
widget->deleteLater();
// 访问前先判断，绝对安全
if (!widget.isNull()) {
    widget->doSomething();
}

父子对象无需重复调用 ：父对象调用deleteLater()后，析构时会自动销毁所有子对象，无需给子对象单独调用deleteLater()，除非子对象需要提前销毁。