COM STA/MTA の基礎知識 - スレッドモデルとハングを避ける考え方

COM の STA/MTA は、Windows 開発や .NET から COM を触るときに避けて通りにくい基礎知識です。 特に検索で多いのは、UI スレッドがなぜ STA なのか、Apartment をまたぐと何が起きるのか、なぜハングするのか、という疑問です。

目次

• 1. まず結論（ひとことで）
• 2. Apartment Modelの呼び出しパターン（図）
  • 2.1. パターン1: 同一STAスレッド内での呼び出し
  • 2.2. パターン2: 同一MTA内での呼び出し
  • 2.3. パターン3: Apartmentを跨ぐ呼び出し
  • 2.4. マーシャリングのオーバーヘッド目安
• 3. STA（Single-Threaded Apartment）
  • 3.1. なぜUIスレッドでSTAが使われるのか
• 4. MTA（Multi-Threaded Apartment）
• 5. STA/MTAはどこで決まるのか
  • 5.1. .NETでのSTA/MTA
• 6. STAを間違えると起きるハングの具体例
  • 6.1. よくある状況
  • 6.2. 何が起きるのか
  • 6.3. 擬似コード（典型的な失敗パターン）
  • 6.4. 回避の要点
  • 6.5.「メッセージループを回す」って結局なに？
  • 6.6. 正しい方向の例（雑に書くとこう）
  • 6.7. もう一つのハング例: 同期呼び出し中のコールバック
• 7. ざっくり使い分け
• 8. まとめ
• 9. 参考資料

COMを使うとき、「どのスレッドで動くか」は避けて通れません。その中心にあるのが Apartment Model（STA/MTA） です。STA/MTAはWindowsの一般的なスレッド概念ではなく、COMオブジェクトの呼び出し規則を決めるためのスレッドモデルです。

この記事では、STAとMTAとCOMの関係を図にしながら、「なぜハングすることがあるのか」までつなげて説明します。

この記事の知識マップ

COMのSTA(Single-Threaded Apartment)とMTA(Multi-Threaded Apartment)は、どのスレッドからコンポーネントを呼んでよいかを決めるApartment Modelの2つの形です。STAは1スレッドに1Apartmentで、Apartmentを跨ぐ呼び出しはProxy/Stub経由でマーシャリングされます。別スレッドから呼ばれるSTAはメッセージループを回していないと呼び出しの転送を受け取れずハングし、同期呼び出し中にコールバックが来るパターンもデッドロックになりやすい構造です。MTAは複数スレッドで1Apartmentを共有する代わりに、オブジェクト側にスレッドセーフ設計を要求します。.NETの[STAThread]属性は、このApartment初期化を設定するラッパーにすぎません。

flowchart LR
    accTitle: COM STA/MTAの知識マップ
    accDescr: STAとMTAというCOMのApartmentモデルが、メッセージループ・マーシャリング・Proxy/Stubとどう関係し、メッセージループの不在がSTAのハングやデッドロックにつながる仕組みを示す図
    sta["STA(Single-Threaded Apartment)"]
    mta["MTA(Multi-Threaded Apartment)"]
    com["COM(コンポーネントオブジェクトモデル)"]
    com_apartment_model["COMアパートメントモデル(STA/MTA)"]
    coinitializeex["CoInitializeEx"]
    message_loop["メッセージループ"]
    proxy_stub["Proxy/Stub"]
    thread_safe_com_object["スレッドセーフなCOMオブジェクト設計"]
    windows_forms["Windows Forms"]
    stathread_attribute[".NETの[STAThread]/[MTAThread]属性"]
    threadingmodel_registry["ThreadingModelレジストリ値"]
    com_automation["Automation"]
    idispatch["IDispatch"]
    midl["MIDL"]
    sta_hang["STAのハング(呼び出し転送の停止)"]
    msgwaitformultipleobjects["MsgWaitForMultipleObjects"]
    sta_callback_deadlock["同期呼び出し中のコールバックによるデッドロック"]
    dotnet[".NET(Core以降)"]
    com_marshaling["マーシャリング"]
    com -->|"利用する"| com_apartment_model
    com_apartment_model -->|"前提とする"| coinitializeex
    sta -->|"前提とする"| message_loop
    sta -.->|"利用する"| proxy_stub
    mta -->|"前提とする"| thread_safe_com_object
    windows_forms -.->|"利用する"| sta
    windows_forms -->|"利用する"| message_loop
    stathread_attribute -->|"利用する"| coinitializeex
    threadingmodel_registry -.->|"前提とする"| sta
    com_automation -->|"利用する"| idispatch
    proxy_stub -.->|"で構成できる"| midl
    sta -.->|"原因になり得る"| sta_hang
    message_loop -->|"防止する"| sta_hang
    msgwaitformultipleobjects -.->|"防止する"| sta_hang
    sta -.->|"原因になり得る"| sta_callback_deadlock
    dotnet -.->|"原因になり得る"| sta_hang
    mta -.->|"利用する"| proxy_stub
    stathread_attribute -->|"前提とする"| com_apartment_model
    proxy_stub -->|"実装を担う"| com_marshaling
    com_automation -->|"実装を担う"| com_marshaling

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全20件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

