VB.NETを掌握する極限の知見：Stack(Of T) と Queue(Of T) によるメモリ効率的かつ堅牢な業務処理アーキテクチャ
レガシーなVB6/VBAの地平から、モダンな.NET Runtime（.NET 8等）の領域まで、我々は数々の業務システムを構築・保守してきた。
その中で、配列(`Array`)や単純な `List(Of T)` だけをこねくり回し、メモリ断片化やパフォーマンス劣化、果てはスレッド競合の泥沼にハマっているコードベースをどれほど見てきたことか。
「元に戻す（Undo）」機能や、厳密な順序性が求められる「非同期タスク処理」。これらを実装する際、場当たり的なフラグ管理やインデックス操作で凌ぐのは、プロではなく「ただ動かしているだけの作業者」の所業だ。
今回は、VB.NETの中級者からシニアへステップアップするための必須教養として、`Stack(Of T)`（LIFO） と `Queue(Of T)`（FIFO） の内部構造、メモリ最適化、そして業務システムにおける極限の活用パターンを叩き込む。
—
1. 基礎的アーキテクチャの再確認：なぜ `List(Of T)` ではダメなのか？
多くの開発者は、データの蓄積に `List(Of T)` を使い、末尾の削除に `RemoveAt(list.Count – 1)` を使ったり、先頭の処理に `RemoveAt(0)` を使ったりする。
今すぐその実装を止めよ。
- `Stack(Of T)` (LIFO: Last-In, First-Out)
- 後入れ先出し。最後に積まれたものが最初に処理される。
- 内部的には配列 (`T[]`) を保持し、ポインタ（インデックス）を上下させるだけである。
- `Push` も `Pop` も、償却計算量（Amortized Time Complexity）は $O(1)$。
- `Queue(Of T)` (FIFO: First-In, First-Out)
- 先入れ先出し。最初に入ったものが最初に処理される。
- 循環配列（Circular Buffer）構造を持ち、先頭・末尾のポインタを移動させる。
- `Enqueue` も `Dequeue` も、計算量は $O(1)$。
`List(Of T)` の先頭要素を `RemoveAt(0)` で削除した瞬間、裏では全要素のメモリコピー（Array.Copy）が走る。数万件のデータを扱うバッチ処理や高頻度なUI操作において、これがどれほどのガベージコレクション（GC）負荷とCPUサイクルの無駄を生むか、想像に難くないはずだ。
—
2. 業務活用パターン①：`Stack(Of T)` による堅牢な「元に戻す（Undo）」実装
業務アプリケーションにおいて、複雑な入力フォームやドキュメントエディタの「Undo/Redo」は必須要件だ。
ここで重要なのは、メモリ消費量とオブジェクトのライフサイクル管理である。特にVB.NETのデスクトップアプリ（Windows Forms / WPF）では、巨大なデータ構造全体をスタックに積むと、瞬く間にメモリリークやOOM（Out Of Memory）を引き起こす。
以下のコードは、差分（Mementoパターン）を効率的にスタックで管理し、メモリプレッシャーを最小限に抑える実装例である。
Imports System.Collections.Generic
Namespace Enterprise.Patterns
‘ 状態変化をカプセル化するスナップショット（イミュータブル設計）
Public NotInheritable Class FormStateMemento
Public ReadOnly Property TargetId As String
Public ReadOnly Property Value As String
Public ReadOnly Property Timestamp As DateTime
Public Sub New(id As String, val As String)
TargetId = id
Value = val
Timestamp = DateTime.UtcNow
End Sub
End Class
‘ Undo/Redo マネージャー
Public Class UndoRedoManager(Of T)
Private ReadOnly _undoStack As New Stack(Of T)()
Private ReadOnly _redoStack As New Stack(Of T)()
Private ReadOnly _capacity As Integer
‘ コンストラクタで最大保持数を制限し、メモリ枯渇を防ぐ
Public Sub New(Optional capacity As Integer = 50)
_capacity = capacity
End Sub
‘ 状態の記録（ユーザー操作時）
Public Sub PushState(state As T)
_undoStack.Push(state)
‘ 新規操作が入ったらRedoスタックはクリアする（標準的な挙動）
_redoStack.Clear()
‘ キャパシティを超えた場合のメモリ最適化
‘ Stack(Of T)には容量制限の直接的機能がないため、溢れた場合は再構築が必要だが、
‘ 実務上は上限に達したら底を捨てる仕組み（カスタムコレクション）を検討すべき。
If _undoStack.Count > _capacity Then
TrimStack()
End If
End Sub
‘ Undo実行
Public Function Undo(currentState As T) As T
If _undoStack.Count = 0 Then Return Nothing
_redoStack.Push(currentState)
Return _undoStack.Pop()
End Function
‘ Redo実行
Public Function Redo(currentState As T) As T
If _redoStack.Count = 0 Then Return Nothing
_undoStack.Push(currentState)
Return _redoStack.Pop()
End Function
‘ スタック底面トリミングの極意（メモリの省力化）
Private Sub TrimStack()
‘ Stackは底面を直接操作できないため、配列に落として再構築する
Dim tempArray = _undoStack.ToArray()
_undoStack.Clear()
‘ 新しい順に詰め直す（最大件数-1まで）
For i As Integer = _capacity – 1 To 0 Step -1
_undoStack.Push(tempArray(i))
Next
End Sub
End Class
End Namespace
アーキテクトの視点：オブジェクトの明示的解放とGC対策
マネージ言語であるVB.NETであっても、巨大なオブジェクトグラフをスタックに保持し続けると、世代別ガベージコレクション（Gen 2 GC）のコストが跳ね上がる。業務システムで大量のバイナリや参照を扱う場合は、`IDisposable` を実装したオブジェクトを `Stack` に格納し、`Pop` された不要要素や、トリミングで溢れた要素に対して強制的に `.Dispose()` を呼ぶか、あるいは構造体（`Structure`）を活用してマネージヒープへの負荷をゼロに近づける設計が求められる。
—
3. 業務活用パターン②：`Queue(Of T)` による非同期タスクの順次処理（スレッドセーフ制御）
次に、基幹システム間連携や、ファイル監視、大量の帳票出力リクエストを非同期で順次処理（FIFO）するシチュエーションを考える。
ここで発生しがちなのが、複数スレッドからの同時アクセスによる `InvalidOperationException`（コレクションが変更されました）や、データ競合による破損だ。
VB.NETで `Queue(Of T)` を安全にラップし、バックグラウンドワーカーへタスクを供給する堅牢なキューイングエンジンの実装を示す。
Imports System.Collections.Generic
Imports System.Threading
Imports System.Threading.Tasks
Namespace Enterprise.Threading
Public Class SafeTaskQueue(Of T)
Private ReadOnly _queue As New Queue(Of T)()
Private ReadOnly _lockObject As New Object()
Private _isDisposed As Boolean = False
‘ キューへのエンキュー（生産者側）
Public Sub Enqueue(item As T)
SyncLock _lockObject
If _isDisposed Then Throw New ObjectDisposedException(NameOf(SafeTaskQueue(Of T)))
_queue.Enqueue(item)
‘ 待機スレッドへ通知（Monitor.Pulse あるいは Task/Semaphoreを使うのがモダン）
Monitor.Pulse(_lockObject)
End SyncLock
End Sub
‘ キューからのデキュー（消費者側：ブロック型）
Public Function Dequeue(cancellationToken As CancellationToken) As T
SyncLock _lockObject
While _queue.Count = 0
If _isDisposed Then Return Nothing
‘ シグナルを受け取るまでスレッドを効率的に休止（CPUを100%食いつぶさない）
Monitor.Wait(_lockObject)
cancellationToken.ThrowIfCancellationRequested()
End While
Return _queue.Dequeue()
End SyncLock
End Function
‘ 現在のキュー件数取得
Public ReadOnly Property Count As Integer
Get
SyncLock _lockObject
Return _queue.Count
End SyncLock
End Get
End Property
End Class
End Namespace
実務上の極限知見：スレッド競合とロックの粒度
単純な `SyncLock` は実装が容易だが、高スループットが求められる極限の環境では、ロック競合（Lock Contention）がボトルネックになる。
.NET 4.0以降であれば、`System.Collections.Concurrent.ConcurrentQueue(Of T)` を採用するのが定石である。内部でロックフリーに近いアトミック操作（CAS: Compare-And-Swap）を使用しているため、マルチスレッド環境下でのパフォーマンスは圧倒的だ。
しかし、「複数のキュー操作を不可分のトランザクションとしてAtomicに実行したい場合」や、古い .NET Framework 2.0/3.5 レガシー環境の保守においては、上記のような `Monitor` を用いた明示的な同期機構が今なお最強の武器となる。
—
4. レガシーシステム連携におけるトラブルシューティング
現場では、VB6のCOMコンポーネントや、外部の非マネージDLL（Windows API）と連携するケースが多々ある。
例えば、Windows APIのメッセージキュー（`PeekMessage` / `GetMessage`）と、マネージドな `Queue(Of T)` をブリッジする際、以下の罠に注意せよ。
1. マーシャリングコストの削減
Interop境界を跨ぐデータ構造のやり取りは、マネージ・アンマネージ間のメモリコピーが発生し、性能を著しく劣化させる。APIから取得したハンドルやポインタのリストを扱う場合は、マネージヒープに直接構造体を展開せず、`IntPtr` のまま `Queue(Of IntPtr)` で管理し、最終的な破棄を確実に担保すること。
2. メモリリークの温床「イベントハンドラとコレクション」
`Queue` や `Stack` に格納されたオブジェクトがイベントを購読している場合、コレクション自体が参照を持ち続けるため、GCのルートから外れず、メモリリークの主原因となる。キューから要素を排除する際は、必ずイベントの解除やリソースの解放（`Dispose`）をセットで行うこと。
—
総括
VB.NETにおける `Stack(Of T)` と `Queue(Of T)` は、単なる「便利なデータ構造」ではない。
システムのメモリフットプリントを最適化し、CPUキャッシュヒット率を高め、マルチスレッド環境におけるデータ整合性を担保するための「アーキテクチャの基盤」である。
「動けばいい」というアマチュアのコードを捨て、背後にあるメモリモデルと計算量を完全に支配せよ。それこそが、真のシニア・業務自動化エンジニアの姿である。
