【実務・中級編】上級プロフェッショナル向け：VB.NETアプリケーションのメモリリーク検出と対策：WinDbgとdotMemoryを用いたマネージド・アンマネージド資源の徹底解析手法 – Visual Basic (VB / VB.NET)解析バイブル

【VB.NETの極意】チーフアーキテクトが暴くメモリリークの深淵：WinDbgとdotMemoryで完全攻略せよ

諸君、開発現場の最前線で日夜奮闘するエンジニアたちよ。私は長年にわたり、Visual Basic、そしてVB.NETの世界で数多のシステムを設計し、その魂を磨き上げてきたチーフアーキテクトだ。今日のテーマは、多くの開発者がその影に怯え、しかし真の解決策を見出せずにいる「メモリリーク」について、だ。

君たちが開発する業務効率化ツールや基幹システムは、単に動けば良いというものではない。長期にわたり安定稼働し、パフォーマンスを維持し続ける「堅牢さ」が求められる。しかし、なぜか時間が経つにつれてシステムが重くなり、最終的には応答しなくなる——そんな経験はないか？それは多くの場合、メモリリークという見えない病魔に蝕まれている証拠だ。

「VB.NETにはガベージコレクタ（GC）があるから、メモリリークは起きないだろう？」そう高を括る者は、いずれ手痛いしっぺ返しを食らうことになる。GCは万能ではない。我々はGCの挙動を理解し、その限界を知り、マネージドとアンマネージドの境界線を掌握しなければならない。

この記事では、表面的な知識では決して到達できない、メモリリーク検出と対策の「極限の知見」を君たちに授けよう。WinDbgとdotMemoryという強力な武器を手に、マネージド・アンマネージド資源の深層を徹底的に解析し、バグの起きない、そして保守性の高いプロダクションコードを構築する術を伝授する。

なぜVB.NETでもメモリリークは起こるのか？GCの光と影

まずは、メモリリークの真の姿を理解することから始めよう。

マネージドメモリリークの正体

VB.NETを含む.NET Framework/.NET Core環境は、ガベージコレクタ（GC）によってメモリ管理の多くを自動化している。これは開発者にとって大きな恩恵だが、同時に「メモリリークはGCが何とかしてくれる」という誤解を生みやすい。

マネージドメモリリークとは、GCルートから参照され続けているため、GCによって回収されないオブジェクトが、実際にはアプリケーションのロジック上はもはや不要であるにも関わらず、メモリ上に残り続けてしまう現象だ。

例えるなら、忘れ去られたにも関わらず、部屋の隅で誰かがまだ「必要だ」と主張し続けるゴミのようなものだ。GCは賢いが、その「必要だ」という主張が論理的な誤りであることまでは見抜けない。

アンマネージドメモリリークの闇

VB.NETアプリケーションといえども、常にマネージドコードだけで完結するわけではない。COMコンポーネントの利用（COM Interop）、Windows APIの呼び出し（P/Invoke）、データベース接続のネイティブドライバなど、アンマネージド（ネイティブ）な資源を利用する場面は多々ある。

これらの資源はGCの管理外だ。ファイルハンドル、ネットワークソケット、データベースコネクション、GDIオブジェクト（ビットマップ、フォントなど）、ネイティブヒープ上のメモリなどは、開発者が明示的に解放しなければ、アプリケーションが終了するまで残り続ける。これがアンマネージドメモリリークだ。

長期稼働システムでは、この二つのリークが複合的に発生し、徐々にシステム資源を枯渇させ、最終的にサービスダウンを引き起こす。この危険性を軽視してはならない。

検出フェーズ：見えない敵を可視化する

メモリリークの検出には、まず「現場」の状況を正確に把握するための情報が必要だ。それがメモリダンプであり、それを解析するためのプロファイリングツールだ。

ステップ1: メモリダンプの取得 – 事件現場の証拠保全

メモリリークが疑われる状況（CPU使用率が高い、メモリ使用量が異常に増加しているなど）で、アプリケーションのメモリ状態をスナップショットとして取得する。これがメモリダンプだ。本番環境で問題を再現させるのは困難なことが多いため、メモリダンプは「動いている現場」の貴重な情報となる。