1. まず結論（ひとことで）

• COMオブジェクトは「どのApartmentに所属するか」で呼び出し規則が決まる
• STAは 1スレッドに1Apartment、MTAは 複数スレッドで1Apartment と考えると理解しやすい
• Apartmentを跨ぐ呼び出しは、COMがProxy/Stub経由でマーシャリングする

2. Apartment Modelの呼び出しパターン（図）

COMオブジェクトの呼び出しには、大きく3つのパターンがあります。

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（1つのApartment）]
        Thread1[ワーカースレッド1]
        Thread2[ワーカースレッド2]
        Obj[COMオブジェクト]
        Thread1 -->|直接呼び出し| Obj
        Thread2 -->|直接呼び出し| Obj
    end

2.3. パターン3: Apartmentを跨ぐ呼び出し

異なるApartment間では、COMがProxy/Stubを使って転送します。 標準的なインターフェースならCOMランタイムが処理してくれます。

この先の表には、COM 特有の言葉が説明なしで出てきます。先に 1 行ずつ書いておきます。

注意: Proxy/Stubは何でも自動で用意されるわけではないのですが、実務では明示的に生成しなくて済む場合がほとんどです。

つまり、MIDLでProxy/Stub生成が必要になるのは、IDispatch を使わず IUnknown 直接派生のインターフェースを作る場合です。 .NETやスクリプト言語から使う一般的なCOMコンポーネントでは、この作業が必要になることは少ないです。

flowchart LR
    subgraph STA[STAスレッド]
        StaCaller[呼び出し元コード]
    end

    subgraph RT[COMランタイム（自動）]
        Proxy[Proxy]
        RPC[RPC/IPC]
        Stub[Stub]
        Proxy --> RPC --> Stub
    end

    subgraph MTA[MTAスレッド]
        MtaObj[COMオブジェクト]
    end

    StaCaller -->|呼び出し| Proxy
    Stub -->|転送| MtaObj

ポイント: Apartmentを跨ぐとマーシャリングのオーバーヘッドが発生します。 高頻度の呼び出しでは性能に影響するため、設計時に考慮が必要です。

2.4. マーシャリングのオーバーヘッド目安

以下は一般的な目安です（実測値ではなく、状況・パラメータの複雑さで大きく変わります）。

相対的な比較:

• 同一Apartment: 1回のメモリアクセス程度
• 異なるApartment: 1回のシステムコール程度
• 異なるプロセス: ローカルホストへのネットワーク通信程度

ループで1万回呼ぶような場面では、この差が顕著に効いてきます。

この数値の扱いについて

上の表は 桁（オーダー）の感覚をつかむためのもので、出典のある実測値ではありません。 公開されている統一ベンチマークがあるわけでもないので、この数値そのものを設計判断の根拠に使わないでください。

