COM如何避免两个对象互相调用场景下的死锁问题？

COM针对套间（Apartment）之间的跨调用场景，内置了专门的调度逻辑来避免循环调用引发的死锁，核心原理和实现逻辑如下：

核心前提：单线程套间（STA）的消息循环机制 #

所有单线程套间的宿主线程必须运行Windows消息循环，这是COM跨STA调度的基础：

• 跨STA的方法调用不会直接执行，而是被COM封装为标准消息，投递到目标STA线程的消息队列中等待执行
• 线程空闲时从队列取出消息，执行对应的COM调用逻辑，执行完成后再把返回值封送回调用方

循环调用场景的死锁规避逻辑 #

我们假设调用链路是 STA1的对象A → 调用STA2的对象B → B反向调用A，COM的处理流程如下：

1. 第一步A调用B时，STA1线程会进入COM内置的等待逻辑，此时线程不会完全挂起，而是继续处理特定范围的消息
2. 当B反向调用A的请求被投递到STA1的消息队列时，处于等待状态的STA1线程会识别到这是入站的COM调用消息，会中断当前的等待，先处理这个反向调用请求
3. 反向调用执行完成后，STA1线程再回到之前的等待状态，继续等待最初A调用B的返回结果

这里COM会严格判断消息的来源和类型，只有属于当前挂起调用链路中的反向入站调用才会被优先处理，无关的用户消息或者其他调用请求不会被提前调度，避免出现逻辑混乱。

其他套间类型的适配逻辑 #

• 对于多线程套间（MTA）：MTA允许多个线程同时进入执行，不存在单线程的独占等待问题，反向调用可以由MTA内的其他空闲线程直接执行，天然不会死锁
• 跨进程场景：跨进程调用本质上还是基于RPC的封送调度，和同进程跨STA的逻辑一致，只是封送层换成了RPC传输层，调度逻辑完全复用套间的消息处理规则

注意事项 #

如果STA线程没有正常运行消息循环，或者用户自定义的消息过滤逻辑拦截了COM的调度消息，COM的死锁规避机制会失效，这种场景下依然可能出现死锁。

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