クロージャの実装原理（環境キャプチャとアップバリュー）

クロージャの正体は「コード＋環境」の組

クロージャとスコープ で見たとおり、クロージャは「定義時の外側変数を覚え続ける関数」です。では実装上、この「覚える」は何で表現されているのか。答えは、クロージャが単なる関数ポインタではなく コード（関数本体）と環境（捕捉した変数の置き場）への参照の組 だという点にあります。関数の中で参照されるが、その関数自身では宣言していない変数を 自由変数（free variable） と呼びます。クロージャが捕捉しなければならないのは、まさにこの自由変数群です。

問題は変数の寿命です。通常、関数のローカル変数はコールスタック上のフレームに置かれ、関数が戻ればフレームごと巻き戻されて消えます。ところがクロージャは、生成元の関数がとうに戻った後も自由変数を参照し続けます。スタックに置いたままでは破棄済みの領域を指してしまう。つまり 捕捉された変数だけは、スタックの寿命を超えて生き延びさせる必要がある——これが実装上の核心です。

ヒープへの昇格（環境のボックス化）

解決策は、捕捉される変数をスタックフレームに置かず、ヒープ上に確保したセル（box）へ昇格させることです。コンパイラは「この変数はクロージャに捕捉される」と静的に判定し、その変数の実体をヒープに移します。ローカル変数のスロットはそのセルへの参照になり、生成されたクロージャも同じセルを指します。こうすれば生成元が戻ってもセルは生き続け、ガベージコレクション が「もう誰も参照していない」と判断するまで回収されません。クロージャの寿命管理が GC に乗るのはこのためです。

このセルを介す間接参照こそ、複数のクロージャが同じ変数を 共有 できる理由です。同じセルを2つのクロージャが指していれば、一方が書き換えた値をもう一方が読みます。ポインタと参照 でいう共有参照そのものが、捕捉変数の実体になっているわけです。

アップバリューと open / closed の二段構え

「常にヒープへ昇格」は単純ですが、捕捉されない大多数の変数まで巻き込むと無駄が出ます。Lua の処理系が採る アップバリュー（upvalue） 方式は、この遅延確保を洗練させた代表例です。アップバリューとは、内側の関数から見た外側のローカル変数への間接参照です。

要点は二状態を持つことです。捕捉対象の変数がまだ生成元のスタックフレーム上に生きている間、アップバリューは open 状態で、スタックスロットを直接指します。生成元の関数がそのスコープを抜ける瞬間、ランタイムはアップバリューを close し、変数の現在値をアップバリュー自身の内部へコピーして退避させ、参照先をそこへ切り替えます。

この設計の利点は、変数がスタック上にある限りヒープ確保を先延ばしにでき、しかも同じ open アップバリューを複数のクロージャが共有すれば書き換えが互いに見える点です。VM は「どのスタックスロットがどの open アップバリューに対応するか」のリストを持ち、スコープ離脱時に該当分だけまとめて close します。VMとバイトコード実行 の文脈では、GETUPVAL / SETUPVAL といった専用命令でアップバリューを読み書きします。

クロージャ変換：コンパイラ側の書き換え

ランタイムの仕掛けを支えているのが、コンパイラ段での クロージャ変換（closure conversion） です。自由変数を持つネストした関数は、そのままでは「外側の文脈」に依存していて単独で呼べません。クロージャ変換は、自由変数を 環境（environment）という構造体に集約 し、関数を「環境を明示的な引数として受け取る、自由変数を持たない素の関数」へ書き換えます。よく似た技法に ラムダリフティング（lambda lifting） がありますが、こちらは自由変数を環境構造体ではなく追加の引数へ展開してトップレベル関数へ持ち上げる点が異なります。

// 変換前（f は自由変数 base を捕捉している）
function makeAdder(base):
  function f(x): return x + base   // base は自由変数
  return f

// 変換後（環境 env を明示化）
function f_lifted(env, x): return x + env.base
function makeAdder(base):
  env = heap_alloc({ base: base })   // 捕捉変数を環境へ
  return Closure(code = f_lifted, env = env)  // コードと環境の組

変換後のクロージャ値は「f_lifted という関数ポインタ」と「env への参照」のペアになります。呼び出しは closure.code(closure.env, 引数...) という形に展開され、自由変数アクセスはすべて env.フィールド への参照に置き換わります。これが冒頭の「コード＋環境の組」の正体です。実装によっては、必要な自由変数だけを詰めた フラットな環境 を作る方式と、外側の環境へのポインタを繋ぐ 連結リスト的な環境 を作る方式があり、前者はアクセスが速く、後者は確保が軽いというトレードオフがあります。

値で捕捉するか、参照で捕捉するか

最後に意味論上の分岐点を押さえます。捕捉が 参照（by reference） なら、クロージャはセルを共有するので、生成後に外側で変数を書き換えるとクロージャから見える値も変わります。JavaScript や Lua のクロージャはこちらで、これが クロージャとスコープ のループ変数共有の罠の正体です——全クロージャが同一セルを指すため、ループ終了後の最終値を一斉に読みます。

一方 値（by value） での捕捉は、生成時点の値を環境へコピーします。C++ のラムダの [=] は明示的にこの系統で、捕捉後に元を変えてもクロージャの値は固定です。Java は「捕捉変数は事実上 final（再代入不可）」という制約を課すため、参照捕捉でありながら値捕捉と区別がつかなくなります。なお C# は変数自体をヒープへ持ち上げる参照捕捉で、捕捉変数の再代入を許す点では JavaScript 側に属します。

まとめ

クロージャの実体は コード（関数ポインタ）と捕捉した環境への参照の組 です。捕捉される変数はスタックの寿命を超えるため、エスケープ解析で見抜かれて ヒープ上のセルへ昇格 し、クロージャの生存中は GC が延命します。Lua のアップバリューは open / closed の二段構え で確保を遅延しつつ共有を保ち、コンパイラ側の クロージャ変換 が自由変数を環境構造体へ集約して関数を環境引数つきの素の関数へ書き換えます。捕捉が参照か値かで挙動が変わり、参照捕捉の共有セルがループ変数の罠を生み、捕捉の延命作用がメモリリークの温床にもなる——内部実装まで降りれば、これらは一つの原理の表と裏として一望できます。