メモリの魔術：SharedArrayBufferとAtomicsによる並列処理の限界突破とランタイム防壁
JavaScriptは、その誕生以来「シングルスレッドの言語」という呪縛、あるいは美徳と共に歩んできた。イベントループと非同期I/Oモデルは、WebのUIスレッドをブロックから解放し、フロントエンドの繁栄を支えた。しかし、マルチコアが当たり前となった現代において、CPUの1コアしか直接駆動できないこのモデルは、高負荷な演算処理（画像・動画処理、暗号化、物理演算など）においては明白なボトルネックとなる。
そこで導入されたのが Web Workers であり、さらにその並列性の限界を押し広げるために設計されたのが `SharedArrayBuffer` (SAB) と `Atomics` APIである。
本稿では、メインスレッドとWorkerスレッド間におけるスコープの壁を破壊し、物理メモリを直接共有しながらデータ同期を行う極限の並列処理アーキテクチャについて、V8エンジンのメモリモデルと低レイヤの同期メカニズムを交えて徹底的に解説する。
—
1. V8ヒープの裏側：メッセージパッシングから物理メモリ共有へ
通常、Workerスレッド間でのデータ通信には `postMessage()` が使われる。これの裏側では何が起きているか？
構造化クローンアルゴリズム（Structured Clone Algorithm）により、送信側のオブジェクトは一旦シリアライズ（直列化）され、V8のヒープからメモリがコピーされ、受信側でデシリアライズされて新しいオブジェクトとして割り当てられる。数メガバイトのデータをやり取りする場合、このメモリコピーとGC（ガベージコレクション）のオーバーヘッドは、イベントループのフレームレートを容易に殺す。
[Main Thread] –(Structured Clone: Copy & Deserialize)–> [Worker Thread]
(V8 Heap A) (V8 Heap B)
これに対し、`SharedArrayBuffer` は、V8のヒープマネージャおよびOSの仮想メモリレイヤをバイパスし、両方のスレッドから直接読み書き可能な同一の物理メモリ領域（Raw Binary Memory）への参照を提供する。
[Main Thread] —\
>—> [SharedArrayBuffer (OS Raw Memory)]
[Worker Thread] —/
だが、ここで致命的な問題が生じる。JavaScriptの「変数スコープ」は、もはやシングルスレッドの安全性を保証してくれない。
—
2. スコープの錯覚と「データ競合（Data Race）」の恐怖
関数スコープ、ブロック（Lexical）スコープ、クロージャ。私たちは普段、これらによって変数が安全にカプセル化されていると信じ込んでいる。しかし、`SharedArrayBuffer` を介した空間では、その前提は崩れ去る。
複数のスレッドが、同一のメモリアドレスに対して、同期機構なしに一方が書き込み、もう一方が読み込み（あるいは両方が書き込み）を行った瞬間、データ競合（Data Race）が発生する。これは未定義動作（Undefined Behavior）を引き起こし、C++やRustの世界と同様、JavaScript（あるいはV8のJITコンパイルされたマシンコード）においても、メモリの破損や不整合、最悪の場合はセキュリティ脆弱性の温床となる。
ここで登場するのが `Atomics` オブジェクトである。
—
3. 実装：Atomicsによるハードウェアレベルの同期制御
次のコードは、メインスレッドとWorkerスレッドの間で、ロックフリーなカウンタとフラグメント共有を行う極限の並列処理パターンである。
メインスレッド側の実装 (main.js)
// 4バイト（Int32）の領域を確保。メタデータ用とカウンタ用
const sab = new SharedArrayBuffer(Int32Array.BYTES_PER_ELEMENT 2);
const sharedArray = new Int32Array(sab);
// インデックスの定義
const FLAG_INDEX = 0; // 同期用フラグ (0: ロック解除, 1: ロック中)
const COUNTER_INDEX = 1; // 共有カウンタ
// Workerの起動
const worker = new Worker(‘./worker.js’);
// ワーカースレッドへSharedArrayBufferを送信（ゼロコピー）
worker.postMessage({ sab });
// メインスレッド側でも非同期にインクリメントを試みる
console.log(‘[Main] Workerへの処理指示を開始’);
// メインからAtomicsで安全に値を操作
setTimeout(() => {
Atomics.add(sharedArray, COUNTER_INDEX, 100);
console.log(`[Main] カウンタに100を加算。現在の値: ${Atomics.load(sharedArray, COUNTER_INDEX)}`);
}, 500);
worker.onmessage = (e) => {
console.log(`[Main] Workerからの最終結果受取: ${e.data}`);
console.log(`[Main] 最終カウンタ値: ${Atomics.load(sharedArray, COUNTER_INDEX)}`);
};
ワーカー側の実装 (worker.js)
self.onmessage = (e) => {
const { sab } = e.data;
const sharedArray = new Int32Array(sab);
const FLAG_INDEX = 0;
const COUNTER_INDEX = 1;
// スピンロック（Spinlock）とAtomics.compareExchangeによる排他制御
// 別のスレッドが書き込み中の場合、アトミックにロックを取得できるまでCPUサイクルを消費しながら待機
function acquireLock() {
while (Atomics.compareExchange(sharedArray, FLAG_INDEX, 0, 1) !== 0) {
// Atomics.waitはメインスレッドでは使用不可（DOMブロックを防ぐため）。
// Workerスレッド内であれば Atomics.wait を使ってOSレベルでスリープさせることが可能。
}
}
function releaseLock() {
Atomics.store(sharedArray, FLAG_INDEX, 0);
// 待機している他のスレッドを起こす
Atomics.notify(sharedArray, FLAG_INDEX, 1);
}
// 重い演算をシミュレートしつつ、安全にカウンタをインクリメント
for (let i = 0; i < 10000; i++) {
acquireLock();
// クリティカルセクション（Critical Section）
// この区間内では、他のスレッドはこのメモリ領域を改変できない
let current = Atomics.load(sharedArray, COUNTER_INDEX);
Atomics.store(sharedArray, COUNTER_INDEX, current + 1);
releaseLock();
}
// メインスレッドへ完了通知
self.postMessage('Worker processing completed');
};
このコードがV8ランタイムとCPUレベルで意味すること
1. メモリバリア（Memory Barrier / Fence）の挿入: `Atomics.load` や `Atomics.store` を使うことで、CPUのアウト・オブ・オーダー実行（命令の実行順序入れ替え）や、各コアのL1/L2キャッシュ間の不整合を防ぎ、強制的にメインメモリ（RAM）レベルでデータの整合性を同期させる。
2. `Atomics.compareExchange`: いわゆるCAS（Compare-And-Swap）操作。ハードウェアのロックプリミティブに直結しており、マルチスレッド環境下におけるアトミックな条件分岐を保証する。
—
4. セキュリティの深層：Spectre脆弱性とSharedArrayBufferの制限
ここで、シニアエンジニアやセキュリティ研究者が知るべき「歴史と防壁」の話をしなければならない。
かつて、`SharedArrayBuffer` は任意のOriginから無制限に利用可能だった。しかし、2018年に発覚したCPUのハードウェア脆弱性 Spectre（Variant 1 & 4：投機的実行サイドチャネル攻撃） により、状況は一変した。
サイドチャネル攻撃のメカニズム
攻撃者は、悪意あるWebサイトに埋め込んだJavaScriptから `SharedArrayBuffer` と高精度タイマー（`performance.now()` や専用のWorkerループによるアトミックなカウンタ）を組み合わせることで、CPUの投機的実行（Speculative Execution）のキャッシュヒット/ミスを観測し、本来アクセス権のないブラウザの別オリジン領域のメモリ（クロスオリジン・アイソレーションが破られた空間）をミリ秒単位で読み取ることに成功した。
このサプライチェーン・サイドチャネル攻撃を防ぐため、主要ブラウザは一時的に `SharedArrayBuffer` を無効化した。
現代における厳格な防壁（Cross-Origin Isolation）
現在、本番環境で `SharedArrayBuffer` を有効化するには、サーバーレスポンスヘッダーにおいて以下のクロスオリジン・アイソレーション（Cross-Origin Isolation）を完全に構築することが強制されている。
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
このヘッダーを付与しない限り、`typeof SharedArrayBuffer` は `undefined` となり、インスタンス化しようものなら `TypeError` が投擲される。ランタイムの安全性を担保するため、ブラウザのセキュリティ境界はここまで厳格に引き締められているのだ。
—
5. チーフアーキテクトからの提言
`SharedArrayBuffer` と `Atomics` は、JavaScriptを「スレッドセーフなシステムプログラミング言語」の領域へと引き上げる強力な両刃の剣である。
しかし、安易な導入は、デバッグが極めて困難なデッドロック、ライブロック、そして不可解なメモリ破壊バグをプロダクション環境に招き入れる。データ構造の設計段階からメモリアラインメントを意識し、どのインデックスがどの意味を持つのかを厳密に定義すること。
JavaScriptのランタイムの限界をさらに先へ押し広げたいのであれば、V8のヒープ構造とCPUキャッシュの挙動を脳内に描けた状態でコードを書くべきだ。妥協なき最適化と、鉄壁のセキュリティ要件のクリア。それらを両立させることが、真のモダンWebアーキテクトに課された使命である。