序論：GC（ガベージコレクション）という幻想を捨てよ
マネージド言語としてのVB.NETにおいて、我々が最も陥りやすい罠は「メモリ管理はランタイム（CLR）がすべて解決してくれる」という甘い幻想だ。しかし、Windows Forms（WinForms）の実体は、Win32 APIとGDIオブジェクトという「非マネージド資源」の厚いラッパーに過ぎない。
特に動的なUI生成を繰り返すシステムにおいて、`Controls.Add` したコントロールを単に `Remove` したり、親フォームを閉じるだけで満足しているなら、そのシステムは静かに、しかし確実に死（OutOfMemoryException）へと向かっている。
本稿では、シニアアーキテクトが遵守すべき「WinFormsコントロール破棄の鉄則」を、IDisposableパターンの深層からWindows APIの観点まで徹底的に解説する。
—
1. WinFormsにおける「死の代償」：IDisposableの真実
WinFormsのコントロールは、すべて `System.ComponentModel.Component` を継承し、`IDisposable` を実装している。なぜなら、彼らは「ウィンドウハンドル（HWND）」というOSレベルの貴重な資源を消費するからだ。
1.1 `Controls.Clear()` の罠
多くの開発者が犯す最大の過ちは、パネル上のコントロールを入れ替える際に `Panel1.Controls.Clear()` を呼んで安心することだ。
.net
‘ — 悪い例：これではメモリは解放されない —
Public Sub RefreshDashboard(ByVal data As DataTable)
pnlContainer.Controls.Clear() ‘ コレクションから外れるだけで、Disposeは呼ばれない
For Each row As DataRow In data.Rows
Dim ctrl As New CustomUserControl(row)
pnlContainer.Controls.Add(ctrl)
Next
End Sub
`Clear()` メソッドは、コントロールの親子関係を切り離すだけで、オブジェクトの `Dispose` は呼び出さない。切り離されたコントロールは、イベントハンドラやGDIリソースを保持したままマネージドヒープに居座り、GCすら手を出せない「ゾンビオブジェクト」と化す。
1.2 正解：明示的な反復破棄
動的に生成したコントロールは、必ず逆順で `Dispose` を呼び出すのが鉄則である。
.net
‘ — 正解：リソースを完全に解放する —
Public Sub ClearAndDisposeControls(ByVal targetPanel As Panel)
‘ 逆順でループしてDisposeを呼び出す
For i As Integer = targetPanel.Controls.Count – 1 To 0 Step -1
Dim ctrl = targetPanel.Controls(i)
targetPanel.Controls.RemoveAt(i)
If ctrl IsNot Nothing AndAlso Not ctrl.IsDisposed Then
ctrl.Dispose()
End If
Next
End Sub
—
2. `IContainer` と `components` の真価を知る
Visual Studioのデザイナーが自動生成する `InitializeComponent` 内にある `components` フィールド（`System.ComponentModel.IContainer`）。これこそが、WinFormsにおけるライフサイクル管理の要である。
2.1 自動破棄のメカニズム
フォームが破棄されるとき、`Dispose(ByVal disposing As Boolean)` メソッドが呼ばれ、その中で `components.Dispose()` が実行される。この `components` に登録されたコンポーネント（Timer, ImageList, ToolTipなど）は、フォームと運命を共にする。
2.2 実践：動的コンポーネントを `components` に登録する
自作のクラスや、動的に生成したTimerなどを確実に破棄させるには、デザイナーが用意した `components` コンテナを積極的に活用すべきだ。
.net
Partial Class MyComplexForm
‘ デザイナーが生成した components を利用する
Public Sub AddDynamicTimer()
‘ 第二引数に components を渡すことで、フォーム破棄時に自動で Dispose される
Dim t As New System.Windows.Forms.Timer(Me.components)
t.Interval = 1000
AddHandler t.Tick, AddressOf OnTick
t.Start()
End Sub
End Class
—
3. イベントハンドラ：リークの最大の温床
VB.NETにおいて、`AddHandler` は強力だが、それ以上に危険だ。イベントソース（発行側）が、イベントリスナ（購読側）への強参照を保持するため、リスナ側を `Dispose` したつもりでも、ソースが生きている限りメモリから消えることはない。
3.1 強参照の連鎖を断ち切る
特に「シングルトンなサービス」や「静的イベント」にUIコントロールを紐づける場合は、`Dispose` 内での `RemoveHandler` が絶対条件となる。
.net
Public Class LeakyControl
Inherits UserControl
Public Sub New()
‘ グローバルな設定変更イベントを購読
AddHandler GlobalSettings.Changed, AddressOf OnSettingsChanged
End Sub
Protected Overrides Sub Dispose(ByVal disposing As Boolean)
If disposing Then
‘ 購読解除を忘れると、GlobalSettingsがこのインスタンスを掴み続け、リークする
RemoveHandler GlobalSettings.Changed, AddressOf OnSettingsChanged
If components IsNot Nothing Then
components.Dispose()
End If
End If
MyBase.Dispose(disposing)
End Sub
End Class
—
4. 極限のデバッグ：GDIオブジェクトとメモリプロファイラ
コードが正しいと確信しても、リークは忍び寄る。プロフェッショナルは、感覚ではなく数値で判断する。
4.1 タスクマネージャーで「GDIオブジェクト」を監視せよ
通常の「メモリ」列だけを見てはいけない。
1. タスクマネージャーの「詳細」タブを開く。
2. 列の選択で「GDIオブジェクト」と「ハンドル数」を表示させる。
3. UIの生成・破棄を繰り返し、GDIオブジェクトが元の数値に戻らない場合、確実に `Dispose` 漏れが発生している。
Windows OSにおいて、1プロセスが保持できるGDIハンドル数には上限（通常10,000）があり、これを超えた瞬間にアプリケーションの描画は崩壊する。
4.2 Windows API による動的監視
コード内から現在のリソース消費量を監視し、異常を検知するコードを組み込むことも、長期稼働システムでは有効だ。
.net
”’
”’
Public Class Win32Resources
Private Shared Function GetGuiResources(ByVal hProcess As IntPtr, ByVal uiFlags As UInteger) As UInteger
End Function
Public Shared Function GetGdiObjectCount() As UInteger
Return GetGuiResources(System.Diagnostics.Process.GetCurrentProcess().Handle, 0) ‘ 0 = GDI objects
End Function
End Class
—
結論：アーキテクトの責務
WinFormsにおけるメモリ管理の本質は、「誰がオブジェクトの所有者（Owner）であり、誰がその終焉を見届けるのか」を明確に定義することにある。
1. 動的に作成したものは、明示的に `Dispose` せよ。 `Controls.Clear()` で満足するな。
2. `IContainer` を使い倒せ。 コンポーネントの管理をランタイムに委ねる唯一の安全な道だ。
3. イベントの購読は必ず解除せよ。 弱参照イベントの実装を検討するのも一つの手だが、まずは `RemoveHandler` の徹底が基本だ。
「動けばいい」というコードは、数日後の運用現場で「原因不明のフリーズ」という牙を剥く。真のエンジニアであれば、ハンドルの一つ、バイトの一滴まで掌握し、完璧なライフサイクルを設計せよ。
