QtConcurrent启动的线程调用waitForFinished后与主线程ID相同问题咨询

该现象是Qt Concurrent框架内置的线程窃取优化机制导致的，属于设计层面的既定行为，并非bug：

• QtConcurrent::run底层默认依赖全局QThreadPool实例完成任务调度，QThreadPool为了降低等待场景下的线程调度、切换开销，实现了任务窃取逻辑：当某个线程调用QFuture::waitForFinished()阻塞等待任务完成时，如果当前等待调度的任务还没有被分配到工作线程执行，线程池会直接将该任务放到当前等待线程中同步执行，无需额外唤醒或创建工作线程。
• 你第一次点击按钮时，全局线程池存在空闲工作线程，任务会被立刻分配到工作线程执行，因此第一次updateValue运行在独立线程；但当你在GUI主线程调用waitForFinished()进入阻塞状态后，后续点击触发的新任务提交到线程池时，线程池会检测到主线程正处于阻塞等待、可执行任务的状态，就会直接把新任务交给主线程执行，因此你会看到后续updateValue的线程ID和GUI主线程完全一致。

• 生产环境禁止在GUI主线程调用waitForFinished()这类阻塞接口，一方面会触发上述任务窃取逻辑，导致本该异步执行的任务跑到主线程运行，另一方面会直接阻塞GUI事件循环，造成界面无响应。正确的实现方式是使用QFutureWatcher绑定QFuture的finished信号，异步监听任务执行完成后再处理后续逻辑。
• 若特定场景必须调用等待接口，可以通过调整全局线程池的工作线程回收超时时间降低复现概率：调用QThreadPool::globalInstance()->setExpiryTimeout(-1)让工作线程永久存活，工作线程不会因为短暂空闲被回收，始终处于可调度状态，线程池就不会优先把任务交给阻塞等待的主线程执行。

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