QT queued connection下Signal与Slot通信时间的不确定性问题咨询

我对Qt的queued connection模式下Signal与Slot通信机制的时间不确定性存在疑问：

• Signal与Slot所属对象分属两个不同线程，Worker线程以每秒60次的频率向Main线程的Slot发射Signal
• Main线程运行在事件循环中，Worker线程持续按该频率发射Signal
• 测试场景中Main线程处于理想状态，Slot仅包含return语句（预期可立即返回）

我测量了Signal-Slot通信耗时并绘制了图表，发现存在间歇性大幅峰值，通信时间并非如预想般线性。

预期：当Worker线程与Main线程均未参与其他操作时，Signal-Slot通信耗时应始终一致，至少不应出现突发性间歇性峰值。

首先得明确：Qt的queued connection本质是跨线程事件投递——Signal发射时会把调用封装成事件放到目标线程的事件队列里，目标线程的事件循环处理到这个事件时才会执行Slot。你看到的峰值根本不是Slot执行的耗时，而是事件在队列里等待的时间。

为什么会出现间歇性峰值？ #

1. 系统线程调度的不确定性：哪怕你的主线程看起来没做别的，操作系统的调度器也会随时把CPU时间片分给其他系统进程（比如后台服务、系统守护进程）。主线程被挂起的那段时间，Worker发过来的Signal事件会攒在队列里，等主线程重新拿到CPU时，这些事件会被批量处理，但你测量的是「Signal发射到Slot执行」的总时间，前面攒的事件会导致后续Signal的等待时间变长，出现峰值。
2. Qt事件循环的额外开销：主线程的事件循环不只会处理你自定义的Signal事件，还会处理系统窗口事件、定时器事件、甚至Qt内部的维护事件（比如对象清理、事件分发的内部逻辑）。这些事件的突发处理会挤占Signal事件的处理时机，导致等待时间变长。
3. 线程同步的隐性开销：跨线程投递事件时，Qt内部会用互斥锁等线程同步原语保证事件队列的线程安全。虽然这些操作很快，但系统层面的锁竞争偶尔会出现延迟，尤其当系统有其他线程也在做同步操作时，这种延迟会被放大成你看到的峰值。

验证思路 #

• 拆分测量维度：不要只测「Signal发射到Slot执行」的总时间，分开测「Signal发射到事件入队」的时间，和「事件出队到Slot执行」的时间，你会发现峰值全出在后者，也就是事件等待被处理的阶段。
• 临时调高主线程优先级（不建议长期这么做，会影响系统稳定性），峰值出现的频率会降低，但不可能完全消失——普通桌面/服务器操作系统的调度本质是非实时的。

结论 #

Qt的queued connection本身不保证严格实时性，哪怕在理想测试环境下，操作系统的线程调度、事件循环的额外处理都会导致通信耗时出现波动。你预期的「始终一致的耗时」只有在硬实时系统或完全独占CPU的环境下才可能实现，普通桌面/服务器系统做不到这一点。

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