墓場まで持っていく「リソース管理」の極意：VB.NETでメモリリークを根絶する設計思想
システムが「なぜか数日で重くなる」「突然ファイルがロックされて開けなくなる」。こうした事象は、OSに対する冒涜だ。
VB.NETを扱う諸君。君たちが書いているその `SqlConnection` や `StreamReader` は、ただの変数ではない。OSのリソースを食らう「飢えた獣」であることを自覚しているか？ ガベージコレクション（GC）は万能ではない。君たちが解放をサボれば、OSは悲鳴を上げ、やがてシステムは停止する。
今日は、小手先のテクニックではない。「リソースを制する者がシステムを制する」という、アーキテクチャの根幹を伝授する。
—
1. 勘違いの「Dispose」：なぜ「変数」を信じてはいけないのか
多くの開発者が犯す過ちは、`Dispose` を「いつか誰かがやってくれる」と信じることだ。VB.NETにおいて、`IDisposable` インターフェースを実装したオブジェクトは、スコープを抜けただけでは死なない。GCが回収に来るまで、そのリソースはOS上に居座り続ける。
特にデータベース接続やファイルI/Oは、GCの気まぐれを待つ猶予などない。
敗北するコード（アンチパターン）
‘ 悪い例：例外が発生した瞬間にDisposeが呼ばれず、コネクションが死ぬまで居座る
Dim conn As New SqlConnection(connectionString)
conn.Open()
‘ …処理中に例外発生…
conn.Close() ‘ ここに到達しない
この「解放漏れ」は、数千回繰り返されるバッチ処理の中で確実にシステムを殺す。
—
2. Usingステートメント：スコープによる「強制執行」
`Using` ステートメントは、単なる糖衣構文ではない。これは、「例外が発生しようが何があろうが、このブロックを抜ける瞬間に確実にリソースを屠る（Disposeする）」という、コンパイラへの強い命令だ。
勝利するコード（ベストプラクティス）
‘ 正しい例：Usingによる確実な解放
Using conn As New SqlConnection(connectionString)
conn.Open()
Using cmd As New SqlCommand(“SELECT …”, conn)
Using reader As SqlDataReader = cmd.ExecuteReader()
‘ ここで例外が出ても、Usingは確実にDisposeを呼び出し、
‘ 接続とリーダーをOSへ返却する
While reader.Read()
‘ 処理
End While
End Using
End Using
End Using
ここで重要なのは、「必要最小限のスコープ」に絞ることだ。コネクションを開く時間は、最短にせよ。DB接続を長々と保持する設計は、そもそもアーキテクチャの敗北である。
—
3. シニアのための深掘り：アンマネージドリソースの境界線
時として、APIのラッパーやCOMコンポーネントを扱う際、VB.NETのGCだけでは管理しきれない「真のアンマネージドリソース」に直面する。
`Marshal.ReleaseComObject` が必要になる場面だ。Excelのオートメーションや、古いWin32 APIを直接叩く場合、`Using` だけでは不十分なケースがある。
‘ COMコンポーネント解放の極意
Dim xlApp As Excel.Application = Nothing
Try
xlApp = New Excel.Application()
‘ …処理…
Finally
If xlApp IsNot Nothing Then
‘ 明示的な解放
System.Runtime.InteropServices.Marshal.ReleaseComObject(xlApp)
xlApp = Nothing
‘ GCを強制発動させるのは最終手段だが、レガシー連携では必要悪となることもある
GC.Collect()
GC.WaitForPendingFinalizers()
End If
End Try
※注意：`GC.Collect()` を業務アプリの通常フローに組み込むのは禁じ手だ。あくまで「どうにもならないメモリ断片化」に対する外科手術であることを忘れるな。
—
4. アーキテクトからの提言：設計で見えないリークを潰す
コードの書き方以上に重要なのは、「リソースを保持する時間を最小化する」という設計思想だ。
1. 接続文字列を保持しない: `SqlConnection` をクラスメンバに持たせるな。メソッド内で生成し、その場で破棄しろ。
2. コネクションプールを信じろ: 「接続し直すと遅い」と嘆く者がいるが、現代のADO.NETのコネクションプールは優秀だ。接続を使い回そうとせず、`Using` で生成・破棄を繰り返すのが、最もパフォーマンスが高く、かつ安全である。
3. 例外処理の肥大化を防ぐ: `Try…Catch` の中でリソースを生成し、`Finally` で個別にDisposeを書く必要はない。`Using` を使えば、その冗長なコードはすべて消し去ることができる。
—
結びに代えて
君たちが書く一行のコードが、数年後の保守エンジニアの命を救うかもしれない。あるいは、深夜の障害対応で君自身を苦しめるかもしれない。
`Using` を使いこなすことは、リソースへの敬意を持つことだ。OSという巨大なインフラの上に、自分たちのプログラムを「お邪魔させる」という謙虚な姿勢こそが、最高峰のエンジニアへの第一歩となる。
コードを書け。ただし、そのリソースの寿命を、君自身が完全に支配下に置け。以上だ。