取得方法：

1. タスクマネージャー: 最も手軽な方法。

• 対象プロセスを右クリック → 「ダンプファイルの作成」
• ただし、これは「ミニダンプ」であり、フルダンプに比べて情報が少ない場合がある。

2. ProcDump: より詳細なダンプ取得や、特定の条件での自動取得に優れる。

• Microsoft Sysinternals Suiteに含まれる高機能なツール。

# プロセスID (PID) を指定してフルダンプを取得
procdump.exe -ma C:\Dumps\MyLeakApp.dmp

# メモリ使用量が一定値を超えた場合にダンプを自動取得（例: 2GBを超えたら）
procdump.exe -ma -m 2048M MyLeakApp.exe C:\Dumps\MyLeakApp_mem_spike.dmp

• `-ma` オプションは、完全なメモリダンプ（Full Dump）を取得するために重要だ。これにより、マネージドヒープ、アンマネージドヒープ、スレッドスタックなど、解析に必要な全ての情報が含まれる。

ダンプ取得の注意点：

• ファイルサイズ: フルダンプは、対象プロセスのメモリ使用量に比例して巨大になる。ディスク容量と転送時間に注意せよ。
• 取得タイミング: リーク発生が疑われる「メモリが増加した時点」と、正常稼働時の「ベースライン」の2つのダンプを取得すると、差分比較が容易になる。

ステップ2: マネージドメモリリークの徹底解析 – dotMemoryの眼

マネージドヒープのリーク解析には、JetBrains dotMemoryが非常に強力だ。これはオブジェクトの参照グラフを視覚化し、GCルートからの参照関係を明確にする点で、WinDbg単体よりも直感的で高速な解析を可能にする。

dotMemoryによる解析アプローチ：

1. スナップショット比較: アプリケーション起動直後と、メモリリークが疑われる時間が経過した後の2つのスナップショットを取得し、差分を比較する。これにより、どのオブジェクトが「新規に増え続けているか」を特定できる。
2. オブジェクトセットの参照パス: 不審なオブジェクトが特定されたら、そのオブジェクトがなぜGCによって回収されないのか、その「参照パス」を辿る。dotMemoryはGCルート（スタティックフィールド、スレッドスタックなど）からの参照パスをツリー構造で表示してくれる。

典型的なマネージドリークパターンと対策：

• イベントハンドラの解除忘れ: これがマネージドメモリリークの最も古典的で、かつ最も頻繁に発生する原因の一つだ。
• ソースオブジェクトがターゲットオブジェクトのイベントを購読すると、ソースはターゲットへの参照を持つ。ターゲットオブジェクトが破棄されるべきタイミングで破棄されない場合、ソースオブジェクトもGCルートからの参照が切れず、メモリ上に残り続ける。
• 特に、寿命の長いオブジェクト（例：フォームやメインウィンドウ）が、寿命の短いオブジェクト（例：一時的なダイアログやコントロール）のイベントを購読し、解除を忘れると発生しやすい。

.net
Public Class LeakyForm
Private WithEvents _myControl As New SomeControl() ‘ SomeControlがイベントを発行すると仮定

Public Sub New()
InitializeComponent()
‘ イベントハンドラを登録
AddHandler _myControl.SomeEvent, AddressOf MyEventHandler
Me.Controls.Add(_myControl)
End Sub

Private Sub MyEventHandler(sender As Object, e As EventArgs)
‘ イベント処理
End Sub

‘ 問題点: LeakyFormが閉じられても、_myControl.SomeEventへの参照が残る可能性がある。
‘ 特に、_myControlがフォームのDispose時に適切にDisposeされない場合や、
‘ フォームからControlコレクションを削除してもイベントハンドラは自動解除されない。

‘ 対策: 明示的なイベントハンドラの解除
Protected Overrides Sub Dispose(disposing As Boolean)
If disposing Then
‘ アンマネージドリソースの解放 (もしあれば)
‘ イベントハンドラの解除を確実に行う
If _myControl IsNot Nothing Then
RemoveHandler _myControl.SomeEvent, AddressOf MyEventHandler
_myControl.Dispose() ‘ コントロール自体もDisposeする
End If
End If
MyBase.Dispose(disposing)
End Sub
End Class

