VB.NETを掌握する極限の知見：Sharedメンバーの落とし穴とスレッドセーフなクラス設計の極意
レガシーなVB6/VBAの呪縛から脱却し、現代の.NETエコシステムへと踏み出した開発者が最初に直面する罠、それが `Shared`（静的）メンバーの魔力だ。
「どこからでもインスタンス化せずに呼び出せる」「グローバルな状態を保持できる」。この利便性は、シングルスレッドのレガシー脳にとっては麻薬のようなものだ。しかし、マルチスレッドが当たり前の現代のエンタープライズ環境において、無計画な `Shared` の乱用は、システムを静かに、そして確実におかしな挙動へと導く時限爆弾と化す。
今回は、VB.NETの中級から上級へステップアップしようとするエンジニアに向け、`Shared` メンバーがマルチスレッド環境下で引き起こす競合状態（Race Condition）のメカニズムと、それを完全に制御するための排他制御、そしてメモリ最適化を見据えたクラス設計の極意を授ける。
—
1. なぜ `Shared` メンバーはマルチスレッドで凶器と化すのか？
VB.NETにおける `Shared` キーワードは、そのメンバーが特定のインスタンスではなく、型そのものに属することを意味する。アプリケーションドメイン内において、`Shared` 変数はたった一つのメモリ領域を全スレッドで共有する。
ここで発生するのが「可視性の問題」と「アトミクス（不可分性）の欠如」だ。
例えば、バックグラウンドワーカー（`Task` や `Thread`）が並列稼働する基幹システムの集計ロジックにおいて、以下のようなコードを書いたとしたら、それはバグの温床を自らバラ撒いているに等しい。
‘ 【アンチパターン】絶対にやってはいけないShared変数のインクリメント
Public Class TransactionCounter
‘ 共有カウンタ
Public Shared TotalProcessed As Integer = 0
Public Shared Sub Increment()
‘ この一見シンプルな加算処理は、実際には3つのステップに分かれている
‘ 1. メモリからレジスタへ値を読み込む (Read)
‘ 2. レジスタ上で値を+1する (Modify)
‘ 3. レジスタからメモリへ書き戻す (Write)
TotalProcessed += 1
End Sub
End Class
マルチスレッド環境下では、スレッドAがステップ2を実行している最中に、スレッドコンテキストスイッチが発生してスレッドBが割り込むことがある。結果として、2つのスレッドが同時に「同じ古い値」を読み込み、それぞれ1を加算して書き戻すため、本来「2」増えるべきカウンタが「1」しか増えないロストアップデート（更新損失）が引き起こされる。
—
2. `SyncLock` による厳格な排他制御とデッドロックの回避
この競合を防ぐための最もプリミティブかつ確実な手段が、`SyncLock` ステートメント（内部的には `Monitor.Enter` / `Monitor.Exit`）によるクリティカルセクションの保護だ。
しかし、ここにもシニアの知見が必要となる。何をロックの目印（ロックオブジェクト）にするか、という設計思想だ。
誤ったロックオブジェクトの選択
`SyncLock Me` や `SyncLock GetType(MyClass)` を使ってはならない。特に後者（型オブジェクトのロック）は、アプリケーション全体で共有されるため、外部のサードパーティ製ライブラリとロック競合を起こし、原因不明のデッドロック（膠着状態）を引き起こすリスクがある。
正しいスレッドセーフな実装パターン
以下に、スレッドセーフに状態を管理するクラスの模範解答を示す。
Imports System.Threading
Public Class SecureTransactionManager
‘ 1. 外部からアクセスできない専用のロックオブジェクトをSharedで用意する
Private Shared ReadOnly _lockObject As New Object()
‘ 2. 共有状態はPrivateに隠蔽し、プロパティ経由でのみアクセスさせる
Private Shared _totalProcessed As Integer = 0
Public Shared ReadOnly Property TotalProcessed As Integer
Get
‘ 読み取り専用プロパティであっても、メモリバリアと可視性を保証するためロックする
SyncLock _lockObject
Return _totalProcessed
End SyncLock
End Get
End Property
Public Shared Sub ProcessTransaction()
‘ クリティカルセクションの最小化
SyncLock _lockObject
‘ ここにある処理は、同時に1つのスレッドしか実行できない
_totalProcessed += 1
‘ ※注意: このブロック内で時間のかかる外部I/OやDBアクセスを行うと、
‘ 全スレッドのボトルネック（スレッドプール枯渇）になるため厳禁。
End SyncLock
End Sub
End Class
—
3. Windows API連携とメモリ最適化：Sharedが生むGC（ガベージコレクタ）の負荷
レガシーシステムとの統合や、OSの深部を叩くために `DllImport` を用いた Windows API 呼び出しを行う際、`Shared` メソッドの設計はメモリ管理に直結する。
APIのラッパーをすべて `Shared` にすること自体は問題ないが、「マネージドではないリソース（ハンドル、COMオブジェクト、アンマネージドメモリ）」を `Shared` なフィールドに保持し続ける設計は、GCのライフサイクルを破壊する。
アンマネージド・リソースとSharedの危険な関係
Public Class UnsafeApiWrapper
‘ 【悪夢の設計】Shared変数にアンマネージドのハンドルを保持し続ける
‘ アプリケーションが終了するまでメモリが解放されず、メモリリークの温床になる
Private Shared _hGlobalMemory As IntPtr = IntPtr.Zero
Public Shared Sub AllocateBuffer(size As Integer)
SyncLock GetType(UnsafeApiWrapper)
If _hGlobalMemory <> IntPtr.Zero Then
‘ 解放忘れによるメモリリーク
End If
‘ Windows API (GlobalAllocなど) の呼び出し
_hGlobalMemory = System.Runtime.InteropServices.Marshal.AllocHGlobal(size)
End SyncLock
End Sub
End Class
極限の知見：IDisposable パターンとインスタンス化の復権
「どこからでも呼べるから」という安易な理由で、すべてのユーティリティクラスを `Shared` にしてはならない。リソースを保持するクラスは、インスタンスベースで設計し、`IDisposable` インターフェイスを実装して確実な解放（Deterministic Finalization）を担保するのがアーキテクトの鉄則だ。
どうしても `Shared` 経由でAPIを叩く必要がある場合は、状態を持たない（ステートレスな）純粋な関数（Pure Functions）に徹し、メモリの割り当てや解放は呼び出し側のスコープ（Usingブロック）に委ねるべきである。
—
4. スレッドセーフな遅延初期化（Lazy Initialization）の極限
シングルトンパターンや、高コストな設定ファイルの読み込みを `Shared` で行う際、スレッドセーフかつ高パフォーマンスに初期化を行うには、VB.NET / .NETが提供する `Lazy(Of T)` クラスを使用するのが現代のベストプラクティスだ。
自前で `If _instance Is Nothing Then SyncLock …`（ダブルチェックロッキング）を実装するのは、メモリバリアの理解を誤ると極めて微妙なバグ（CPUの命令リオーダリングによる初期化不完全なオブジェクトの参照）を生むため、絶対に避けるべきである。
Imports System.Threading
Public NotInheritable Class EnterpriseConfiguration
‘ Lazy(Of T) を使うことで、スレッドセーフかつ遅延初期化を完璧に実現する
Private Shared ReadOnly _instance As New Lazy(Of EnterpriseConfiguration)(
Function() New EnterpriseConfiguration(),
LazyThreadSafetyMode.ExecutionAndPublication
)
‘ 外部からのインスタンス化を完全にシャットアウト
Private Sub New()
‘ 高コストな初期化処理（DB接続文字列の復号化、XMLパース等）
Console.WriteLine(“Configuration initialized.”)
End Sub
‘ 唯一のアクセスポイント
Public Shared ReadOnly Property Instance As EnterpriseConfiguration
Get
Return _instance.Value
End Get
End Property
‘ インスタンスメンバーの定義
Public ReadOnly Property ConnectionString As String
Get
Return “Server=myServerAddress;Database=myDataBase;Uid=myUsername;Pwd=myPassword;”
End Get
End Property
End Class
この実装であれば、複数のスレッドが同時に `EnterpriseConfiguration.Instance` にアクセスしたとしても、インスタンス化はスレッドセーフに1度だけ実行され、ロックのオーバーヘッドも初期化時のみに限定される。パフォーマンスと安全性の完璧な両立だ。
—
総括：伝説的アーキテクトからの提言
VB.NETは、その柔軟性と懐の深さゆえに、初心者からシニアまで同じコードを書けてしまう言語である。だからこそ、書き手の「設計思想」がコードの品質にダイレクトに反映される。
- `Shared` メンバーは、「状態を持たないユーティリティ」または「スレッドセーフに制御された不変のグローバルリソース」にのみ使用する。
- 可変（Mutable）な状態を `Shared` に持たせる場合は、必ず `SyncLock` または `Lazy(Of T)` による厳格な排他制御とライフサイクル管理を行う。
- レガシーなVBA感覚の「とりあえずグローバル変数」という発想を捨て、オブジェクト指向とマルチスレッドの物理法則に向き合うこと。
この領域を極めた時、あなたの書くVB.NETコードは、レガシーの枠を超え、どんなモダン言語にも劣らない堅牢性と美しさを放つようになる。妥協なきコードで、次のシステムを構築せよ。