一方で、「同一 Apartment 内は直接呼び出し、境界を越えると必ずマーシャリングが挟まる」という構造は、Microsoft のドキュメントに書かれている仕様 です。Single-Threaded Apartments の項には、同じ Apartment 内ならインターフェースポインタをマーシャリングなしで渡せること、Apartment をまたぐ場合は同一プロセス内であってもプロセス間と同じマーシャリングの仕組みを使うこと、そして呼び出しが隠しウィンドウ（OleMainThreadWndClass）へのウィンドウメッセージとして届くことが明記されています。桁が変わるのはこの構造が理由 で、数値そのものは環境と引数の複雑さで動きます。

自分のケースで判断したいときは、同じインターフェースを同一 Apartment から呼んだ場合と、別 Apartment から呼んだ場合で測り比べるのが確実です。

// C#。同じ呼び出しを N 回繰り返して 1 回あたりの時間を出す
static void Measure(string label, Action call, int iterations = 100_000)
{
    call(); // 初回の遅延（JIT、プロキシ生成、接続確立）を計測から外す

    var sw = System.Diagnostics.Stopwatch.StartNew();
    for (int i = 0; i < iterations; i++)
    {
        call();
    }
    sw.Stop();

    double perCallNs = sw.Elapsed.TotalMilliseconds * 1_000_000.0 / iterations;
    Console.WriteLine($"{label}: {perCallNs:F1} ns/call");
}

引数の少ないメソッドと、文字列や配列を渡すメソッドの両方で測ると、「マーシャリング量で効き方が変わる」ことも見えます。

3. STA（Single-Threaded Apartment）

STAは「1スレッド = 1Apartment」というモデルです。

• そのApartment内のCOMオブジェクトは、基本的にそのスレッドでのみ実行
• 別スレッドから呼ぶと、COMがメッセージキュー/RPC経由で呼び出しを転送
• UIスレッド（WinForms/WPF）でよく使われる（UIも「1スレッド親和性＋メッセージループ」なので相性が良い）

3.1. なぜUIスレッドでSTAが使われるのか

UIスレッドとSTAは設計が一致しているからです。

• UIコントロールはスレッドセーフではない ボタンやテキストボックスなどは、生成したスレッドからしか安全に操作できない
• STAも同じく「1スレッド親和性」 COMオブジェクトは生成したスレッドでのみ直接実行される
• UIスレッドは必ずメッセージループを回す ウィンドウイベントを処理するために必須。STAの前提（メッセージポンプ）と一致する

だからWinForms/WPFのUIスレッドはデフォルトでSTAになっています。

ポイント: STAはスレッド親和性が高い代わりに、呼び出し元が多いと渋滞しやすい。

4. MTA（Multi-Threaded Apartment）

MTAは「複数スレッドで1Apartment」というモデルです。

• 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 Modelを設定するためのラッパーです。

• [STAThread] → Mainメソッド（エントリポイント）に付ける。COMを使う際にSTAとして初期化される
• [MTAThread] → 同様にMainメソッド用。MTAとして初期化される
• Thread.SetApartmentState(ApartmentState.STA) → 追加で作るスレッド用。スレッド開始前に設定が必要

注意点:

• [STAThread] があっても、実際にCOMを呼ぶまでは初期化されない（COMを使わないなら効果なし）
• 追加スレッドには [STAThread] は効かない。Thread.SetApartmentState を使う

つまり、.NETのSTA/MTAはCOMのSTA/MTAそのものであり、COM Interopのために用意された仕組みです。

重要: 後からApartmentを変更することはできません。最初の初期化が全てです。

6. STAを間違えると起きるハングの具体例

次のような構成は、実際にハングを引き起こしやすいです。

6.1. よくある状況

• バックグラウンドでSTAスレッドを作成してCOMオブジェクトを生成
• そのスレッドはメッセージループを回していない
• 別スレッド（STA/MTA問わず）からそのCOMオブジェクトを呼び出す

6.2. 何が起きるのか

ハングの理由は、STAの2つの前提に集約できます。この節が理由の説明で、以降の節では繰り返しません。