‘ SomeControl の例
Public Class SomeControl
Inherits Control
Public Event SomeEvent As EventHandler

Private _timer As New System.Windows.Forms.Timer()

Public Sub New()
_timer.Interval = 1000
AddHandler _timer.Tick, AddressOf OnTimerTick
_timer.Start()
End Sub

Private Sub OnTimerTick(sender As Object, e As EventArgs)
RaiseEvent SomeEvent(Me, EventArgs.Empty)
End Sub

Protected Overrides Sub Dispose(disposing As Boolean)
If disposing Then
If _timer IsNot Nothing Then
_timer.Stop()
RemoveHandler _timer.Tick, AddressOf OnTimerTick ‘ Timerのイベントも忘れずに解除
_timer.Dispose()
End If
End If
MyBase.Dispose(disposing)
End Sub
End Class

• チーフアーキテクトの助言: `AddHandler` を書いたら、必ず `RemoveHandler` をセットで書く習慣をつけろ。特に、オブジェクトのライフサイクルが異なる場合（例: 親フォームと子フォーム、または一時的なサービスオブジェクト）は要注意だ。`Using` ステートメントが適用できないイベント駆動型パターンでは、`IDisposable` の実装と `Dispose` メソッド内での解除が鉄則だ。

• 静的フィールド: 静的フィールドはアプリケーションドメインがアンロードされるまでGCされず、それに紐づくオブジェクトも解放されない。キャッシュやシングルトンパターンで安易に静的フィールドを使うと、リークの原因となる。

.net
Public Class StaticLeaker
‘ このリストはアプリケーション終了までメモリに残る
Private Shared _dataCache As New List(Of String)()

Public Shared Sub AddData(data As String)
_dataCache.Add(data)
End Sub
End Class

‘ 対策: 適切なキャッシュ機構の利用、または必要に応じてクリアする機構
‘ 例: System.Runtime.Caching.MemoryCache の利用
Imports System.Runtime.Caching

Public Class ManagedCache
Private Shared ReadOnly _cache As MemoryCache = MemoryCache.Default

Public Shared Sub AddOrGet(key As String, value As Object, expirationMinutes As Integer)
Dim cacheItemPolicy As New CacheItemPolicy()
cacheItemPolicy.AbsoluteExpiration = DateTimeOffset.Now.AddMinutes(expirationMinutes)
_cache.Set(key, value, cacheItemPolicy)
End Sub

Public Shared Function Get(key As String) As Object
Return _cache.Get(key)
End Function

Public Shared Sub Remove(key As String)
_cache.Remove(key)
End Sub
End Class

• チーフアーキテクトの助言: 静的フィールドを使う際は、そのライフサイクルと格納するオブジェクトのサイズ、そしてそれが本当にアプリケーション全体で永続的に必要なのかを熟考せよ。安易なグローバル変数はリークの温床だ。

ステップ3: アンマネージドメモリリークの深掘り – WinDbgの鋭いメス

マネージドヒープに異常がないにも関わらずメモリ使用量が増え続ける場合、アンマネージド資源のリークを疑うべきだ。ここで出番となるのが、Windowsデバッグツール群の王者、WinDbgだ。その学習コストは高いが、得られる情報は計り知れない。

WinDbgによる解析アプローチ：

1. SOS.dllのロード: .NETアプリケーションのマネージドヒープを解析するために、`SOS.dll` (Son of Strike) という拡張機能をロードする。

.loadby sos clr ‘ または .loadby sos coreclr (for .NET Core/.NET 5+)

2. マネージドヒープの基本確認:

• `!dumpheap -stat`: マネージドヒープ上のオブジェクトの種類ごとのサイズとカウントを表示。ここで異常に増えているクラスがないか確認する。
• `!gcroot
  `: 特定のオブジェクトがなぜGCされないのか、そのGCルートを表示する。dotMemoryがない場合の代用となる。

3. アンマネージドヒープの確認:

