COM STA/MTA 基础 - 线程模型与避免 Hang 的思路

COM 的 STA/MTA，是从 Windows 或 .NET 接触 COM 时难以避开的基础知识。
搜索中特别常见的问题是：UI 线程为什么是 STA、跨 Apartment 会发生什么、为什么会 Hang。

目录

1. 先说结论（一句话）
2. Apartment 模型的调用模式（图）
   • 2.1. 模式1：同一 STA 线程内的调用
   • 2.2. 模式2：同一 MTA 内的调用
   • 2.3. 模式3：跨 Apartment 的调用
   • 2.4. Marshaling 开销的大致估计
3. STA（Single-Threaded Apartment）
   • 3.1. 为什么 UI 线程用 STA
4. MTA（Multi-Threaded Apartment）
5. STA/MTA 在哪里决定
   • 5.1. .NET 中的 STA/MTA
6. STA 处理不当时会发生的 Hang 具体例子
   • 6.1. 常见场景
   • 6.2. 到底发生了什么
   • 6.3. 伪代码（典型的失败模式）
   • 6.4. 避免的要点
   • 6.5.「让消息循环转起来」究竟是什么
   • 6.6. 正确方向的例子（随手写一下）
   • 6.7. 另一个 Hang 例子：同步调用中的 Callback
7. 大致的使用分类
8. 总结
9. 参考资料

使用 COM 时，「在哪个线程上运行」 是无法回避的议题。
核心就是 Apartment 模型（STA/MTA）。

STA/MTA 是 COM 专用的线程模型。
它不是 Windows 通用的线程概念，而是决定 COM 对象调用规则的机制。

本文会用 图来整理 STA、MTA 与 COM 的关系，并接着说明 「为什么会 Hang」。

1. 先说结论（一句话）

• COM 对象以「属于哪个 Apartment」来决定调用规则
• STA 是 1 线程 = 1 Apartment，MTA 是 多线程 = 1 Apartment，这样理解最轻松
• 跨 Apartment 的调用，COM 会经由 Proxy/Stub 进行 Marshaling

2. Apartment 模型的调用模式（图）

COM 对象的调用大致可分为三种模式。

2.1. 模式1：同一 STA 线程内的调用

在同一个 STA 线程内可以 直接调用。没有额外开销。

flowchart LR
    subgraph STA[STA 线程]
        Caller[调用方代码]
        Obj[COM 对象]
        Caller -->|直接调用| Obj
    end

2.2. 模式2：同一 MTA 内的调用

MTA 内的多个线程，任何一个线程都可以直接调用。
不过对象本身必须 设计为线程安全。

flowchart LR
    subgraph MTA[MTA（一个 Apartment）]
        Thread1[工作线程 1]
        Thread2[工作线程 2]
        Obj[COM 对象]
        Thread1 -->|直接调用| Obj
        Thread2 -->|直接调用| Obj
    end

2.3. 模式3：跨 Apartment 的调用

在不同 Apartment 之间 COM 会用 Proxy/Stub 转发。
若是标准接口，COM Runtime 会自动处理。

注意： Proxy/Stub 并不是「什么都会自动生成」。
只是实务上大多数情况不需要显式生成。

换句话说，需要用 MIDL 生成 Proxy/Stub 的情况，主要是不使用 IDispatch、而是制作 IUnknown 直接派生接口时。
从 .NET 或脚本语言使用一般的 COM 组件时，这种工作并不常见。

flowchart LR
    subgraph STA[STA 线程]
        StaCaller[调用方代码]
    end

    subgraph RT[COM Runtime（自动）]
        Proxy[Proxy]
        RPC[RPC/IPC]
        Stub[Stub]
        Proxy --> RPC --> Stub
    end

    subgraph MTA[MTA 线程]
        MtaObj[COM 对象]
    end

    StaCaller -->|调用| Proxy
    Stub -->|转发| MtaObj