• COMオブジェクトは、生成したSTAスレッドで処理される 呼び出し元がSTAでもMTAでも、別スレッドからの呼び出しは必ずそのSTAスレッドへ転送されます。転送は、COMがそのApartmentに作る隠しウィンドウ（ウィンドウクラス OleMainThreadWndClass）へのウィンドウメッセージとして届きます
• その転送を受け取るには、STAスレッドがメッセージポンプを回している必要がある Microsoft のドキュメントでも「各STAは、他のプロセスや同一プロセス内の他のApartmentからの呼び出しを処理するために、メッセージループを持たなければならない」と明記されています

したがって、メッセージを回していないSTAスレッドは呼び出しを受け取れず、呼び出し元は返事を待ち続け、結果としてハングします。

なお、これは .NET でも同じです。Single-Threaded Apartments のドキュメントには、STAスレッドを Task.Wait()、Task.Result、Thread.Sleep()、ManualResetEvent.WaitOne() などでブロックすると、COMのコールバックやApartmentをまたぐ呼び出しが完了できずデッドロックになる、という警告が置かれています。次の 6.3 の失敗例が WaitOne() で止まっているのは、まさにこの形です。

一方、UIスレッドはウィンドウイベントを処理するために最初からメッセージループを回しているので、STAの要件を追加実装なしで満たしています。UIスレッドがSTAのCOMオブジェクトを動かす場所として自然な選択肢になるのは、このためです。

6.3. 擬似コード（典型的な失敗パターン）

using System;
using System.Runtime.InteropServices;
using System.Threading;

internal static class StaHangDemo
{
    private const uint COINIT_APARTMENTTHREADED = 0x2;

    [DllImport("ole32.dll")]
    private static extern int CoInitializeEx(IntPtr pvReserved, uint dwCoInit);

    [DllImport("ole32.dll")]
    private static extern void CoUninitialize();

    public static void Run(string progId)
    {
        var ready = new AutoResetEvent(false);
        var done = new AutoResetEvent(false);

        object comObj = null;

        var staThread = new Thread(() =>
        {
            // STAとして初期化
            CoInitializeEx(IntPtr.Zero, COINIT_APARTMENTTHREADED);

            // ThreadingModel=Apartment で登録された COM クラスを想定
            Type type = Type.GetTypeFromProgID(progId, throwOnError: true);
            comObj = Activator.CreateInstance(type);
            ready.Set();

            // メッセージループがないまま待機 -> ここが致命傷
            done.WaitOne();

            CoUninitialize();
        });

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

        ready.WaitOne();

        try
        {
            // 別スレッド（STA/MTA問わず）から呼ぶと、呼び出しがSTAに転送される
            // しかしSTA側はメッセージを処理しないため、ここでハングしやすい
            dynamic obj = comObj;
            obj.AnyMethod();
        }
        finally
        {
            // 呼び出しが返ってきた場合 ── agileなクラスだった、
            // 呼び出しが転送されなかった、AnyMethodが即座に返った ── でも、
            // 必ずSTAスレッドを解放する。ここを省くと、doneを待ち続ける
            // フォアグラウンドスレッドが残り、「再現しなかった」ときも
            // プロセスが終わらない。再現の有無を症状で見分けられなくなる
            done.Set();
            staThread.Join();
        }
    }
}

このコードは、ThreadingModel=Apartment（= STA）として登録された COM クラスの ProgID を渡す前提です。AnyMethod は、そのクラスが実際に持つメソッド名に置き換えてください。どの COM クラスでも再現するわけではありません。 再現に必要な条件は次の 3 つです。

obj.AnyMethod() を try / finally で挟み、done.Set() と staThread.Join() を必ず通しているのは、この「再現しないケース」を見分けるためです。STAスレッドは既定でフォアグラウンドスレッドなので、done が立たない限りプロセスは終わりません。finally を省くと、再現したとき(呼び出しが返らない)と再現しなかったとき(呼び出しが返ったが done を誰も立てない)で、外から見える症状がどちらも「プロセスが終わらない」になります。再現条件を確かめるための道具が、条件の成否を隠してしまうわけです。上の形なら、再現しなかった場合はそのまま正常終了します。

