破滅を招く「GC任せ」からの脱却：VB.NETにおける`Using`の真実とアンマネージド資源の鉄則
諸君、現役でVB.NETを扱うエンジニアたちへ。
「GC（ガベージコレクタ）が自動でメモリを回収してくれるから安心だ」――この慢心が、どれほどのシステムを死に至らしめてきたか。
特に、ファイルI/O、データベース接続、あるいはWindows APIを直接叩くようなレガシーな連携システムにおいて、資源管理の甘さは即座に「メモリリーク」「ハンドル枯渇」「アプリケーションのフリーズ」という形で牙を剥く。
今回は、VB.NETの`Using`ステートメントの裏側を暴き、プロフェッショナルとして守るべき資源管理の鉄則を授ける。
—
1. Usingの正体：糖衣構文の裏にある「try-finally」の冷徹な現実
VB.NETの`Using`は、単なる記述の簡略化ではない。それは「例外発生時であっても確実に`Dispose()`を呼ぶ」という約束を、コンパイラが強制的に保証するための防壁だ。
`Using`ブロックを記述すると、コンパイル時に以下のような`try-finally`構造へ変換される。
‘ 開発者が書くコード
Using stream As New FileStream(“data.bin”, FileMode.Open)
‘ 処理
End Using
‘ コンパイラが生成する実体（イメージ）
Dim stream As FileStream = New FileStream(“data.bin”, FileMode.Open)
Try
‘ 処理
Finally
If stream IsNot Nothing Then
DirectCast(stream, IDisposable).Dispose()
End If
End Try
重要なのは、`Finally`ブロックが例外が発生しても必ず実行される点だ。もし`Using`を使わずに手動で`Dispose()`を呼び出すコードを書いていたとして、その途中で例外が発生したら？ そのリソースは永遠に解放されず、GCが回収に来るまで（あるいはプロセスが落ちるまで）メモリに居座り続けることになる。
—
2. Windows APIとアンマネージド資源の闇
特に危ういのは、`DllImport`を使ってWin32 APIを直接叩いている場合だ。メモリ確保に`Marshal.AllocHGlobal`などを使用した際、GCは「そのメモリがどこで使われているか」を完璧には把握できない。
ここで`Using`を活用するために、自作クラスに`IDisposable`を実装するパターンを叩き込んでおけ。
鉄則：Disposeパターンの実装
Public Class NativeResourceManager
Implements IDisposable
‘ アンマネージドハンドル（例：Win32 APIの戻り値）
Private _handle As IntPtr
Public Sub New()
‘ ハンドル確保
_handle = NativeMethods.CreateMyResource()
End Sub
‘ Disposeの実装
Public Sub Dispose() Implements IDisposable.Dispose
Dispose(True)
GC.SuppressFinalize(Me) ‘ ファイナライザの実行を抑制（高速化）
End Sub
Protected Overridable Sub Dispose(disposing As Boolean)
If _handle <> IntPtr.Zero Then
‘ アンマネージド資源の解放
NativeMethods.CloseMyResource(_handle)
_handle = IntPtr.Zero
End If
End Sub
‘ ファイナライザ（念のため）
Protected Overrides Sub Finalize()
Dispose(False)
End Sub
End Class
このように`IDisposable`を実装しておけば、呼び出し側はただ`Using`で囲むだけで、アンマネージド資源の漏洩を完全に封じることができる。これがプロの品質だ。
—
3. なぜ「大域的変数」でリソースを保持してはならないのか
レガシーなシステム改修でよく見るのが、クラスのメンバ変数として`SqlConnection`や`Stream`を持ち続け、使い回す設計だ。これは「リソースの保有期間」と「オブジェクトの生存期間」を混同している典型的な悪手である。
- リソースは「使う直前に確保し、使い終わったら即座に捨てる」のが鉄則。
- 接続プール（Connection Pooling）が正しく機能するのは、`Using`で短期間に接続を開閉するからだ。長期間持ち続けると、接続プールの枯渇を招き、システム全体を低速化させる。
—
4. チーフアーキテクトからの提言：極限の現場で勝つために
- スコープを最小化せよ: `Using`ブロックは可能な限り短く記述しろ。ネストが深くなるのが嫌なら、処理を小さなメソッドに切り出せ。それが保守性の第一歩だ。
- 例外の握り潰しを許すな: `Using`ブロック内での例外を隠蔽すると、リソース解放の成否すら分からなくなる。ログ出力は必須だが、ログ処理自体で例外を投げない堅牢な実装を心がけろ。
- 「とりあえずNew」を卒業せよ: 何でもインスタンス化して保持するのではなく、本当にそのリソースが必要な生存期間を定義せよ。
VB.NETは古臭い言語ではない。正しい作法を知る者にとっては、極めて強力な武器になる。コードの裏側で何が起きているかを想像できないエンジニアに、システムの安定など語らせるな。
君たちの書く一本の`Using`が、今日もどこかのサーバーのメモリリークを未然に防いでいる。その自負を持って、設計にあたれ。
