亡霊を葬る技術：VB.NETにおけるメモリリークの深淵と「極限の解析術」
VB.NETで組まれた常駐型アプリケーションや、長期間稼働するバッチ処理において、「徐々にメモリを食い潰し、数日後に沈黙する」という現象に頭を抱えたことはないか。
ガベージコレクション（GC）は銀の弾丸ではない。特に、Win32 APIを多用するレガシー・ラッパーや、COM相互運用（Interop）を含むコードは、マネージドの領域外で死の影を落とす。今日は、伝説的なアーキテクトが現場で叩き込んできた、メモリリークの「特定」と「抹殺」の作法を伝授する。
—
1. 敵はどこに潜むか：マネージド対アンマネージド
VB.NETのメモリリークの犯人は、大きく分けて2種類だ。
1. マネージドリーク: 参照の連鎖（Event Handlerの解除漏れ、静的コレクションへの無制限な追加）。
2. アンマネージドリーク: `Marshal.AllocHGlobal`の解放忘れ、またはCOMオブジェクトの解放不全。
特に後者はGCの管理外だ。`.NET`のメモリ使用量監視だけで安心していると、裏でハンドルが枯渇し、システムは死ぬ。
—
2. 実戦的解析ツール：WinDbgとdotMemoryの使い分け
メモリリークが疑われる際、IDEのデバッガを眺めるのは素人のやり方だ。本物は「死体（ダンプファイル）」から真相を読み解く。
A. dotMemoryによる「生存者」の特定
まずはJetBrainsの dotMemory で「世代を超えて生き残っているオブジェクト」を追う。
- 手法: アプリを実行し、メモリ負荷をかけた前後でスナップショットを撮る。
- 注目点: 「Difference」ビューで、解放されるはずのオブジェクト（Formや特定のDTO）のカウントが増え続けていないかを確認せよ。
B. WinDbgによる「アンマネージドの深層」
dotMemoryで解決できない場合、WinDbgの出番だ。
1. `procdump -ma
2. `!eeheap -gc` でマネージドヒープの断片化状況を確認。
3. `!handle` を実行し、ハンドルのリークがないか監視。もしハンドルが異常に増加していれば、それはWin32 APIの戻り値を適切に破棄できていない証拠だ。
—
3. コードレベルでの「最適化の極み」
VB.NETにおいて、リソース解放を曖昧にするのは罪だ。以下のパターンを徹底せよ。
パターン1：IDisposableの連鎖を断ち切る
`IDisposable`を実装したクラスを扱う際、`Using`ステートメントを怠る者は去れ。
‘ 悪い例：解放が例外発生時に保証されない
Dim fs As New FileStream(“log.txt”, FileMode.Open)
‘ …処理…
fs.Dispose()
‘ 良い例：Usingによるスコープ内での確実な解放
Using fs As New FileStream(“log.txt”, FileMode.Open)
‘ IDisposableを実装したオブジェクトは必ずUsingに閉じ込める
‘ 例外が発生しようとも、Finallyブロックがメモリを確実に解放する
End Using
パターン2：COM/API呼び出しの明示的解放
Excel操作やWindows API経由のハンドル操作は、`Marshal.ReleaseComObject`が必須だ。
Imports System.Runtime.InteropServices
Public Sub SafeRelease(ByRef obj As Object)
Try
If obj IsNot Nothing AndAlso Marshal.IsComObject(obj) Then
‘ 参照カウントを強制的に減らす
Do While Marshal.ReleaseComObject(obj) > 0
Loop
End If
Catch ex As Exception
‘ ログ出力のみに留める
Finally
obj = Nothing
End Try
End Sub
—
4. 伝説のアーキテクトからの提言：設計指針
メモリリークを「デバッグで直す」のは下策だ。設計で防げ。
1. イベントハンドラの解除を徹底せよ:
長寿命のオブジェクト（静的クラスなど）に、短寿命のオブジェクト（Form等）のイベントを購読させるな。購読させたなら、必ず`RemoveHandler`でデタッチせよ。これが最大かつ最も多いリーク源だ。
2. 大規模なコレクションは`Clear()`だけでは不十分:
`List(Of T)`を多用する場合、`Clear()`しても内部配列のサイズは保持される。極端なメモリ逼迫時は、`List = Nothing`にするか、`Capacity`を0にリセットせよ。
3. Finalizer（デストラクタ）を過信するな:
`Finalize`メソッドはGCのコストを跳ね上げる。アンマネージド資源以外には絶対に使用するな。
—
結びに：安定こそが正義
業務システムにおいて、機能の多寡よりも「止まらないこと」がエンジニアの評価に直結する。メモリリークはアプリケーションの「不整脈」だ。小さな違和感を見逃さず、WinDbgでダンプの鼓動を読み解く。
ツールはただの道具に過ぎない。重要なのは、オブジェクトのライフサイクルを制御下に置くという、エンジニアとしての執念である。
さあ、あなたのコードに潜む亡霊を、今すぐ見つけ出し、葬り去れ。
