Qt5/C++多线程开发中新建对象线程归属错误的原因及正确修复方案

核心概念先理清 #

所有这类问题的根源，都是混淆了两个完全独立的“线程”概念：

1. 真实代码执行线程：即当前CPU正在跑这段代码的操作系统线程，对应API是QThread::currentThread()，这个值是动态的，代码跑到哪，这个值就对应哪的线程。
2. QObject的线程亲和性：即obj->thread()的返回值，是QObject实例的一个静态属性——专门指定哪个线程的事件循环来处理这个实例排队的信号槽、定时器事件。这个属性是可以通过moveToThread()主动修改的，和当前哪个线程在执行这个obj的成员方法没有任何绑定关系。

关于QObject亲和性的赋值规则：

• 创建QObject实例时，如果没有传入带已知亲和性的parent，新对象的初始亲和线程 = 真实执行new代码的OS线程
• 主动调用obj->moveToThread(targetThread)后，obj的亲和性会被永久设置为targetThread，后续不管哪个线程调用obj的方法，obj->thread()永远返回targetThread

两个核心疑问的直接解答 #

1. 为什么线程#0发起的方法调用，this->thread()显示为线程#1 #

你代码里的this指针，是一个之前已经被主动调用过moveToThread(thread1)的QObject实例。它的亲和性属性早在moveToThread的时候就被永久设置成了线程#1。
现在你直接在线程#0里同步调用这个实例的成员方法，代码确实是在线程#0里实打实运行的，但因为this->thread()读的是对象自身的静态亲和属性，不是当前代码的执行线程，所以打出来的结果永远是#1，和真实执行位置无关。
这是90%Qt多线程新手踩坑的起点——误以为this->thread()能查询当前代码的运行线程，实际上这个API根本没有这个功能。

2. 为什么跨线程直接调用的场景下，新建的hardware对象归属为线程#0 #

当你在线程#0里同步调用这段创建逻辑时，真实执行new hardware()这行代码的OS线程就是#0。按照QObject的初始亲和规则，没有指定parent的新对象，初始亲和性就和执行new的真实线程绑定——也就是hardware的归属本来就应该是线程#0，完全符合Qt的设计规则。
你看到的“错位感”本质是日志的语义错位造成的：

• 第一行日志this->thread()读的是对象静态亲和属性，返回#1
• 第二行日志hardware->thread()读的是新对象创建时绑定的真实执行线程，返回#0

两个结果根本不是在描述同一个维度的信息，叠在一起就会造成“同一段代码在两个线程里同时跑”的错觉。

为什么改成槽函数触发后归属就符合预期 #

当你把创建hardware的逻辑改成槽函数，通过队列连接触发时，整个执行链路就变了：

1. 调用方（线程#0）只会往目标线程的事件队列里投递一个调用事件，根本不会同步执行这段创建逻辑
2. 等线程#1的事件循环处理到这个队列事件时，才会在#1的真实代码上下文里执行槽函数内容
3. 这时候执行new hardware()的真实线程就是#1，hardware的亲和性自然会绑定到#1，和你最初的预期完全一致。

正确的实践边界 #

• 排查这类问题时，永远用QThread::currentThread()打日志校验真实代码执行位置，不要用obj->thread()判断当前运行环境
• 永远不要跨线程直接同步调用已经moveToThread到其他线程的QObject的成员方法，所有跨线程交互必须通过队列连接的信号槽，或者指定Qt::QueuedConnection的QMetaObject::invokeMethod触发
• 新建QObject对象时，不要指望“方法写在哪个类里，对象就归哪个线程”——必须保证这行new代码的真实执行线程，就是你期望的对象归属线程。

内容的提问来源于stack exchange，提问作者TSG