为何程序会阻塞Windows OS Main Thread与GUI

Windows的GUI子系统采用按线程隔离消息队列的核心设计：

• 任何创建了顶层窗口的线程，都会由系统分配专属的消息队列，所有投递到该线程关联窗口的输入事件（鼠标、键盘操作）、绘制请求、系统通知，都会按顺序进入这个队列排队等待处理
• 承载窗口的线程（绝大多数程序都是把这个线程作为入口主线程）的核心运行逻辑是标准的消息泵循环：不断从队列头部取出待处理消息 -> 调用对应的窗口回调函数处理消息 -> 处理完成后回到循环取新消息。如果主线程在处理某条消息时，执行了超过用户可感知阈值（通常是100ms以上）的同步阻塞操作（比如批量文件遍历、大体积文件解析、复杂索引计算），就会打断这个消息循环，导致队列里的后续消息无法被及时取出，对应的窗口就会进入“无响应”状态。

很多用户感知到的“整个操作系统GUI被阻塞”，首先要区分两个容易混淆的场景：

• 绝大多数情况下这是单程序无响应带来的感知误判：当VS的主线程被长耗时加载操作卡住时，它自身的所有窗口会停止响应输入和重绘，加上VS窗口通常会在加载阶段置顶，用户点击其他程序时会被无响应的VS窗口遮挡，就会误以为全系统都卡死了。
• 这种把长耗时加载操作放在主线程同步执行的写法，本质上属于未遵守GUI开发规范的实现问题。按照Windows平台的GUI开发最佳实践，所有长耗时的IO、计算操作都应该拆分到独立的后台工作线程执行，主线程仅负责响应用户交互、渲染后台线程回传的进度信息，从架构上就不应该让主线程承担百毫秒级以上的阻塞操作。这类卡顿不是不可避免的，是可以通过代码优化解决的。

只有少数系统层面的场景会导致全范围的GUI响应延迟，和单个程序的代码规范无关：

• 内核态关键路径阻塞：当多个程序同时触发高优先级的内核态操作，导致负责系统GUI渲染、输入转发的win32k.sys模块出现锁竞争、消息传递队列阻塞时，全系统所有窗口的消息处理都会被拖住，这种场景下哪怕所有程序都严格遵守后台线程的规范，也会出现全局卡顿
• 物理资源耗竭的连锁反应：当加载操作触发了海量的内存申请，导致系统开始疯狂读写分页文件，把磁盘IO、内存带宽全部占满时，全系统的所有操作延迟都会指数级上升，带来全局的界面操作迟滞感。这种是硬件性能边界带来的连锁反应，不属于单程序的代码实现问题。

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