BackgroundWorkerの残影と戦う：レガシーを「安全」に掌握する非同期設計の極意
多くのSI現場で、今なお現役で稼働するWindows Formsアプリケーション。その心臓部には、時代遅れと揶揄されつつも、依然として「同期の呪縛」からUIを解放する唯一の防波堤として `BackgroundWorker` が君臨している。
async/await（タスク並列ライブラリ）全盛の今、なぜあえて `BackgroundWorker` を語るのか。それは、レガシーコードの保守において「非同期処理の再設計」を強行することが、往々にしてUIスレッドのデッドロックやメモリリークという地獄への扉を開くからだ。
真のエンジニアは、ツールを捨てるのではない。ツールの深淵を理解し、その挙動を完全に制御下に置くのだ。
—
1. キャンセル処理の真実：フラグと状態遷移の同期
`BackgroundWorker` の `CancelAsync()` は、魔法ではない。単に `CancellationPending` プロパティを `True` に切り替えるだけの、極めて質素なメカニズムだ。
多くのジュニアエンジニアが陥る罠は、長時間ループの中でこのフラグをチェックしていないことにある。以下に、確実なキャンセル制御を実装するための「正解」を示す。
.net
‘ DoWorkイベント内での安全なキャンセルチェック
Private Sub backgroundWorker_DoWork(sender As Object, e As DoWorkEventArgs) Handles bgw.DoWork
Dim worker As BackgroundWorker = DirectCast(sender, BackgroundWorker)
For i As Integer = 0 To 100
‘ 1. キャンセル要求の有無を検知
If worker.CancellationPending Then
e.Cancel = True ‘ キャンセル確定をイベント引数にマーク
Exit For
End If
‘ 重い処理の実行
DoHeavyWork(i)
‘ 2. 進捗報告 (WorkerReportsProgress = True であること)
worker.ReportProgress(i, $”Processing {i}%”)
Next
End Sub
極限の知見： キャンセル時にリソース（ファイルハンドルやデータベース接続）が宙に浮くのを防ぐため、`RunWorkerCompleted` イベントでの後処理は必須だ。`e.Cancelled` フラグをチェックし、正常終了と異常終了（キャンセル）を厳密に分離せよ。
—
2. ReportProgressの安全な運用とスレッド境界
`BackgroundWorker` の最大の強みは、`ReportProgress` を呼び出すだけで、自動的に `SynchronizationContext` を介してUIスレッドへマーシャリングしてくれる点にある。
しかし、ここには落とし穴がある。`ReportProgress` に渡すオブジェクトが参照型である場合、UIスレッド側で描画される前にバックグラウンド側で状態が変化すれば、競合（Race Condition）が発生する。
鉄則： UIへの通知データは、必ず「イミュータブル（不変）」なオブジェクトとして構造化せよ。
.net
‘ 不変な進捗データ構造
Public Structure ProgressData
Public ReadOnly Percentage As Integer
Public ReadOnly Message As String
Public Sub New(p As Integer, m As String)
Percentage = p
Message = m
End Sub
End Structure
‘ ReportProgress呼び出し時
worker.ReportProgress(p, New ProgressData(p, “Status Update”))
—
3. メモリリークを撲滅する「後始末」の美学
`BackgroundWorker` を使い捨てのクラスとして実装する際、イベントハンドラの購読（`AddHandler`）を解除しないままインスタンスを放置すると、GC（ガベージコレクタ）が回収できない巨大なメモリリークが発生する。
特に、フォームの閉じるボタンを押しても処理が裏で回り続けるような設計は、Windowsのハンドル枯渇を招く。
.net
‘ インスタンス終了時の完全なクリーンアップ
Private Sub CleanupWorker()
If bgw IsNot Nothing Then
‘ イベント購読解除は基本中の基本
RemoveHandler bgw.DoWork, AddressOf backgroundWorker_DoWork
RemoveHandler bgw.ProgressChanged, AddressOf backgroundWorker_ProgressChanged
RemoveHandler bgw.RunWorkerCompleted, AddressOf backgroundWorker_RunWorkerCompleted
bgw.Dispose()
bgw = Nothing
End If
End Sub
—
4. レガシー環境におけるWindows APIとの調和
古いVB.NETシステムでは、`BackgroundWorker` 内から Win32 API を呼び出すケースも多い。だが注意せよ。多くのGDI+関連APIは「STA（シングルスレッドアパートメント）」を要求する。
`BackgroundWorker` はスレッドプールを利用するため、マルチスレッド環境とレガシーなAPIの相性は極めて悪い。もしAPI呼び出し中に例外が発生する場合、`DoWork` 内での `Try…Catch` は必須だが、さらに以下の防護壁を築くべきだ。
- 例外はUIへ伝搬させる： `RunWorkerCompleted` の `e.Error` プロパティを介して例外情報をUIスレッドに送る。決してバックグラウンドスレッドでダイアログを表示してはならない（アプリがフリーズする）。
- 例外のシリアライズ： エラー情報はカスタムクラスに詰め込み、UI側で適切にロギングするアーキテクチャにせよ。
—
結びに：なぜ、あえて「古い技術」を極めるのか
現代の `Task` や `async/await` は確かに強力だ。しかし、20年前のVB.NETコードベースには、現代のフレームワークが隠蔽してしまった「スレッドとは何か」「リソースとは何か」という本質が剥き出しで横たわっている。
`BackgroundWorker` を正しく使いこなせるということは、OSの仕組みと、UIスレッドの脆弱性を理解しているという証明に他ならない。
現場のコードがどれほど古かろうが、システムを支配するのは常に「細部へのこだわり」を持つエンジニアだ。この記事を読んだ君ならば、もう `BackgroundWorker` を恐れることはないはずだ。自信を持って、レガシーを掌握せよ。
