async/awaitとコルーチンの内部実装

async/awaitは「中断できる関数」への糖衣

同期処理と非同期処理で見たとおり、async/awaitは非同期コードを同期のように書ける構文です。しかし「同期っぽく読める」のは表層で、実態は関数を任意の地点で中断し、後で同じ場所から再開する機能、すなわちコルーチンです。普通の関数（サブルーチン）は呼ばれたら最後まで走って戻りますが、コルーチンはawaitの地点で呼び出し元へいったん制御を返し、後で続きから走り直せます。

鍵は「ローカル変数や実行位置をどう保存するか」です。普通の関数はこれをコールスタック上に置きますが、中断するとスタックフレームは巻き戻ってしまう。だから別の場所に状態を退避する必要があります。その実現方式が、内部実装の核心です。

状態機械への変換

C#、Rust、JavaScriptなどの主流処理系は、async関数をコンパイル時に状態機械（state machine）へ変換します。awaitのたびに「ここまで進んだ」を表す状態番号を割り当て、関数全体を「現在の状態に応じて続きを実行する1つのループ」に書き換えるのです。

// 元のコード
async function load(id) {
  const user = await getUser(id);
  const posts = await getPosts(user);
  return render(user, posts);
}

これは概念的に、次のような構造体＋resume関数へ変換されます。

struct LoadState {
  state: int            // 0=開始, 1=getUser待ち, 2=getPosts待ち
  id, user, posts       // awaitをまたいで生きるローカル変数
}

resume(s):
  switch s.state:
    case 0:
      f = getUser(s.id); s.state = 1
      if f未完了: f.onComplete(() => resume(s)); return  // 中断
    case 1:
      s.user = f.結果
      g = getPosts(s.user); s.state = 2
      if g未完了: g.onComplete(() => resume(s)); return  // 中断
    case 2:
      s.posts = g.結果
      complete(render(s.user, s.posts))                   // 完了

ポイントは3つあります。第一に、awaitをまたいで使われるローカル変数はスタックではなく状態オブジェクト（ヒープ上）に格納される。第二に、await地点は「未完了なら完了コールバックを登録してreturnする」中断点になる。第三に、再開は同じresumeを再度呼び、switchが状態番号を見て続きへジャンプする。元の関数の見た目は手続き的でも、内部はこの「ジャンプ表」で制御構文を再構成しているわけです。

なぜ「状態の退避」が必要か

中断をまたいで生き残る変数は、なぜわざわざヒープへ移すのか。awaitで呼び出し元へ戻ると、そのasync関数のスタックフレームは解放されて消えるからです。再開時には別の呼び出し経路（完了コールバック）から入ってくるため、元のフレームはもう存在しません。状態オブジェクトに変数を保持しておけば、フレームが消えても値は残り、再開時に復元できます。これはクロージャが外側変数を閉じ込めて生かし続けるのと同じ発想で、コルーチンは「実行位置＋ローカル変数」をまとめてヒープに閉じ込めていると言えます。

スタックレス vs スタックフル

コルーチンの実装は、退避する範囲によって2系統に分かれます。

スタックレスコルーチンは、前述のとおり1つのasync関数を状態機械に変換するだけなので軽量です。ただし中断できるのはasync関数の本体に直接書いたawaitだけ。普通の関数から中断したければ、その関数もasyncにしてawaitを上へ伝播させる必要があります。これがいわゆる「関数の色（async汚染）」問題で、非同期は呼び出し連鎖を上まで侵食します。

スタックフルコルーチンは、コルーチンごとに独立したスタックを丸ごと持ちます。だから何段深い関数の中からでも中断でき、awaitのような印を全段に付ける必要がありません（Goで普通の関数呼び出しがそのままgoroutine内で止まれるのはこのため）。代償として、各コルーチンにスタック領域（数KB〜）を割り当てるコストが生じます。Goは初期数KBの小さなスタックを使い、必要に応じて拡張する方式でこれを抑えています。

イベントループとの連携

状態機械は「中断・再開できる」だけで、いつ再開するかを決めるのは別の主体です。それがイベントループ／スケジューラです。流れを追います。

1. async関数がawait fに到達。f（Promise/Future）が未完了なら、fに「完了したらresumeを呼べ」という継続を登録し、呼び出し元へreturnする。スレッドはブロックしない。
2. 実I/Oは処理系の外側（OSのepoll/IOCP、ブラウザのネットワーク層など）に依頼されており、完了するとイベントとして通知される。
3. イベントループが完了を検知し、登録された継続をタスクキューへ積む。
4. ループはコールスタックが空になった隙に、キューから継続を取り出してresumeを実行。状態機械は保存済みの状態番号から続きを走らせる。

つまりawaitは「待つ」のではなく「いったん譲って、完了したら起こしてもらう」仕組みです。JavaScriptでは完了継続はマイクロタスクとして扱われ、setTimeoutなどのマクロタスクより優先して実行されます。1本のスレッドでも固まらないのは、待ち時間にスレッドを解放し、その間に他のタスクを回せるからです。

async function a() {
  console.log('1');
  await null;            // ここで一旦譲る（マイクロタスクに分割）
  console.log('3');
}
console.log('start');
a();
console.log('2');
// 出力: start → 1 → 2 → 3

await nullの直後がそのまま動かず2が先に出るのは、await地点で関数が中断して呼び出し元（同期コード）へ制御を返し、続き（3）は現在の同期処理が終わってからマイクロタスクとして再開されるためです。

まとめ

async/awaitの内部実装は、(1)awaitごとに状態番号を振り、ローカル変数をヒープの状態オブジェクトへ退避する状態機械変換、(2)中断範囲が関数本体か専用スタック全体かで分かれるスタックレス／スタックフルの選択、(3)完了通知を受けてresumeを再投入するイベントループとの連携、という3層で成り立ちます。awaitは「待つ」のではなく「譲って後で起こしてもらう」中断点だと捉えると、関数の色問題、マイクロタスクの順序、CPUバウンド処理が詰まる理由まで一貫して説明できます。挙動の全体像は同期処理と非同期処理と合わせて押さえると盤石です。