• `!heap -s`: ネイティブヒープの使用状況サマリー。
• `!address -summary`: アドレス空間の割り当て状況。
• `!for_each_heap “!heap -stat -h “`: 個々のネイティブヒープの詳細統計。
• これらのコマンドで、特定のDLLやコンポーネントが不釣り合いな量のネイティブメモリを消費していないかを確認する。

4. ハンドルリークの検出:

• `!handle`: プロセスが所有するカーネルハンドル（ファイル、レジストリキー、イベント、ミューテックスなど）のリストを表示する。
• 特に、`!handle ` で特定のタイプ（例: `!handle File`）をフィルタリングし、時間が経つにつれて特定のハンドルが増え続けていないかを確認する。

5. GDI/USERオブジェクトリークの検出:

• `!gdi`: プロセスが使用しているGDIオブジェクト（ビットマップ、ペン、ブラシ、フォントなど）の数を表示。特にGUIアプリケーションで重要。
• `!cs`: USERオブジェクト（ウィンドウ、メニュー、カーソルなど）の数を表示。
• これらのオブジェクトは、上限に達するとアプリケーションがクラッシュしたり、描画がおかしくなったりする。

典型的なアンマネージドリークパターンと対策：

• P/InvokeやCOM Interopでの資源解放忘れ: Windows APIやCOMコンポーネントから取得したハンドルやポインタは、必ず明示的に解放しなければならない。
• `IntPtr` で受け取ったハンドルは `CloseHandle` や `ReleaseDC` など、対応するAPIで解放する。
• COMオブジェクトは `System.Runtime.InteropServices.Marshal.ReleaseComObject` で参照カウントを減らす。

.net
Imports System.Runtime.InteropServices

Public Class NativeResourceLeaker
‘ GDIオブジェクトの代表例: Device Context (DC)
Private Declare Function GetDC Lib “user32” (ByVal hwnd As IntPtr) As IntPtr
Private Declare Function ReleaseDC Lib “user32” (ByVal hwnd As IntPtr, ByVal hdc As IntPtr) As Integer

‘ ファイルハンドル (CreateFileの戻り値など)
Private Declare Function CreateFile Lib “kernel32” Alias “CreateFileA” ( _
ByVal lpFileName As String, _
ByVal dwDesiredAccess As UInteger, _
ByVal dwShareMode As UInteger, _
ByVal lpSecurityAttributes As IntPtr, _
ByVal dwCreationDisposition As UInteger, _
ByVal dwFlagsAndAttributes As UInteger, _
ByVal hTemplateFile As IntPtr _
) As IntPtr
Private Declare Function CloseHandle Lib “kernel32” (ByVal hObject As IntPtr) As Boolean

‘ アンマネージドリソースを保持するフィールド
Private _hDeviceContext As IntPtr = IntPtr.Zero
Private _hSomeFile As IntPtr = IntPtr.Zero

Public Sub AcquireResources(hwnd As IntPtr, filePath As String)
‘ Device Contextを取得 (必ず解放が必要)
_hDeviceContext = GetDC(hwnd)
If _hDeviceContext = IntPtr.Zero Then
Throw New InvalidOperationException(“Failed to get device context.”)
End If

‘ ファイルハンドルを取得 (必ず解放が必要)
_hSomeFile = CreateFile(filePath, &H40000000, &H1, IntPtr.Zero, &H2, &H80, IntPtr.Zero) ‘ GENERIC_WRITE, FILE_SHARE_READ, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL
If _hSomeFile = CType(-1, IntPtr) Then ‘ INVALID_HANDLE_VALUE
Throw New InvalidOperationException(“Failed to create file handle.”)
End If
End Sub

‘ 問題点: AcquireResourcesを呼び出した後、明示的に解放しないとリークする

‘ 対策: IDisposableインターフェースを実装し、Usingステートメントで確実に解放
Public Sub ReleaseResources()
If _hDeviceContext <> IntPtr.Zero Then
ReleaseDC(IntPtr.Zero, _hDeviceContext) ‘ 第一引数はGetDCで使ったHWNDに合わせる
_hDeviceContext = IntPtr.Zero
End If

If _hSomeFile <> CType(-1, IntPtr) AndAlso _hSomeFile <> IntPtr.Zero Then ‘ INVALID_HANDLE_VALUE
CloseHandle(_hSomeFile)
_hSomeFile = IntPtr.Zero
End If
End Sub

