Workerスレッド間での変数共有：SharedArrayBufferとAtomicsによる並列処理とメモリ空間の深層
JavaScriptは伝統的にシングルスレッドのランタイムとして設計されてきた。V8エンジンのメインスレッド上で動くイベントループは、コールスタック、マクロタスクキュー（`setTimeout`等）、マイクロタスクキュー（`Promise`等）を調停し、UIのブロッキングを防ぐために非同期I/Oを駆使してきた。
しかし、現代のWebアプリケーションやNode.jsサーバーサイド環境において、暗号学的ハッシュの計算、画像・映像のリアルタイムデコード、巨大なJSONやバイナリデータのパースといった重い処理をメインスレッドで実行することは、フレームドロップやイベントループの遅延（Livenessの喪失）を直ちに引き起こす。
ここで登場するのが `Web Worker` および `WorkerThreads`（Node.js）である。従来の Worker 間通信は `postMessage` を介した構造化クローン（Structured Clone）によるメモリの「コピー」が基本であり、巨大なデータを扱う際のシリアライズ/デシリアライズコスト、およびV8ヒープ間のガベージコレクション（GC）のプレッシャーは無視できないボトルネックであった。
このパラダイムを根本から覆し、真の並列処理（Shared-Memory Multithreading）をもたらすのが `SharedArrayBuffer` (SAB) と `Atomics` である。本稿では、V8エンジンのメモリモデル、C++ヒープとJavaScriptコンテキストの境界、そしてマルチスレッド環境下におけるスコープと変数の可視性の限界を、極限の低レイヤ視点から解き明かす。
—
1. V8メモリ空間とSharedArrayBufferの物理的実体
通常、JavaScriptのオブジェクトや配列は、V8のガベージコレクタ（Orinoco等）が管理するヒープ領域（New Space / Old Space）にアロケートされる。各Workerスレッドはそれぞれ独自の独立したV8 Isolate（独立したV8インスタンス、ヒープ、ヒープ管理構造）を持ち、変数のスコープは完全に隔離されている。
しかし、`SharedArrayBuffer` はV8ヒープの管理下でありながら、OSの仮想メモリ空間（あるいはブラウザのプロセスを跨ぐ共有メモリ領域）に直接マッピングされる連続したバッファである。
[ メインスレッド (Isolate A) ] [ Workerスレッド (Isolate B) ]
| |
v v
V8 Heap (独自空間) V8 Heap (独自空間)
\ /
+—> [ SharedArrayBuffer (物理メモリ共有) ] <---+
ここで重要なのは、「共有されているのはあくまで生（Raw）のバイト列であって、JavaScriptの変数やオブジェクトそのものではない」という点である。
`SharedArrayBuffer` 自体はスコープやプロパティを持つオブジェクトだが、その実態は単なる固定長のバイト配列への参照に過ぎない。これを型付き配列（`Int32Array` や `Float64Array` など）でラップすることで、初めて意味のある数値データとしてアクセスできるようになる。
しかし、複数スレッドから同一のメモリ領域へアトミック（不可分）な同期なしにアクセスすると、CPUキャッシュの不整合、命令の並べ替え（Reordering）、そして致命的なデータ競合（Data Race）を引き起こす。
—
2. スコープと変数の可視性：レキシカルスコープの幻想
JavaScriptプログラマは、変数の可視性を「レキシカルスコープ（Lexical Scope）」や「クロージャ」といった言語仕様の概念で捉えがちである。例えば、次のようなコードを想像してほしい。
// メインスレッドのスコープ内
const sharedBuffer = new SharedArrayBuffer(1024);
const sharedArray = new Int32Array(sharedBuffer);
// Workerへバッファを転送（実際には転送ではなく共有）
const worker = new Worker(‘worker.js’);
worker.postMessage({ buffer: sharedBuffer });
`worker.js` 側で `sharedBuffer` を受け取り、それをラップした `Int32Array` を別の変数名で宣言したとしても、指し示している物理メモリはメインスレッドのものと完全に同一である。
// worker.js 内
self.onmessage = (e) => {
const { buffer } = e.data;
const localArray = new Int32Array(buffer);
// メインスレッド側で変更された値が、即座にこのスコープから見える
console.log(localArray[0]);
};
ここで注意すべきは、「変数のバインディング（スコープ内の名前）」はスレッドごとに独立しているが、「メモリの実体」は共有されているという点だ。
レキシカルスコープはコンパイル時の静的な解決やV8のスコープ情報（ScopeInfo）によって保証されるが、`SharedArrayBuffer` を介したデータ共有は、言語のスコープ規則を完全にバイパスし、生のメモリアドレスに対する直接的な読み書きを行う。
—
3. Atomics API による同期制御とメモリオーダリング
マルチスレッド環境において、あるスレッドが書き込んだ変数の変更が、別のスレッドからいつ見えるようになるのか（Visibility）、そして複数のCPUコアが同時に同じメモリ領域を書き換えたときにデータの整合性がどう保たれるのか（Atomicity）という問題は、CPUのアーキテクチャ（x86/x64のTSOやARMの弱メモリモデル）に直結する。
JavaScriptでは、このハードウェアレベルの同期プリミティブを `Atomics` オブジェクトを通じて安全に操作できる。
以下のコードは、メインスレッドとWorkerスレッド間で `SharedArrayBuffer` を用いて安全にカウンタをインクリメントし、処理の同期を取る実践的な実装例である。
実装例：セマフォとアトミック操作による安全な並列処理
// — main.js (メインスレッド) —
// 4バイト（32ビット整数）× 2個分の共有バッファを確保
// [0]: カウンタ値, [1]: ロックフラグ/ステータス
const sab = new SharedArrayBuffer(Int32Array.BYTES_PER_ELEMENT 2);
const sharedArray = new Int32Array(sab);
// ワーカーの生成
const worker = new Worker(‘./worker.js’);
worker.onmessage = (event) => {
if (event.data === ‘DONE’) {
console.log(`[Main] すべての処理が完了しました。最終カウンタ値: ${Atomics.load(sharedArray, 0)}`);
}
};
// ワーカーにSharedArrayBufferを渡す
worker.postMessage({ buffer: sab });
// — worker.js (Workerスレッド) —
self.onmessage = (event) => {
const { buffer } = event.data;
const sharedArray = new Int32Array(buffer);
// 10万回のアトミックなインクリメントを実行
for (let i = 0; i < 100000; i++) {
// Atomics.add は指定したインデックスの値をアトミックに加算し、直前の値を返す
// これにより、読み取り・修飾・書き込みの競合（Race Condition）を防ぐ
Atomics.add(sharedArray, 0, 1);
}
// メインスレッドへ完了を通知
self.postMessage('DONE');
};
Atomics.wait と Atomics.notify によるスレッドのブロック制御
UIスレッド（ブラウザのメインスレッド）で `Atomics.wait()` を呼び出すことは厳に慎むべきである。なぜなら、`Atomics.wait()` は指定されたメモリ位置の値が特定の条件を満たすまで、メインスレッドのイベントループそのものを完全にブロック（停止）させるからだ。この仕様のため、`Atomics.wait()` はメインスレッド上では実行時エラー（`TypeError`）を投げるよう設計されている。
したがって、同期的ウェイトは必ず Worker スレッド（あるいはNode.jsのWorkerThreads）の内部で行う必要がある。
// Workerスレッド内でのアトミックな待機処理の例
// sharedArray[1] が 0 である間、スレッドをOSレベルでサスペンド（CPUサイクルを消費しない）させる
Atomics.wait(sharedArray, 1, 0);
console.log(‘[Worker] メインスレッドからのシグナルを受信しました。’);
—
4. ランタイムの防壁を突破・防御する：セキュリティの深層
`SharedArrayBuffer` は極めて強力な機能であるため、セキュリティ上の脅威（特に Spectre などのサイドチャネル攻撃）の温床となり得た歴史を持つ。高精度タイマー（`performance.now()` 等）と `SharedArrayBuffer` を組み合わせることで、CPUのキャッシュヒット・ミスを観測し、他のオリジンのメモリ領域から機密情報を不正に読み出すスぺクター攻撃が可能になるためである。
現在、ブラウザ環境で `SharedArrayBuffer` を安全に利用するためには、クロスオリジン分離（Cross-Origin Isolation）が必須となっている。HTTPヘッダーにおいて以下の設定が強制される：
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
プロトタイプ汚染（Prototype Pollution）との交差点
ここで、シニアエンジニアとして警戒すべき最悪のシナリオに言及しておこう。それは、「もし、共有メモリを操作するコードベースにおいてプロトタイプ汚染脆弱性が存在した場合、サプライチェーン経由でRCE（リモートコード実行）に直結するリスク」である。
通常、プロトタイプ汚染は `Object.prototype` などのプロパティを書き換えることで、アプリケーションのロジックを誤認させたり、プロパティインジェクションを通じてDoSや権限昇格を引き起こしたりする。
しかし、もし攻撃者が `SharedArrayBuffer` を用いた高度な非同期処理、あるいはネイティブアドオン/Wasm（WebAssembly）とJavaScriptオブジェクトの境界を曖昧にするコード構造においてプロトタイプ汚染を達成した場合、以下の脅威が現実味を帯びる。
1. 型付き配列のビューの誤認: 共有メモリをラップする `TypedArray` のコンストラクタやプロトタイプメソッド（例: `DataView` や `Int32Array.prototype`）が汚染された場合、メモリアクセスのオフセットや長さを表す内部スロットが改ざんされる可能性がある。
2. バッファオーバーフローの誘発: 汚染されたプロパティがメモリサイズやインデックスの計算ロジックに流し込まれた場合、V8の境界チェック（Bounds Check）をバイパスし、任意のメモリ領域（別のWorkerのデータやV8の内部ヒープ）への不正な読み書き（Arbitrary Read/Write）を引き起こす。
3. コード実行への昇格: 共有メモリ上に配置されたバイトコードやWasmのインスタンス領域、あるいは関数ポインタを模したデータ構造が不正に書き換えられた場合、最終的にネイティブ命令の実行ハイジャック（RCE）へと繋がる。
防御の鉄則（Hardening）
- 入力値の厳格な検証 (Schema Validation): ZodやJoiなどのバリデーターを用い、外部から渡されたデータが `__proto__` や `constructor` などの危険なプロパティを含んでいないことをランタイムの境界で確実に検証する。
- Object.freeze() によるイミュータビリティ: 共有メモリを制御するコアとなるオブジェクトやプロトタイプは、起動時に `Object.freeze()` を適用し、動的な拡張や改ざんを物理的に不可能にする。
- 安全なWorker間通信: 構造化クローンや `SharedArrayBuffer` を扱う際は、不要なオブジェクトのプロトタイプチェーンをコピーしないよう、プレーンなデータ構造（Plain Old JavaScript Object）のみを許可するアーキテクチャを徹底する。
—
結びにかえて
`SharedArrayBuffer` と `Atomics` は、JavaScriptを「単一のイベントループ上で動くスクリプト言語」から「真のマルチスレッド並列処理を内包するシステム言語の領域」へと引き上げた。
しかし、そのパワーの代償として、開発者はV8のヒープ管理、OSのメモリモデル、CPUキャッシュの整合性、そしてアトミック操作のセマンティクスを完全に理解していなければならない。レキシカルスコープの向こう側に広がる共有メモリの荒野において、バグはもはや単なる「値の勘違い」ではなく、ハードウェアレベルの競合や致命的なセキュリティホールとなって牙をむく。
ランタイムの挙動を支配し、コードの1行がCPUキャッシュとV8の内部構造にどう作用するかを常にイメージすること。それこそが、現代のシニアエンジニアおよびアーキテクトに求められる絶対的な素養である。