要点：
跨 Apartment 会产生 Marshaling 的额外开销。
高频调用时会影响性能，设计时必须考虑。

2.4. Marshaling 开销的大致估计

以下是一般参考值（非实测，会依场景与参数复杂度有很大差异）。

相对比较：

• 同一 Apartment：约一次内存访问
• 不同 Apartment：约一次系统调用
• 不同进程：约一次 localhost 的网络通信

在循环中调用一万次的场景，这个差距会非常明显。

3. STA（Single-Threaded Apartment）

STA 是 「1 线程 = 1 Apartment」 的模型。

• 该 Apartment 内的 COM 对象 原则上只在那个线程上运行
• 其他线程调用时，COM 会经由消息队列/RPC 转发
• 常用于 UI 线程（WinForms/WPF）（UI 也是「1 线程亲和性 + 消息循环」，所以很搭）

3.1. 为什么 UI 线程用 STA

因为 UI 线程和 STA 设计一致。

• UI 控件不是线程安全的
  Button、TextBox 只能由创建它的线程安全操作
• STA 同样具有「1 线程亲和性」
  COM 对象只在创建它的线程上直接运行
• UI 线程必定有消息循环
  为了处理窗口消息必须有，和 STA 的前提（消息泵）一致

因此 WinForms/WPF 的 UI 线程 默认就是 STA。

要点：
STA 线程亲和性高，相对地 调用方多的时候容易阻塞。

4. MTA（Multi-Threaded Apartment）

MTA 是 「多线程 = 1 Apartment」 的模型。

• COM 对象会被多个线程同时调用
• 对象本身 必须设计为线程安全
• 适合服务端处理或后台处理

要点：
MTA 的并发性高，但 对象实现的责任也比较重。

5. STA/MTA 在哪里决定

COM 的 Apartment 是 通过在每个线程上初始化 来决定。

• 调用 CoInitialize / CoInitializeEx 的当下，该线程的 Apartment 就决定了
• STA：COINIT_APARTMENTTHREADED
• MTA：COINIT_MULTITHREADED

5.1. .NET 中的 STA/MTA

.NET 也有 [STAThread] / [MTAThread] 属性或 ApartmentState，但这些都是 设置 COM Apartment 模型的封装。

• [STAThread] → 标注在 Main 方法（入口点）。使用 COM 时会以 STA 初始化
• [MTAThread] → 同样用于 Main 方法。会以 MTA 初始化
• Thread.SetApartmentState(ApartmentState.STA) → 用于额外创建的线程。必须在线程启动前设置

注意：

• 即便有 [STAThread]，在实际调用 COM 之前并不会初始化（不用 COM 就没效果）
• 额外创建的线程 [STAThread] 无效。要用 Thread.SetApartmentState

也就是说，.NET 的 STA/MTA 就是 COM 的 STA/MTA 本身。
它不是 .NET 自己的线程模型，而是为了 COM Interop 而准备的机制。

重要：
初始化之后不能再改 Apartment。第一次的初始化就是全部。

6. STA 处理不当时会发生的 Hang 具体例子

以下这种配置 实际上很容易 Hang。

6.1. 常见场景

• 在后台创建一个 STA 线程并生成 COM 对象
• 该线程 没有在运行消息循环
• 从其他线程（不论 STA/MTA）调用那个 COM 对象

6.2. 到底发生了什么

STA 的 COM 对象 必须在那个 STA 线程上处理调用。
无论调用方是 STA 还是 MTA，只要是其他线程，COM 都会用消息/RPC 转发。

但 STA 线程 不处理消息 的情况下，调用会一直等下去，结果就是 Hang。

6.3. 伪代码（典型的失败模式）

var ready = new AutoResetEvent(false);
var done = new AutoResetEvent(false);

object comObj = null;
var staThread = new Thread(() =>
{
    // 以 STA 初始化
    CoInitializeEx(IntPtr.Zero, COINIT_APARTMENTTHREADED);

    comObj = new SomeStaComObject();
    ready.Set();

    // 没有消息循环就等待 -> 这里是致命伤
    done.WaitOne();
});

