墓穴を掘るな：VB.NETにおける厳格なDisposableパターンとガベージコレクションの真実
レガシーシステムの近代化、あるいは長く稼働し続ける業務アプリケーションの保守において、最も恐ろしい敵は何だと思うか？
それは「メモリリーク」であり、さらに言えば「アンマネージドリソースの解放漏れ」だ。
VB.NET（および共通言語ランタイム：CLR）は非常に優秀だ。マネージドメモリの管理はガベージコレクター（GC）が自動で行ってくれる。そのため、初学者や場当たり的なコーディングを行うプログラマは、「VB.NETだからメモリ管理はしなくていい」という致命的な幻想を抱きがちだ。
しかし、考えてみてほしい。Win32 APIのハンドル、GDI+のデバイスコンテキスト（HDC）、あるいはCOMオブジェクト（ExcelやWordのオートメーション、生のアクティブXコンポーネント）は、CLRの管理外にあるアンマネージドリソースだ。これらはGCの慈悲深い回収リストには載らない。あなたが明示的に「捨てろ」と命令しなければ、OSのリソースを食いつぶし続け、やがてアプリケーションはOutOfMemoryExceptionを吐くか、システム全体のフリーズを引き起こす。
今回は、VB.NETのWindows Formsアプリケーション開発および業務システム連携において、アンマネージドリソースを完全に掌握し、確実かつ安全に解放するための「真のDisposableパターン」を解説する。
—
1. ガベージコレクションの限界とFinalizeの罠
まず、大前提として知っておくべきことがある。オブジェクトが破棄される際、GCは`Finalize`メソッド（VB.NETでは `Protected Overrides Sub Finalize()`）を呼び出す。これが俗に言う「デストラクタ」に相当するものだ。
しかし、プロフェッショナルであれば、ビジネスロジックの中で`Finalize`に頼ってリソースを解放してはならないことを知っているはずだ。
- 実行タイミングの不確実性: `Finalize`がいつ実行されるかはGCの気まぐれであり、予測不能である。リソースが枯渇寸前になっても呼ばれないことが多々ある。
- ファイナライゼーションの負荷: `Finalize`を持つオブジェクトは、GCの世代管理において生存期間が引き延ばされ、メモリ回収のオーバーヘッドが劇的に増大する。
したがって、`Finalize`はあくまで「プログラマが明示的な解放を忘れたときの最終防衛ライン（セーフティネット）」としてのみ機能させるべきなのだ。
—
2. 実装すべき「完全版」Disposableパターン
VB.NETでアンマネージド・リソースを安全に管理するための標準かつ唯一無二の正解が、IDisposableインターフェースを実装した決定版パターンである。
以下のコードは、Win32 APIのハンドル（例としてダミーの外部リソースとする）を安全にラップし、マネージド／アンマネージドリソースを完璧に制御するクラスの実装例だ。現場でそのまま応用してほしい。
Imports System
Imports System.Runtime.InteropServices
”’
”’
Public Class NativeResourceWrapper
Implements IDisposable
‘ アンマネージドリソース（例：Win32 APIのハンドル）
Private _nativeHandle As IntPtr = IntPtr.Zero
‘ マネージドリソース（このクラス内で保持する他のIDisposableオブジェクト等）
Private _managedStream As System.IO.MemoryStream = Nothing
‘ すでにDisposeが呼ばれたかを示すフラグ（二重解放の防止）
Private _disposed As Boolean = False
Public Sub New(ByVal handleValue As IntPtr)
Me._nativeHandle = handleValue
Me._managedStream = New System.IO.MemoryStream()
End Sub
”’
”’
Public Sub Dispose() Implements IDisposable.Dispose
‘ 1. 実際の解放処理を実行する
Dispose(True)
‘ 2. ガベージコレクタに対して、ファイナライザの実行をスキップするよう要求する
‘ （すでに明示的に解放したため、Finalizeを走らせる必要がない＝パフォーマンス向上）
GC.SuppressFinalize(Me)
End Sub
”’
”’
”’
”’ True: パブリックなDisposeから呼ばれた（マネージド・アンマネージド両方を解放）
”’ False: ファイナライザから呼ばれた（アンマネージドのみ解放可能）
”’
Protected Overridable Sub Dispose(ByVal disposing As Boolean)
If Not Me._disposed Then
If disposing Then
‘ — 【マネージドリソースの解放】 —
‘ 他のIDisposable実装オブジェクトはここで安全にDisposeする
If _managedStream IsNot Nothing Then
_managedStream.Dispose()
_managedStream = Nothing
End If
End If
‘ — 【アンマネージドリソースの解放】 —
‘ disposingの値に関わらず、ネイティブハンドルが有効であれば必ず解放する
If _nativeHandle <> IntPtr.Zero Then
‘ 例: Win32 APIのハンドル解放関数を呼ぶ想定
‘ CloseHandle(_nativeHandle)
_nativeHandle = IntPtr.Zero
End If
Me._disposed = True
End If
End Sub
”’
”’
Protected Overrides Sub Finalize()
Try
‘ disposingにFalseを指定して呼び出し（マネージド側には触れないこと！）
Dispose(False)
Finally
MyBase.Finalize()
End Try
End Sub
”’
”’
Private Sub CheckDisposed()
If _disposed Then
Throw New ObjectDisposedException(Me.GetType().FullName)
End If
End Sub
‘ サンプル用メソッド
Public Sub DoSomething()
CheckDisposed()
‘ 処理を記述
End Sub
End Class
このコードの急所（Architect’s Notes）
1. `Dispose(Boolean disposing)` の分離:
ファイナライザ（`Finalize`）から呼ばれた場合（`disposing = False`）、マネージドオブジェクト（`_managedStream`など）に触れてはならない。なぜなら、GCの回収順序は保証されておらず、すでに他のマネージドオブジェクトがファイナライズされている可能性があるからだ。 触ればNullReferenceExceptionや致命的なメモリ破壊を引き起こす。
2. `GC.SuppressFinalize(Me)` の絶対性:
明示的に `Dispose()` が呼ばれた際、このメソッドを呼ぶことでGCのファイナライザキューから自身を外し、オブジェクトの寿命を不必要に引き延ばすことを防ぐ。これがパフォーマンス最適化の鍵となる。
—
3. Windows FormsおよびCOM相互運用における実践的テクニック
業務システムでは、Windows Formsのコントロールや、Excel / Word等のCOMオブジェクトを扱う機会がいまだに多い。これらにおける具体的なリソースリーク対策を見ていこう。
Usingブロックの強制（Using Statement）
VB.NETの `Using` ステートメントは、スコープを抜けた瞬間に自動的に `Dispose()` を呼び出してくれる優れた糖衣構文だ。例外が発生しようとも確実にリソースが解放される。
‘ 正しい使い方：スコープアウトと同時に確実なクリーンアップが行われる
Using wrapper As New NativeResourceWrapper(GetSomeHandle())
wrapper.DoSomething()
‘ 業務ロジック…
End Using ‘ ここで自動的に wrapper.Dispose() が走る
レガシーCOMオブジェクト（Excel操作等）の呪縛
VB.NETから `Microsoft.Office.Interop.Excel` を操作する際、変数チェーンで記述すると、背後で無数のCOM RCW（Runtime Callable Wrapper）が生成され、プロセス（Excel.exe）がタスクマネージャーに残留し続けるという悪名高いバグを引き起こす。
これを防ぐには、参照を細かく変数に切り、個別に解放するか、あるいはMarshalクラスを用いて明示的に参照カウントを落とす必要がある。
Dim xlApp As Object = Nothing
Dim xlBooks As Object = Nothing
Dim xlBook As Object = Nothing
Try
xlApp = CreateObject(“Excel.Application”)
xlBooks = xlApp.Workbooks
xlBook = xlBooks.Open(“C:\Work\Data.xlsx”)
‘ — 処理 —
Finally
‘ 逆順かつ確実に解放する
If xlBook IsNot Nothing Then
System.Runtime.InteropServices.Marshal.ReleaseComObject(xlBook)
xlBook = Nothing
End If
If xlBooks IsNot Nothing Then
System.Runtime.InteropServices.Marshal.ReleaseComObject(xlBooks)
xlBooks = Nothing
End If
If xlApp IsNot Nothing Then
xlApp.Quit()
System.Runtime.InteropServices.Marshal.ReleaseComObject(xlApp)
xlApp = Nothing
End If
‘ ガベージコレクションを促す（COM解放の決定打）
GC.Collect()
GC.WaitForPendingFinalizers()
End Try
レガシーなCOM連携において、`Marshal.ReleaseComObject` と `GC.Collect()` のコンボは、ゾンビプロセスを根絶やしにするための必須儀式である。
—
総括：プロフェッショナルとしての誇り
「動けばいい」というコードは、プロトタイプや個人の趣味の範疇でしか通用しない。長期間稼働する社内システム、24時間止まらない業務アプリケーションの設計において、リソース管理の甘さはシステム全体の信頼性を根底から揺るがす致命傷となる。
VB.NETは古い言語だと言われることもある。しかし、その言語仕様の奥底にある仕組み――マネージドとアンマネージドの境界線を正確に理解し、コントロールする者にとって、これほど信頼できるツールはない。
あなたの書くコードは、OSのリソースを正しく敬い、適切に解放しているか？
今一度、プロジェクト内の `IDisposable` 実装を見直し、完璧なライフサイクル管理を構築してほしい。
