参照の鎖を断ち切れ：WinFormsにおけるWeakEventManagerを用いた「メモリリーク・ゼロ」の疎結合設計
業務自動化ツールの開発現場において、多くのエンジニアが陥る「見えない罠」がある。それは、「画面を閉じたはずなのに、メモリ使用量が減らず、プロセスが居座り続ける」という現象だ。
特に、親フォームから子フォーム、あるいは兄弟フォームへとデータをリアルタイムに同期させる設計を導入した際、この問題は牙を剥く。標準的な `AddHandler` によるイベント購読は、一見すると完璧に動作する。しかし、その裏側では、イベント発行側（Publisher）が購読側（Subscriber）への「強い参照」を握り続けている。
結果として、フォームを `Close` しても、ガベージコレクション（GC）は「まだ誰かに使われている」と判断し、メモリを解放できない。これが「Lapsed Listener（失われたリスナー）」問題、すなわちメモリリークの正体だ。
本記事では、この問題を根本から解決し、保守性と堅牢性を極限まで高めるためのWeakEventManager（弱参照を用いたオブザーバーパターン）の構築手法を伝授する。
なぜ、あなたのコードは「死なない」のか
まず、問題の構造を理解せよ。
通常のイベントハンドラの仕組みは以下のようになっている：
1. `FormB` が `FormA` のイベントを購読する。
2. `FormA.DataChanged += AddressOf FormB.OnDataChanged` と記述する。
3. この瞬間、`FormA` は `FormB` のインスタンスへの強参照（Strong Reference）を保持する。
この状態では、`FormB` を閉じたとしても、`FormA` が生存している限り、`FormB` はメモリ上に残り続ける。大規模な業務システムで、ユーザーが何十回、何百回と画面を開閉すれば、メモリは食いつぶされ、最終的にアプリケーションはクラッシュする。
これを防ぐには、「イベントは通知するが、相手の生存に責任は持たない」という、疎結合かつ弱参照を用いた設計が必要不可欠だ。
実装：WeakMessenger（弱参照型メッセージハブ）
WinFormsでこれを実現するために、WPFの `WeakEventManager` に着想を得た、独自の `WeakMessenger` クラスを実装する。このクラスは、購読者を `WeakReference` として保持するため、購読者が不要になれば、GCによって自然に回収される。
以下に、プロダクションレベルで使用可能な、堅牢な実装例を示す。
1. メッセージのインターフェースと実装
まず、やり取りする「データ」そのものを定義する。
''' <summary>
''' メッセージの基底インターフェース
''' </summary>
Public Interface IMessage
End Interface
''' <summary>
''' 顧客情報を更新するためのメッセージ例
''' </summary>
Public Class CustomerUpdateMessage
Implements IMessage
Public Property CustomerId As Integer
Public Property NewName As String
Public Sub New(id As Integer, name As String)
Implements IMessage
Me.CustomerId = id
Me.NewName = name
End Sub
End Class2. WeakMessenger のコアロジック
ここが設計の心臓部だ。購読者を管理する際、`WeakReference` を用いて、参照のライフサイクルを分離する。
Imports System.Runtime.CompilerServices
''' <summary>
''' 弱参照を用いたメッセージングハブ。
''' 購読者のメモリリークを防ぎつつ、画面間通信を実現する。
''' </summary>
Public Class WeakMessenger
' 内部的な購読情報を保持する構造体
Private Class Subscription
Implements IDisposable
Public Property Target As WeakReference(Of Object)
Public Property Action As Action(Of IMessage)
Public Sub New(target As Object, action As Action(Of IMessage))
Implements New(target, action)
Me.Target = New WeakReference(Of Object)(target)
Me.Action = action
End Sub
Public Sub Dispose() Implements IDisposable.Dispose
Me.Action = Nothing
End Sub
End Class
Private ReadOnly _subscriptions As New List(Of Subscription)
Private ReadOnly _lock As New Object()
''' <summary>
''' メッセージを購読する
''' </summary>
Public Sub Subscribe(Of TMessage As IMessage)(target As Object, handler As Action(Of TMessage))
SyncLock _lock
' 型変換を含めたラッパーを作成
Dim wrapper As Action(Of IMessage) = Function(m) handler(DirectCast(m, TMessage))
_subscriptions.Add(New Subscription(target, wrapper))
End SyncLock
End Sub
''' <summary>
''' メッセージを配信する
''' </summary>
Public Sub Publish(message As IMessage)
Dim toRemove As New List(Of Subscription)
SyncLock _lock
For Each subsc In _subscriptions
' ターゲットがまだ生存しているか確認
Dim targetObj = subsc.Target.Target
If targetObj IsNot Nothing Then
' メッセージを配信
subsc.Action(message)
Else
' ターゲットがGCにより回収済みなら削除対象とする
toRemove.Add(subsc)
End If
Next
' 死んだ参照を一括削除（クリーンアップ）
For Each deadSub In toRemove
_subscriptions.Remove(deadSub)
deadSub.Dispose()
Next
End SyncLock
End Sub
' シングルトンパターン（アプリケーション全体で一つのハブを利用）
Private Shared _instance As WeakMessenger
Public Shared ReadOnly Property Instance As WeakMessenger
Get
If _instance Is Nothing Then _instance = New WeakMessenger()
Return _instance
End Get
End Property
End Class実践：画面間での利用シナリオ
では、この `WeakMessenger` を使って、メイン画面（`MainForm`）と詳細画面（`DetailForm`）の間でデータを同期させる。
DetailForm（データを変更する側）
Public Class DetailForm
Inherits Form
Private Sub btnUpdate_Click(sender As Object, e As EventArgs) Handles btnUpdate.Click
' データの更新をメッセージとして発行
' MessengerはDetailFormへの強い参照を持たないため、
' このフォームを閉じれば、即座にメモリ解放の対象となる。
Dim msg As New CustomerUpdateMessage(101, "株式会社アーキテクト")
WeakMessenger.Instance.Publish(msg)
Me.Close()
End Sub
End ClassMainForm（データを受け取る側）
Public Class MainForm
Inherits Form
Private Sub MainForm_Load(sender As Object, e As EventArgs) Handles MyBase.Load
' メッセージの購読を開始
' 購読側が「強参照」を保持されることはなく、設計がクリーンに保たれる
WeakMessenger.Instance.Subscribe(Of CustomerUpdateMessage)(Me, AddressOf OnCustomerUpdated)
End Sub
Private Sub OnCustomerUpdated(msg As CustomerUpdateMessage)
' UIスレッドへの配慮（重要：別スレッドからのPublishにも対応可能にするため）
If Me.InvokeRequired Then
Me.Invoke(Sub() OnCustomerUpdated(msg))
Return
End If
' データの反映
lblStatus.Text = $"更新完了: ID={msg.CustomerId}, Name={msg.NewName}"
End Sub
Private Sub btnOpenDetail_Click(sender As Object, e As EventArgs) Handles btnOpenDetail.Click
Dim detail As New DetailForm()
detail.Show()
End Sub
End Classプロフェッショナルのための設計指針
この設計を実務に投入する際、リーダーとして以下の3点を徹底させよ。
1. UIスレッドの保護（Thread Safety）
`WeakMessenger.Publish` がバックグラウンドスレッド（ファイルI/OやDBアクセス完了時など）から呼ばれる可能性がある場合、購読側のハンドラ内では必ず `InvokeRequired` によるスレッドチェックを行え。これを怠ると、非決定的なタイミングで `InvalidOperationException` が発生し、バグの特定が極めて困難になる。
2. Single Source of Truth (SSOT) の原則
画面間でのデータ同期は、単なる「UIの表示合わせ」であってはならない。
メッセージを介して同期させるべきは、「状態（State）」である。
- 悪い例: 「テキストボックスの値を送る」
- 良い例: 「データベースの更新が完了したという事実と、更新されたIDを送る」
受信側は、そのIDを元に最新のデータを再取得するか、あるいは信頼できるキャッシュから値を読み取るべきだ。
3. データベース・ファイル連携時のトランザクション
メッセージ駆動型設計では、イベントの連鎖（Event Cascading）が起きやすい。
「Aの更新 → メッセージ発行 → Bが受信 → BがDB更新 → Bがメッセージ発行 → Aが受信…」
このような無限ループや、不整合な状態を防ぐため、メッセージの役割を「通知（Notification）」に限定し、実際の「永続化（Persistence）」の責任範囲を明確に分離せよ。
結論
`AddHandler` は便利だが、それは小規模な、あるいはライフサイクルが明確なオブジェクト間でのみ許される「甘え」だ。
業務アプリケーションという、長時間稼働し、複雑な画面遷移を伴う戦場において、我々エンジニアに求められるのは、オブジェクトの死に際まで管理する規律である。`WeakMessenger` による疎結合な設計を採用することで、メモリリークの恐怖から解放され、真に保守性の高い、堅牢なシステムを構築することが可能になる。
「動く」コードを書くのは初級者だ。「死なない」コードを書くのが、プロフェッショナルである。
