BUG：由Qt::BlockingQueuedConnection引起的关闭Qt主页面而后台仍有进程残留

1、错误代码示例

首先我们看下下面的代码，可以思考一下代码的错误之处

/** BlockingQueueDeadLock.h **/
#pragma once

#include <QtWidgets/QMainWindow>
#include "ui_BlockingQueueDeadLock.h"
#include <thread>

class BlockingQueueDeadLock : public QMainWindow
{
    Q_OBJECT

public:
    BlockingQueueDeadLock(QWidget *parent = nullptr);
    ~BlockingQueueDeadLock();

public slots:
	void RecvBlockingQueueSignal();
signals:
	void SendBlockingQueueSignal();

private:
	void startLoopTest();
	void stopLoopTest();
	void RunInThread();

private:
    Ui::BlockingQueueDeadLockClass ui;
	std::thread loopTest;
	bool m_StopFlag;
};

/** BlockingQueueDeadLock.cpp **/
#include "BlockingQueueDeadLock.h"
#include <qdebug.h>

BlockingQueueDeadLock::BlockingQueueDeadLock(QWidget *parent)
    : QMainWindow(parent)
	, m_StopFlag(false)
{
    ui.setupUi(this);
	startLoopTest();
	connect(this, &BlockingQueueDeadLock::SendBlockingQueueSignal,
		this, &BlockingQueueDeadLock::RecvBlockingQueueSignal, Qt::BlockingQueuedConnection);
}

BlockingQueueDeadLock::~BlockingQueueDeadLock()
{
	stopLoopTest();
}

void BlockingQueueDeadLock::RunInThread()
{
	qDebug("%1", std::this_thread::get_id());
	while (!m_StopFlag) {
		std::this_thread::sleep_for(std::chrono::microseconds(10));
		qDebug("signal thread: %1", std::this_thread::get_id());
		emit SendBlockingQueueSignal();
	}
}

void BlockingQueueDeadLock::RecvBlockingQueueSignal()
{
	qDebug("slot thread: %1", std::this_thread::get_id());
}

void BlockingQueueDeadLock::startLoopTest()
{
	m_StopFlag = false;
	loopTest = std::thread(&BlockingQueueDeadLock::RunInThread, this);
}

void BlockingQueueDeadLock::stopLoopTest()
{
	m_StopFlag = true;
	if (loopTest.joinable()) {
		loopTest.join();
	}
}

上面短短几十行代码竟会导致当我关闭Qt主页面时，后台的进程并没有完全退出。

2、原因分析

先使用转储工具获取当前后台进程的堆栈信息；右击后台进程->创建转储文件

这时会获得一个DMP文件，通过windbg分析该DMP文件，如下图所示

我们可以清晰的看到后台进程一直在等待join函数的退出；阅读源码分析join最终调用的时_Thrd_join这个接口，该接口是阻塞的，需要等待线程的主函数运行结束后才会返回。

也就是说我们RunInThread线程主函数迟迟没有结束。

BlockingQueueDeadLock::~BlockingQueueDeadLock()
{
	stopLoopTest();
}

void BlockingQueueDeadLock::RunInThread()
{
	qDebug("%1", std::this_thread::get_id());
	while (!m_StopFlag) {
		std::this_thread::sleep_for(std::chrono::microseconds(10));
		qDebug("signal thread: %1", std::this_thread::get_id());
		emit SendBlockingQueueSignal();
	}
}
void BlockingQueueDeadLock::stopLoopTest()
{
	m_StopFlag = true;
	if (loopTest.joinable()) {
		loopTest.join();
	}
}

线程的主函数就是一个while循环，在我们BlockingQueueDeadLock析构的时候会将标识符m_StopFlag置为true；按道理讲该while循环应该很快的结束并返回。

但是！但是！但是！我们是否忽略了emit这个信号发射的是如何connect的呢？

connect(this, &BlockingQueueDeadLock::SendBlockingQueueSignal,
		this, &BlockingQueueDeadLock::RecvBlockingQueueSignal， Qt::BlockingQueuedConnection);

非常非常奇怪的是为什么connect最后一个参数是Qt::BlockingQueuedConnection呢？我看到这个代码也会很奇怪，可能之前的开发者认为发送信号和接受信号的slot不在同一个线程吧！！

3、解决方案

奇怪的地方必有妖，没错就是Qt::BlockingQueuedConnection这里有问题。

先看Qt官方文档的解释：

非常明确的指出了发射的信号与接收的槽不能在同一个线程里，否者会导致应用死锁。

想要了解Qt BlockingQueuedConnection源码的同学可以看下面的文章：

14.QueuedConnection和BlockingQueuedConnection连接方式源码分析_Master Cui的博客-CSDN博客

明确的指出了使用BlockingQueuedConnection同一个线程时死锁的原因。

因此，我们只需要将Qt::BlockingQueuedConnection最后的参数去除，使用默认参数即可。

这就是我发现的Qt主界面关闭，而后台进程未释放的问题；还是由于后台进程中的某个线程没有释放，而该线程没有结束又是由于Qt::BlockingQueuedConnection死锁导致的。

4、总结

当前Qt主界面关闭，而后台进程未释放的原因有很多。这里只是展示了其中一个原因：后台进程中有线程未及时释放导致的，也为遇到同样问题的你提供一个思路。