Memory Leakの温床を断つ：Windows Formsにおけるイベントハンドラの適切な解除とDisposeパターンの極意
業務アプリケーションの現場で、こんな怪現象に頭を悩ませたことはないか？
「画面を開閉するたびに、タスクマネージャーのメモリ使用量が右肩上がりに増えていく」
「長時間稼働させると、やがて `OutOfMemoryException` でアプリケーションがクラッシュする」
犯人は、Windows Formsのイベント駆動モデルの特性、そして「イベントハンドラの野放し」だ。
今回は、VB.NETによるWindows Forms開発において、サブフォームやカスタムコントロールのライフサイクルを完全に掌握し、メモリリークの温床を断つための決定版アーキテクチャを伝授する。
—
1. なぜWindows Formsでメモリリークが起きるのか？
Windows FormsのUIコンポーネントは、背後でWin32のネイティブハンドルやGDI+リソースを抱えている。さらにVB.NETのイベント（`AddHandler` または `+=` 構文）は、「発行元（Publisher）が購読者（Subscriber）の強力な参照（Strong Reference）を保持する」という仕様上のトラップを持っている。
破滅へのシナリオ
1. 親フォームが子フォームを生成し、子フォームの独自イベントを購読する。
.net
‘ 親フォーム側でのイベント購読
AddHandler subForm.DataUpdated, AddressOf OnDataUpdated
2. ユーザーが子フォームを閉じる（`Close()` または `Hide()`）。
3. 子フォームの見た目は消えるが、親フォームが子フォームへのイベント参照（デリゲート）を握りしめているため、GC（ガベージコレクタ）の回収対象から外れる。
4. 結果、子フォームのインスタンスがメモリ上に幽霊のように居座り続け、親やデータベース接続までも巻き込んでメモリリークを引き起こす。
「フォームを閉じれば消える」という素朴な幻想は、今すぐ捨てていただきたい。
—
2. 鉄則：登録したイベントは必ず解除せよ
イベントを購読したら、不要になった時点で必ず解除（`RemoveHandler`）しなければならない。しかし、それを手動で各所に散りばめると、必ず解除漏れのバグが発生する。
ここで、IDisposable パターンの出番だ。クラスの寿命管理とリソース解放の責任を、そのオブジェクト自身に持たせる。
—
3. 実装例：メモリリークを完全封鎖するプロダクションコード
以下のコードは、データベースや外部ファイルを操作するサービス層を持ち、頻繁に生成・破棄される「データ入力サブフォーム」の模範的な実装である。
コピペしてそのまま現場のアーキテクチャの基準として使えるよう、細部まで堅牢に作り込んでいる。
.net
Imports System.Data.SqlClient
Imports System.IO
Namespace FormsArchitecture.Samples
”’
”’
Public Class DataEntrySubForm
Inherits Form
Implements IDisposable
‘ イベント定義：親フォームへ処理完了を通知する
Public Event DataProcessed As EventHandler(Of String)
‘ マネージドリソース（DB接続や内部コンポーネント）
Private _dbConnection As SqlConnection
Private _isDisposed As Boolean = False
Public Sub New(ByVal connectionString As String)
MyBase.New()
‘ UIコントロールの初期化（コンポーネントデザイナー生成コード想定）
InitializeComponent()
‘ 外部リソース（DB接続）の初期化
_dbConnection = New SqlConnection(connectionString)
‘ イベントの購読（自身が発行元または購読者になる場合の初期化）
‘ 例: 内部ボタンのクリックイベント
AddHandler Me.btnExecute.Click, AddressOf BtnExecute_Click
End Sub
”’
”’
Private Sub BtnExecute_Click(sender As Object, e As EventArgs)
Try
‘ データベース連携処理のシミュレーション
_dbConnection.Open()
‘ 処理成功をイベントで通知
RaiseEvent DataProcessed(Me, “処理が正常に完了しました。”)
Catch ex As Exception
‘ 実業務ではログ出力基盤へ接続
MessageBox.Show($”エラーが発生しました: {ex.Message}”, “エラー”, MessageBoxButtons.OK, MessageBoxIcon.Error)
Finally
‘ 接続は使い回さず、メソッド内で確実に閉じる
If _dbConnection.State = ConnectionState.Open Then
_dbConnection.Close()
End If
End Try
End Sub
Region ” IDisposable パターンの実装 ”
”’
”’
Protected Overrides Sub OnFormClosed(e: FormClosedEventArgs)
MyBase.OnFormClosed(e)
‘ フォームが閉じられたら明示的にDisposeを呼び出し、リソース連鎖を切断する
Me.Dispose()
End Sub
”’
”’
Protected Overloads Overrides Sub Dispose(disposing As Boolean)
If Not _isDisposed Then
If disposing Then
‘ 1. 【最重要】自身が張ったイベントハンドラの解除 (-= 相当)
‘ これにより、このフォームインスタンスへの参照を断ち切る
RemoveHandler Me.btnExecute.Click, AddressOf BtnExecute_Click
‘ 2. マネージド リソース（IDisposable実装オブジェクト）の明示的解放
If _dbConnection IsNot Nothing Then
If _dbConnection.State = ConnectionState.Open Then
_dbConnection.Close()
End If
_dbConnection.Dispose()
_dbConnection = Nothing
End If
‘ 3. コンポーネントコンテナの破棄
If components IsNot Nothing Then
components.Dispose()
End If
End If
‘ アンマネージド リソースがあればここで解放 (今回はなし)
_isDisposed = True
End If
MyBase.Dispose(disposing)
End Sub
Region ” Windows Form Designer generated code ”
‘ ダミーのコントロール宣言（実際のデザイナコードに準拠）
Friend WithEvents btnExecute As Button
Private components As System.ComponentModel.IContainer = Nothing
Private Sub InitializeComponent()
Me.btnExecute = New Button()
Me.SuspendLayout()
‘
‘ btnExecute
‘
Me.btnExecute.Location = New Point(30, 30)
Me.btnExecute.Name = “btnExecute”
Me.btnExecute.Size = New Size(120, 30)
Me.btnExecute.TabIndex = 0
Me.btnExecute.Text = “データ処理実行”
Me.btnExecute.UseVisualStyleBackColor = True
‘
‘ DataEntrySubForm
‘
Me.ClientSize = New Size(284, 161)
Me.Controls.Add(Me.btnExecute)
Me.Name = “DataEntrySubForm”
Me.ResumeLayout(False)
End Sub
End Region
Region ” IDisposable.Dispose (Explicit) ”
‘ IDisposableインターフェースの明示的実装（FormがIDisposableを継承しているため重複注意だが念のため網羅）
Public Shadows Sub Dispose() Implements IDisposable.Dispose
Dispose(True)
GC.SuppressFinalize(Me)
End Sub
End Region
Region ” ファイナライザ ”
‘ アンマネージド資源を直接保持する場合のみファイナライザを実装する。
‘ Windows Formsの一般的なコントロール・フォームではGC.SuppressFinalizeが効くため不要なケースが多いが、
‘ アンマネージドAPIを直叩きしている場合はコメントアウトを解除すること。
‘ Protected Overrides Sub Finalize()
‘ Dispose(False)
‘ MyBase.Finalize()
‘ End Sub
End Region
End Region
End Class
End Namespace
—
4. 現場のリーダーが教える「ファイル・DB連携における設計上の罠」
メモリリークと並んで業務アプリをクラッシュさせる原因が、ファイルロックとコネクション枯渇だ。
A. データベース接続（`SqlConnection` 等）の寿命
前述のコードの通り、データベース接続は「必要な最小限のスコープで開き、即座に閉じる（Using または Try-Finally）」のが鉄則だ。フォームの寿命とDB接続の寿命を直結させると、ユーザーが画面を開きっぱなしにした際にコネクションプールを圧迫し、システム全体のパフォーマンスが劣化する。
B. ファイルI/O（`StreamReader` / `FileStream`）の解放漏れ
CSV取り込みなどの機能でファイルを扱う際、ファイルを掴んだまま解放し忘れると、別のプロセス（Excel等）からファイルを開けなくなる。
VB.NETの `Using` ステートメントを強制し、スコープを抜けた瞬間に確実にリソースが破棄される構造をコードレビューで厳格にチェックすべきだ。
.net
‘ 正しいファイル読み込みの作法
Using fs As New FileStream(“data.csv”, FileMode.Open, FileAccess.Read)
Using reader As New StreamReader(fs, System.Text.Encoding.UTF8)
Dim line As String = reader.ReadLine()
‘ 処理…
End Using
End = ‘ このスコープを抜けた瞬間に、自動的に fs.Dispose() と reader.Dispose() が呼ばれる
—
5. まとめ：堅牢なアーキテクチャのために
業務効率化ツールや社内システムであっても、「動けばいい」という粗雑なコードは、やがて運用フェーズで必ず開発チームの首を絞めることになる。
1. イベントを購読したら、必ず `RemoveHandler`（またはDispose内での確実な切断）を行う。
2. サブフォームやカスタムコントロールには `IDisposable` パターンを徹底し、マネージド/アンマネージド資源のライフサイクルをコントロールする。
3. DBやファイルは持ち越さず、最小スコープで使い捨て、確実な解放を行う。
この3つをチームのコーディング規約に組み込むだけで、メモリリーク起因の不可解なバグは跡形もなく消え去るはずだ。
プロフェッショナルとして、メモリの隅々まで意図の通った美しいコードベースを構築してほしい。