staThread.SetApartmentState(ApartmentState.STA);
staThread.Start();

ready.WaitOne();

// 从别的线程（STA/MTA 都一样）调用，调用会转发到 STA
// 但 STA 那边不处理消息，所以这里很容易 Hang
CallComObject(comObj);

sequenceDiagram
    participant Main as 主线程
    participant STA as STA 线程
    participant COM as COM Runtime

    Main->>STA: 线程启动
    STA->>STA: CoInitializeEx(STA)
    STA->>STA: 生成 COM 对象
    STA->>Main: ready.Set()
    STA->>STA: done.WaitOne() 等待
    Note over STA: 没有消息循环
卡在这里

    Main->>COM: CallComObject()
    COM->>STA: 尝试转发调用
    Note over COM: 用消息转发，但...
    Note over STA: 正在 WaitOne
无法处理消息
    Note over Main: 调用方也继续等待
    Note over Main,STA: 双方都在等 → Hang

简言之：
这里说的「前提」，是为了解释 「为什么在 STA 跨线程调用会 Hang」 而提到的前提。
STA 的前提有 两点：

• COM 对象在创建它的 STA 线程上处理
  其他线程的调用一定会被转发到那个 STA 线程
• 为了接收那些转发，STA 线程必须运行消息泵
  没运行就接不到

所以，

• 没有运行消息循环的 STA 线程 接不到调用
• 接不到的结果就是调用方一直等待，最后 Hang

另一方面，UI 线程 本来就为了处理窗口消息而一直运行消息循环，不需要额外实现就符合 STA 的要求。
所以 UI 线程自然成为运行 STA COM 对象的最佳场所。

6.4. 避免的要点

• 要接收其他线程的调用时，STA 线程必须运行消息循环
• 可能的话 在 UI 线程上创建与使用（UI 线程本来就有消息循环）
• 不需要 STA 时 一开始就用 MTA

补充： 如果只在同一线程内结束，不一定需要 Application.Run()。
不过 UI 相关、COM 相关经常会和其他线程的调用产生关联，实务上几乎都需要。

6.5.「让消息循环转起来」究竟是什么

Win32 UI 线程平常在运行的就是这段：

while (GetMessage(out var msg, IntPtr.Zero, 0, 0))
{
    TranslateMessage(ref msg);
    DispatchMessage(ref msg);
}

STA 上其他线程的调用会被「转发」过来。
接收这些转发并派发执行 的，就是这个循环（消息泵）。

6.6. 正确方向的例子（随手写一下）

若想「在后台 STA 使用 COM」，会是这样：

var ready = new AutoResetEvent(false);
object comObj = null;

var staThread = new Thread(() =>
{
    CoInitializeEx(IntPtr.Zero, COINIT_APARTMENTTHREADED);

    comObj = new SomeStaComObject();
    ready.Set();

    // STA 线程存活期间要运行消息循环
    Application.Run();

    CoUninitialize();
});

staThread.SetApartmentState(ApartmentState.STA);
staThread.Start();

ready.WaitOne();
CallComObject(comObj);

（※ 忘了 CoInitializeEx / CoUninitialize 会直接出问题）

6.7. 另一个 Hang 例子：同步调用中的 Callback

STA 除了「调用会被转发过来」之外，某些场景下还会有 反方向（服务端 → 客户端）的 Callback。
同步调用中发生 Callback 的模式 很容易造成死锁。

sequenceDiagram
    participant UI as UI 线程（STA）
    participant Server as COM 服务端

    UI->>Server: DoWork()（同步调用）
    Note over UI: 等待 DoWork 返回
（不处理消息）
    Server->>UI: ProgressCallback()（回调）
    Note over UI: 等待中
收不到回调
    Note over Server: 等回调完成
    Note over UI,Server: 彼此在等对方 → 死锁

