終わらないメモリリークに終止符を。Windows Formsにおける「死んだフォーム」の追跡と排除
長年運用されているVB.NETのWindows Formsアプリケーションにおいて、「起動直後は軽快だが、長時間使い続けるとメモリを食いつぶし、挙句の果てにプロセスがクラッシュする」という怪奇現象に頭を抱えていないだろうか。
多くの開発者は、これを「.NETのGC（ガベージコレクション）の気まぐれ」で片付けようとする。だが、プロの現場においてGCは魔法の杖ではない。メモリリークは、君たちが書いたコードが「生存の証」を残し続けているから起きるのだ。
今日は、dotMemoryやVisual Studio診断ツールを使い、死んだはずのフォームやイベントハンドラの残骸を物理的に突き止め、二度とリークさせないための極限の設計指針を授ける。
—
1. なぜメモリリークは起きるのか：犯人は「強い参照」だ
Windows Formsで最も多いメモリリークの原因は、「閉じられたはずのフォームが、どこかのイベントハンドラによって参照され続けている」ことにある。
特に危険なのは、以下のような実装だ。
- 静的クラス（Static Class）やシングルトンへのイベント購読
- 不適切な匿名デリゲートの使用
- イベントハンドラを解除（-=）せずにフォームを閉じる
イベントハンドラを購読（+=）するということは、そのイベントの発行元が、購読者のインスタンスへの「強い参照」を持つことを意味する。発行元が静的な存在であれば、購読したフォームはアプリが終了するまでGCの対象にはならない。
—
2. 診断ツールで「生存者のリスト」を炙り出す
勘でコードを書き換えるのは素人のやることだ。まずは証拠を掴め。
Visual Studio 診断ツールでの特定手順
1. デバッグ開始: アプリを立ち上げ、メモリ使用量を確認する。
2. スナップショットの取得: フォームを開き、閉じる。この操作を数回繰り返す。
3. GCの強制実行: 診断ツールの「ガベージ コレクション」ボタンを押す。
4. ヒープの分析: まだメモリ上に残っているクラス名を確認する。ここに「閉じたはずのフォーム名」が残っていれば、それが犯人だ。
dotMemoryを使う場合:
「Key Retention Paths（主要な保持パス）」を確認せよ。どのオブジェクトが、どのルートでフォームを掴んでいるかが可視化される。これを見れば、自分が書いた「負の遺産」がひと目で分かるはずだ。
—
3. 実践：二度とリークさせない「イベントの断ち切り方」
では、どう設計すればよいのか。基本は「フォームが閉じられる際に、自ら購読を解除する」ことだ。以下にプロダクションコードのテンプレートを示す。
Public Class DetailForm
Inherits Form
‘ イベント購読の管理用プロキシ
Private Sub DetailForm_Load(sender As Object, e As EventArgs) Handles MyBase.Load
‘ 共有サービスのイベントを購読
AddHandler DataService.Instance.DataUpdated, AddressOf OnDataUpdated
End Sub
‘ フォームが閉じられる瞬間に全てを解除する
Protected Overrides Sub OnFormClosing(e As FormClosingEventArgs)
MyBase.OnFormClosing(e)
‘ 重要な儀式：購読解除（これがないとGCの対象外になる）
RemoveHandler DataService.Instance.DataUpdated, AddressOf OnDataUpdated
End Sub
Private Sub OnDataUpdated(sender As Object, e As EventArgs)
‘ ここでUIを更新する
If Me.InvokeRequired Then
Me.Invoke(Sub() UpdateUI())
Else
UpdateUI()
End If
End Sub
End Class
なぜこの書き方が必要なのか
`OnFormClosing` で `RemoveHandler` を呼ぶのは鉄則だ。もしこれを忘れると、`DataService` という静的インスタンスが `DetailForm` への参照を握り続け、メモリリークが確定する。これは単なる規約ではなく、メモリ管理における契約である。
—
4. ファイル・DB連携時の注意点：リソースの断捨離
フォームだけでなく、`IDisposable` を実装したオブジェクト（DBコネクション、Stream、Graphics）の管理もメモリ消費に直結する。
‘ 悪い例：usingを使わずCloseも忘れる
Dim fs As New FileStream(“data.bin”, FileMode.Open)
‘ 良い例：usingスコープで確実に開放する
Using fs As New FileStream(“data.bin”, FileMode.Open)
‘ 処理
End Using ‘ ここでDisposeが呼ばれ、メモリが解放される
Windows FormsのUIリソースは「アンマネージリソース」を内部で多く抱えている。`Dispose()` メソッドを明示的に呼ぶことは、OSに対する「もうこのメモリは不要だ」という強力な意思表示だ。
—
結論：コードは「書く」のではなく「管理する」ものだ
メモリリークを放置するエンジニアは、いずれ自分自身が書いた膨大なコードの墓場に埋もれることになる。
- イベント購読は必ず解除する。
- IDisposableなオブジェクトはUsingで包む。
- 診断ツールで「生存数」を監視する習慣を持つ。
これらを守るだけで、君のアプリケーションは驚くほど安定する。小手先のテクニックではなく、オブジェクトのライフサイクルを理解し、制御下に置くこと。それこそが、伝説のエンジニアへの第一歩だ。
さあ、今すぐ自分の書いたコードの「参照パス」を辿り、不要な絆を断ち切ってくるといい。君のアプリが真の安定を手に入れることを期待している。