‘ IDisposable実装 (後述のIDisposableパターンで詳細解説)
End Class

• チーフアーキテクトの助言: WinDbgは強力だが、その解析は時間を要する。しかし、ネイティブヒープの挙動や、特定のDLLがどれだけメモリを消費しているかを詳細に知るには不可欠だ。COMオブジェクトを扱う際は、常に `ReleaseComObject` を念頭に置け。そして、`IntPtr` を受け取るAPIを呼んだら、その解放APIもセットで探すのがプロの仕事だ。

対策フェーズ：堅牢な設計とコーディングプラクティス

検出したリークの原因を特定したら、次はそれを二度と発生させないための設計と実装が求められる。

IDisposableパターンと`Using`ステートメントの徹底

アンマネージド資源を扱うクラス、あるいは比較的大きなマネージド資源（例: 大規模なデータセット、ファイルストリームなど）を内部に持つクラスは、必ず `IDisposable` インターフェースを実装し、不要になった時点で `Dispose` メソッドを呼び出す規約を確立すべきだ。

.net
Imports System.Runtime.InteropServices

Public Class MyResourceWrapper
Implements IDisposable

‘ アンマネージド資源の例: ファイルハンドル
Private _fileHandle As SafeFileHandle ‘ SafeHandleを推奨

‘ マネージド資源の例: 大規模なリスト
Private _largeList As List(Of Byte)

‘ コンストラクタ
Public Sub New(filePath As String)
‘ アンマネージド資源の取得
‘ SafeHandleは自動的にCloseHandleを呼び出すため、より安全
_fileHandle = CreateFileAsSafeHandle(filePath, &H40000000, &H1, IntPtr.Zero, &H2, &H80, IntPtr.Zero) ‘ GENERIC_WRITE, FILE_SHARE_READ, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL

‘ マネージド資源の初期化
_largeList = New List(Of Byte)(1024 1024 10) ‘ 10MBのリスト
End Sub

‘ CreateFile APIのP/Invoke (SafeHandle対応版)

Private Shared Function CreateFileAsSafeHandle( _
ByVal lpFileName As String, _
ByVal dwDesiredAccess As UInteger, _
ByVal dwShareMode As UInteger, _
ByVal lpSecurityAttributes As IntPtr, _
ByVal dwCreationDisposition As UInteger, _
ByVal dwFlagsAndAttributes As UInteger, _
ByVal hTemplateFile As IntPtr _
) As SafeFileHandle
End Function

‘ IDisposableインターフェースの実装
Region “IDisposable Support”
Private disposedValue As Boolean ‘ 重複呼び出しを検出するためのフラグ

Protected Overridable Sub Dispose(disposing As Boolean)
If Not Me.disposedValue Then
If disposing Then
‘ TODO: ここにマネージド状態を破棄するコードを記述します。
‘ マネージド資源を解放
If _largeList IsNot Nothing Then
_largeList.Clear()
_largeList = Nothing
End If

‘ イベントハンドラの解除などもここで行う
End If

‘ TODO: ここにアンマネージド リソースを解放するコードを記述します。
‘ アンマネージド資源を解放
If _fileHandle IsNot Nothing AndAlso Not _fileHandle.IsClosed Then
_fileHandle.Dispose() ‘ SafeHandleは内部でCloseHandleを呼び出す
End If

Me.disposedValue = True
End If
End Sub

‘ TODO: 上の Dispose(disposing As Boolean) にアンマネージド リソースを解放するコードのみが含まれる場合に、ファイナライザーをオーバーライドします。
‘ Finalize メソッドは、アンマネージド資源のみを解放する場合に利用する。
‘ GCがいつ呼び出すか不明であり、パフォーマンスコストも高い。
‘ IDisposableを適切に実装していれば、ほとんどの場合不要。
‘Protected Overrides Sub Finalize()
‘ ‘ このコードを変更しないでください。クリーンアップ コードを Dispose(disposing As Boolean) に記述します。
‘ Dispose(False)
‘ MyBase.Finalize()
‘End Sub