止まったことの確認は、デバッガでプロセスを一時停止し、呼び出し元スレッドのスタックが COM の待機で止まっていること、STAスレッドが WaitOne で止まっていることを見るのが早いです。

sequenceDiagram
    participant Main as メインスレッド
    participant STA as STAスレッド
    participant COM as COMランタイム

    Main->>STA: スレッド開始
    STA->>STA: CoInitializeEx（STA）
    STA->>STA: COMオブジェクト生成
    STA->>Main: ready.Set()
    STA->>STA: done.WaitOne()で待機
    Note over STA: メッセージループなし<br/>ここで詰まっている

    Main->>COM: CallComObject()
    COM->>STA: 呼び出しを転送しようとする
    Note over COM: メッセージで転送するが...
    Note over STA: WaitOne中なので<br/>メッセージを処理できない
    Note over Main: 呼び出し元も待ち続ける
    Note over Main,STA: 両方が待ち状態 → ハング

図の中央、「メッセージで転送するが…」の 2 行が、6.2 で書いた 2 つの前提が崩れている場所です。

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 の呼び忘れは普通に事故ります。CoInitializeEx の P/Invoke 宣言は 6.3 と同じものが要ります）

Application.Run() の引数なしの形は、フォームを持たずにメッセージループだけを回す ためのものです。用途としてはここがまさに想定される場面ですが、次の 2 点は押さえておいてください。

• System.Windows.Forms への参照が要ります。コンソールアプリなら、プロジェクトファイルに <UseWindowsForms>true</UseWindowsForms> を足します
• このループは自分では終わりません。 止めるには、そのスレッド上で Application.ExitThread()（またはアプリ全体を終える Application.Exit()）を呼びます。上の例で CoUninitialize() まで到達させたいなら、STAスレッドへ「終了」を伝えて ExitThread を呼ばせる仕組みが別に必要です

WinForms に依存したくない場合は、6.5 の GetMessage / DispatchMessage ループを自分で書くか、メッセージと同期オブジェクトの両方を待てる MsgWaitForMultipleObjects を使います。後者は「イベントで終了通知を受けつつ、COM の呼び出しも取りこぼさない」形にしたいときの定番です。

6.7. もう一つのハング例: 同期呼び出し中のコールバック

STAは「呼び出しが転送される」だけでなく、状況によっては逆方向（サーバー→クライアント）にコールバックが来ます。中でも同期呼び出し中にコールバックが発生するパターンは、デッドロックの定番です。

sequenceDiagram
    participant UI as UIスレッド（STA）
    participant Server as COMサーバー

    UI->>Server: DoWork()（同期呼び出し）
    Note over UI: DoWorkの戻りを待っている<br/>（メッセージを処理していない）
    Server->>UI: ProgressCallback()（コールバック）
    Note over UI: 待機中なので<br/>コールバックを受け取れない
    Note over Server: コールバックの完了を待っている
    Note over UI,Server: お互いが相手を待っている → デッドロック

なぜデッドロックになりやすいのか:

1. UIスレッドが DoWork() を同期呼び出し（ブロッキング）
2. UIスレッドは戻りを待っている（メッセージを処理していない）
3. サーバーが ProgressCallback() をUIスレッドに送る
4. UIスレッドは待機中なのでコールバックを受け取れない
5. サーバーはコールバックの完了を待っている
6. お互いが相手を待っている → 永遠に進まない

処理時間の長さは関係ありません。同期呼び出し中にコールバックが来るというパターン自体が問題になりやすいです。

補足: COMには状況によってメッセージを回す・再入する仕組みもあり、コンポーネントや呼び出し形態で挙動が変わります。 必ずデッドロックになるわけではありませんが、このパターンは避けるのが無難です。

7. ざっくり使い分け

