.net - ThreadAbortException の悪い結果は何ですか?

Question

Thread.Abort()私は最近、外部システムへの同時リクエストをキャンセルするメソッドに依存するレガシー コードベースのマルチスレッド パターンに出くわしました。悪い結果の 1 つは、タイムアウト例外を他の例外タイプと区別するのが容易ではないことです。

ThreadAbortExceptionマルチスレッド制御フローで sを使用しない他の理由は何ですか?

Answer 1

マルチスレッド制御フローで ThreadAbortExceptions を使用しない他の理由は何ですか?

Thread.Abort はスレッドを非常に奇妙な状態のままにする可能性があり、きれいに処理することは不可能です。

Thread.Abortのドキュメントから:

あるスレッドが別のスレッドで Abort を呼び出すと、実行中のコードが中断されます。静的コンストラクターが中止される可能性もあります。まれに、これにより、そのアプリケーション ドメインでそのクラスのインスタンスが作成されなくなる場合があります。.NET Framework バージョン 1.0 および 1.1 では、finally ブロックの実行中にスレッドが中止される可能性があり、その場合、finally ブロックは中止されます。

マルチスレッド コードで作業している場合、デッドロックが発生する可能性があるため、これはさらに危険です。これも文書化されています：

中止されるスレッドがコードの保護された領域 (catch ブロック、finally ブロック、または制約付き実行領域など) にある場合、Abort を呼び出すスレッドはブロックされる可能性があります。Abort を呼び出すスレッドが、中止されたスレッドが必要とするロックを保持している場合、デッドロックが発生する可能性があります。

一般に、フレームワークの協調キャンセル モデルを使用し、 を呼び出さない方がはるかに安全でクリーンThread.Abortです。CancellationTokenandを使用CancellationTokenSourceすると、スレッドが独自のクリーンアップを適切に処理できるクリーンな方法で適切なキャンセルを設計できます。