‘ このコードを共有して、破棄パターンを実装します。
Public Sub Dispose() Implements IDisposable.Dispose
‘ このコードを変更しないでください。クリーンアップ コードを Dispose(disposing As Boolean) に記述します。
Dispose(True)
GC.SuppressFinalize(Me) ‘ ファイナライザーが実行されないようにGCに指示
End Sub
End Region

End Class

そして、この `IDisposable` を実装したクラスのインスタンスを使用する際は、必ず `Using` ステートメントを使用する。

.net
Public Sub UseResource()
Dim filePath As String = “C:\temp\mydata.bin”
Using myResource As New MyResourceWrapper(filePath)
‘ myResourceを使った処理
‘ 例: myResource._largeList.Add(123)
Console.WriteLine(“Resource is in use.”)
End Using ‘ ここで自動的に myResource.Dispose() が呼ばれる

Console.WriteLine(“Resource has been disposed.”)
End Sub

• チーフアーキテクトの助言: `Using` ステートメントは、リソース解放のベストプラクティスだ。どんな例外が発生しても、確実に `Dispose` メソッドが呼び出される。アンマネージド資源をP/Invokeで直接扱う場合は、`IntPtr` ではなく `SafeHandle` 派生クラスを使うことを強く推奨する。`SafeHandle` はファイナライザーを内部に持ち、開発者が `Dispose` を呼び忘れても、GCが最終的に安全にハンドルを解放してくれる。

ファイル・データベース連携の堅牢化

業務システムにおいて、ファイルやデータベースとの連携は避けて通れない。これらの外部リソースもまた、アンマネージド資源と同様に、適切な解放が不可欠だ。

.net
‘ ファイル読み書きの例
Public Sub ProcessFile(filePath As String)
Try
‘ ファイル読み込み
Using reader As New StreamReader(filePath)
Dim line As String
Do
line = reader.ReadLine()
If line Is Nothing Then Exit Do
Console.WriteLine($”Read: {line}”)
‘ 読み込んだデータを処理…
Loop
End Using ‘ reader.Dispose() が自動的に呼ばれ、ファイルハンドルが閉じられる

‘ ファイル書き込み
Using writer As New StreamWriter(filePath & “.out”)
writer.WriteLine(“Processed data output.”)
‘ データを書き込む…
End Using ‘ writer.Dispose() が自動的に呼ばれ、ファイルハンドルが閉じられる

Catch ex As Exception
Console.WriteLine($”ファイル処理中にエラーが発生しました: {ex.Message}”)
End Try
End Sub

‘ データベース連携の例
Imports System.Data.SqlClient ‘ または Npgsql, MySql.Data など

Public Sub AccessDatabase(connectionString As String, customerId As Integer)
Try
Using connection As New SqlConnection(connectionString)
connection.Open()

Dim sql As String = “SELECT CustomerName, Email FROM Customers WHERE CustomerId = @CustomerId”
Using command As New SqlCommand(sql, connection)
command.Parameters.AddWithValue(“@CustomerId”, customerId)

Using reader As SqlDataReader = command.ExecuteReader()
If reader.Read() Then
Console.WriteLine($”Customer: {reader(“CustomerName”)}, Email: {reader(“Email”)}”)
Else
Console.WriteLine(“Customer not found.”)
End If
End Using ‘ reader.Dispose() が自動的に呼ばれる
End Using ‘ command.Dispose() が自動的に呼ばれる
End Using ‘ connection.Dispose() が自動的に呼ばれ、データベースコネクションが閉じられる

Catch ex As Exception
Console.WriteLine($”データベース処理中にエラーが発生しました: {ex.Message}”)
End Try
End Sub

• チーフアーキテクトの助言: ストリーム、コネクション、コマンド、データリーダーといったリソースは、全て `IDisposable` を実装している。そのため、迷わず `Using` ステートメントで囲むこと。これにより、どんなに複雑なロジックや予期せぬエラーが発生しても、確実にリソースが解放される。これが堅牢なシステム設計の基本中の基本だ。

その他の対策：WeakReferenceの活用