迷ったときの優先順位は、「相手の要求 > UIの有無 > 並列性」 の順で見ると決まりやすいです。Apartmentは最初の初期化で確定して後から変更できないので、ここだけは実装を始める前に決めておきます。

8. まとめ

STA/MTAはCOMのためのスレッドモデルで、STAは1スレッド = 1Apartment、MTAは複数スレッドで1Apartmentという形をとります。Apartmentを跨ぐ呼び出しはCOMがProxy/Stub経由で転送してくれます（標準IF以外はMIDL等での生成・登録が必要）が、そこにはマーシャリングのオーバーヘッドが伴うため、高頻度の呼び出しが想定される場面ではApartment設計を慎重に決めたいところです。

ハングの観点では、「別スレッドからの呼び出しを受けるSTAスレッドは、メッセージポンプを回すことが前提」という一点に尽きます。メッセージを回していないSTAスレッドに呼び出すとハングしやすく、同期呼び出し中にコールバックが来るパターンもデッドロックになりやすい。UIスレッドは「1スレッド親和性」と「メッセージループ」を最初から持っているため、この前提を追加実装なしで満たしており、STAのCOMと相性が良いわけです。

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
• Single-Threaded Apartments（メッセージループが必須である理由、隠しウィンドウ、.NETでのデッドロック警告） https://learn.microsoft.com/en-us/windows/win32/com/single-threaded-apartments
• Multithreaded Apartments https://learn.microsoft.com/en-us/windows/win32/com/multithreaded-apartments
• InprocServer32（ThreadingModel の値） https://learn.microsoft.com/en-us/windows/win32/com/inprocserver32
• Application.Run メソッド（フォームなしでメッセージループを回す形と、その止め方） https://learn.microsoft.com/en-us/dotnet/api/system.windows.forms.application.run
• MsgWaitForMultipleObjects（メッセージと同期オブジェクトを同時に待つ） https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-msgwaitformultipleobjects

この記事のWordファイルをダウンロード

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

STAとMTAはどちらを選ぶべきですか？

UIが絡む処理ならSTA、大量の並列処理ならMTAが基本の使い分けです。STAは1スレッドに1Apartmentという形でスレッド親和性が高い一方、呼び出し元が多いと渋滞しやすくなります。MTAは複数スレッドで1Apartmentを共有するため並列性が高いですが、COMオブジェクト側にスレッドセーフ設計が必須になります。どちらでもない場合は、使う既存ライブラリやCOMサーバーの要求に合わせるのが現実的です。

なぜUIスレッドはSTAなのですか？

UIスレッドとSTAは設計が一致しているためです。ボタンやテキストボックスなどのUIコントロールはスレッドセーフではなく、生成したスレッドからしか安全に操作できません。STAも同じく1スレッド親和性のモデルです。さらにUIスレッドはウィンドウイベント処理のために必ずメッセージループを回しており、STAの前提であるメッセージポンプを追加実装なしで満たします。このためWinForms/WPFのUIスレッドはデフォルトでSTAになっています。

STAのCOMオブジェクトを呼ぶとハングするのはなぜですか？

STAのCOMオブジェクトへの呼び出しは、生成したSTAスレッドで処理されます。別スレッドからの呼び出しはCOMがメッセージ/RPC経由で転送しますが、STAスレッドがメッセージループを回していないと転送を受け取れず、呼び出し元が待ち続けてハングします。回避するには、別スレッドから呼ばれるSTAスレッドでメッセージループを回すか、UIスレッド上で生成・利用するか、STAが不要なら最初からMTAにすることです。

.NETの[STAThread]属性は何のためにありますか？

COMのApartment Modelを設定するためのラッパーです。Mainメソッドに付けると、COMを使う際にそのスレッドがSTAとして初期化されます。ただし実際にCOMを呼ぶまでは初期化されず、COMを使わないアプリでは効果がありません。また追加で作るスレッドには効かないため、スレッド開始前にThread.SetApartmentStateで設定します。Apartmentは最初の初期化で決まり、後から変更できない点にも注意が必要です。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。