为什么容易死锁：

1. UI 线程 同步调用（阻塞）DoWork()
2. UI 线程在等待返回（不处理消息）
3. 服务端对 UI 线程发送 ProgressCallback()
4. UI 线程等待中，无法接收回调
5. 服务端在等回调完成
6. 彼此在等对方 → 永远无法推进

处理时间的长短无关。同步调用中发生回调 的模式本身就容易出问题。

补充： COM 在某些场景下也会转发消息、发生重入，依组件与调用形态而行为不同。
不一定会死锁，但这种模式最好避免。

7. 大致的使用分类

• UI 相关 → STA
• 大量并发处理 → MTA
• 都不算 → 依现有库或 COM 服务端的要求决定

8. 总结

STA/MTA 是什么：

• STA/MTA 是 COM 专用的线程模型（不是 Windows 通用的线程概念）
• STA 是 1 线程 = 1 Apartment，MTA 是 多线程 = 1 Apartment
• 跨 Apartment 时 COM 会通过 Proxy/Stub 转发（标准接口以外要用 MIDL 等生成并注册）

STA 的前提与陷阱：

• 要接收其他线程的调用时，STA 必须运行消息泵
• 没有运行消息循环的 STA 线程收到调用 很容易 Hang
• 同步调用中发生回调 的模式 很容易死锁

UI 线程与 STA 的关系：

• UI 线程本来就有「1 线程亲和性」与「消息循环」
• 所以不需要额外实现就满足 STA 的条件，和 STA COM 很搭

设计时要注意：

• 跨 Apartment 的调用有 Marshaling 的额外开销
• 高频调用时会影响性能，Apartment 设计必须谨慎

9. 参考资料

• Apartment Model
  https://learn.microsoft.com/en-us/windows/win32/com/com-apartments
• CoInitializeEx
  https://learn.microsoft.com/en-us/windows/win32/api/objbase/nf-objbase-coinitializeex

下载本文的 Word 文件

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

常见问题

汇总了咨询这一主题时常见的问题。

STA 和 MTA 有什么区别？

STA（Single-Threaded Apartment）是「1 线程 = 1 Apartment」的模型，COM 对象原则上只在创建它的线程上运行；MTA（Multi-Threaded Apartment）是「多线程 = 1 Apartment」，COM 对象会被多个线程同时调用，因此对象本身必须设计为线程安全。STA/MTA 是 COM 专用的线程模型，不是 Windows 通用的线程概念。跨 Apartment 的调用会由 COM 通过 Proxy/Stub 进行 Marshaling，并产生额外开销。

为什么 UI 线程要用 STA？

因为 UI 线程和 STA 的设计一致。UI 控件不是线程安全的，只能由创建它的线程安全操作，这与 STA 的「1 线程亲和性」相同。此外 UI 线程为了处理窗口消息必定有消息循环，正好符合 STA 需要消息泵的前提。因此 WinForms/WPF 的 UI 线程默认就是 STA。

为什么 STA 的 COM 调用会 Hang？

典型场景是在后台创建 STA 线程并生成 COM 对象，但该线程没有运行消息循环。其他线程的调用会被 COM 用消息/RPC 转发到那个 STA 线程，但 STA 线程不处理消息，调用就会一直等下去，结果就是 Hang。另一个容易死锁的模式是同步调用中发生 Callback：UI 线程同步等待返回而不处理消息，服务端又在等回调完成，双方互相等待。

.NET 的 [STAThread] 属性是做什么的？

[STAThread] 标注在 Main 方法（入口点）上，表示使用 COM 时该线程会以 STA 初始化，本质上是设置 COM Apartment 模型的封装。要注意即便有 [STAThread]，在实际调用 COM 之前并不会初始化。额外创建的线程 [STAThread] 无效，要改用 Thread.SetApartmentState，且必须在线程启动前设置。另外 Apartment 在初始化之后不能再改，第一次的初始化就决定了一切。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。