特定のキャッシュシナリオなど、オブジェクトがGCルートから参照され続けていても、メモリが逼迫したらGCに回収してほしい、という要求があるかもしれない。このような場合に `WeakReference` が役立つ。

`WeakReference` は、オブジェクトへの「弱い参照」を提供する。GCは弱い参照を持つオブジェクトを、他の強い参照がなければ回収することができる。

.net
Public Class ObjectCache
‘ キーと弱い参照のディクショナリ
Private Shared _cache As New Dictionary(Of String, WeakReference(Of Object))()
Private Shared ReadOnly _lock As New Object()

Public Shared Sub AddOrUpdate(key As String, value As Object)
SyncLock _lock
_cache(key) = New WeakReference(Of Object)(value)
End SyncLock
End Sub

Public Shared Function Get(key As String) As Object
SyncLock _lock
If _cache.ContainsKey(key) Then
Dim weakRef As WeakReference(Of Object) = _cache(key)
Dim target As Object = Nothing
If weakRef.TryGetTarget(target) Then
Return target ‘ オブジェクトはまだ生きている
Else
‘ オブジェクトはGCによって回収された
_cache.Remove(key) ‘ 無効なエントリを削除
Return Nothing
End If
End If
Return Nothing
End SyncLock
End Function

Public Shared Sub CleanUp()
SyncLock _lock
Dim keysToRemove As New List(Of String)()
For Each kvp In _cache
Dim target As Object = Nothing
If Not kvp.Value.TryGetTarget(target) Then
keysToRemove.Add(kvp.Key)
End If
Next
For Each key In keysToRemove
_cache.Remove(key)
Next
End SyncLock
End Sub
End Class

‘ 使用例
Public Sub UseCache()
ObjectCache.AddOrUpdate(“LargeData”, New Byte(1024 1024 – 1) {}) ‘ 1MBのデータ
Dim data As Byte() = DirectCast(ObjectCache.Get(“LargeData”), Byte())
If data IsNot Nothing Then
Console.WriteLine($”データはまだキャッシュにあります。サイズ: {data.Length}”)
Else
Console.WriteLine(“データはGCによって回収されました。”)
End If

‘ GCを強制実行 (テスト目的。通常は推奨されない)
GC.Collect()
GC.WaitForPendingFinalizers()

data = DirectCast(ObjectCache.Get(“LargeData”), Byte())
If data IsNot Nothing Then
Console.WriteLine($”データはまだキャッシュにあります。サイズ: {data.Length}”)
Else
Console.WriteLine(“データはGCによって回収されました。”)
End If
End Sub

• チーフアーキテクトの助言: `WeakReference` は特殊なケースで非常に有効だが、その利用は慎重に。オブジェクトがいつでも回収されうる、という特性を理解し、`TryGetTarget` でnullチェックを怠るな。安易な乱用は、かえってコードの複雑性を増し、デバッグを困難にする。

結論：知識とツール、そして規律が君を最強にする

諸君、メモリリークは単なるバグではない。それは、システム設計と実装における「規律」の欠如が引き起こす、致命的な設計不良だ。しかし、恐れる必要はない。今日、君たちはその深淵を覗き込み、対抗するための強力な武器と知見を手に入れた。

• GCの限界を理解せよ: マネージドメモリリークは、GCルートからの不要な参照が原因だ。
• アンマネージド資源に目を光らせよ: P/InvokeやCOM Interopを使う際は、必ず解放の責任を負うこと。
• ダンプ取得とプロファイリングをマスターせよ: WinDbgとdotMemoryは、見えないリークを可視化する君の眼となる。
• `IDisposable`と`Using`を徹底せよ: 資源の確実な解放は、堅牢なシステムの基盤だ。
• コードレビューでリークパターンを見抜け: イベントハンドラ、静的フィールド、アンマネージド資源の扱いには、常に細心の注意を払え。

この知識とツール、そして日々のコーディングにおける規律こそが、君たちのシステムを真に堅牢にし、長期にわたる安定稼働を保証する。メモリリークとの戦いは、開発者としての君たちの真価が問われる試練だ。この極限の知見を胸に刻み、君たちのシステムをさらに高みへと引き上げてくれ。未来の伝説は、君たちの手の中にある。