イベントループの仕組み — 表示の順番が入れ替わるのはなぜ？

ひよこ

上に書いた処理が、後から表示されるのはなぜ？

ペンギン先生

後で呼ぶように予約した処理だからだよ。まず今のJavaScriptの処理を進め、予約したコールバックは決まった機会に実行する。下の4つのログで、書いた順と実行順の違いを確かめよう。

ひよこ

イベントループは、待ち受け係みたいなもの？

ペンギン先生

そうだね。実行する仕事を進め、通信などの完了や次の仕事を扱う仕組みだよ。待ち時間にほかの仕事を進められるけれど、長い計算を実行している間は同じ実行スレッドで別のJavaScriptを進められないんだ。

ひよこ

JavaScriptは、いつでも1本のスレッドだけなの？

ペンギン先生

1つの実行の流れでは、今の処理を途中で別の処理に取り替えないことが基本だよ。でもWeb WorkerやNode.jsのworker_threadsなどは別の実行スレッドを使える。エンジン全体やすべてのプログラムが1本だけ、という意味ではないんだ。

ひよこ

Promise.thenはタイマーと同じ順番待ち？

ペンギン先生

同じ1つの列としては考えないほうがいいよ。ブラウザーではPromiseの反応などのマイクロタスクと、タイマーなどのタスクを区別する。下の例では今の処理が終わるとPromiseの反応が先に進むよ。

ひよこ

setTimeoutの0は、今すぐ実行という意味？

ペンギン先生

今の処理へ割り込む意味ではないよ。指定した時間が過ぎても、実行できる機会を待つ。ブラウザーやNode.jsの条件でも変わるから、正確に0ミリ秒後に動く時計にはできないんだ。

ひよこ

awaitを書けば重い計算も軽くなる？

ペンギン先生

awaitは非同期の結果を待つための書き方で、計算を自動的に別のCPUへ移すものではないよ。重い計算なら仕事を小分けにして返すか、適したWorkerへ渡すなどを考える。まず計測して何が時間を使うか調べよう。

ひよこ

Promise.allは、仕事をまとめて開始するの？

ペンギン先生

渡したPromiseの結果をまとめるものだよ。仕事の開始はfetchなどを呼ぶ側の動作で、Promise.all自体が関数一覧を実行するわけではない。1つが拒否されても、ほかの仕事を自動的にキャンセルはしないよ。

ひよこ

ブラウザーとNode.jsは同じ図で覚えていい？

ペンギン先生

最初の例の順番はどちらでも確認できるけれど、仕組みの詳細は分けよう。Node.jsにはpollやcheckなどの段階があり、バージョンによる変更もある。すべてを1つのキューや固定した6段階だけで説明すると誤解しやすいんだ。

まずは、4つのログの順番を予想する

注文をしてから料理ができるまで待つように、JavaScriptでも今行うことと、後で呼ばれることを分けます。イベントループを全部暗記する前に、次の順番を予想してみましょう。

ブラウザーの開発者ツールのコンソールへ貼り付けるか、Node.jsがあればloop-demo.jsとして保存し、node loop-demo.jsで試せます。

console.log("1. 注文する");
setTimeout(() => console.log("4. タイマーの仕事"), 0);
Promise.resolve().then(() => console.log("3. Promiseの反応"));
console.log("2. 今の処理を終える");

この例の出力は次の順です。

1. 注文する
2. 今の処理を終える
3. Promiseの反応
4. タイマーの仕事

setTimeoutやthenを呼ぶことと、その中の関数が実行されることは別です。タイマーの登録は上にあっても、その関数が今の処理を中断するわけではありません。

今の処理・マイクロタスク・次の仕事を分ける

ブラウザーでは、スクリプト実行やイベント、タイマーなどのタスクと、Promiseの反応などのマイクロタスクを扱います。マイクロタスクの確認時点には、その列が空になるまで処理します。そこで新たにマイクロタスクを増やし続けると、ほかの仕事が進まないことがあります。

図は上の短い例の実行順です。あらゆるAPIを同じ列へ入れる図ではありません。描画はブラウザーの都合も関わり、タスクが1つ終わるごとに必ず画面を更新するという保証もありません。

Node.jsでは、I/Oを扱う段階もある

Node.jsはOSの非同期I/O等を使い、必要に応じて内部のスレッドプールも利用します。すべての非同期処理がスレッドプールへ移るわけではありません。CPUを長く使うJavaScriptの計算は、それを書いた実行スレッドを占有し得ます。

Node.jsのイベントループにはI/Oを待ち受けるpoll、setImmediateを扱うcheck等の段階があります。libuv 1.45.0を使うNode.js 20以降では、ループ各周のタイマー処理はpollの後です。ただしループに入る前にタイマーを1回処理する場合もあります。古い図をそのまま「必ずこの順」と使わないことが大切です。

もう少し詳しく：重い仕事と複数の結果

• 長い計算：計測して分割、アルゴリズムの見直し、Workerの利用を検討します。Node.jsのworker_threadsはCPU中心のJavaScriptの処理に適し、通常の非同期I/Oを何でも置き換えるためのものではありません。
• Promise.all：複数の結果を待つ道具です。1つの拒否で全体が拒否されますが、残りの処理の停止は別途設計します。全結果を知りたい場合はPromise.allSettledが候補になります。
• 順番の調査：ブラウザーかNode.jsか、版、呼び出し場所を合わせます。トップレベルのsetTimeoutとsetImmediateの順番などを、別の場所の結果から一般化しません。

🐧 ペンギン先生のまとめ：「イベントループ」って出てきたら「今の仕事と、後で呼ぶ仕事を進める仕組み」と思えばだいたいOK！

次は、待ち時間の扱いをスレッドプールの仕組み、データの受け渡しをメッセージキューの仕組みで見てみましょう。

参考資料

• Node.js：The Node.js Event Loop — 段階・タイマーとpollの順番・版による変更
• MDN：Microtask guide — タスクとマイクロタスク・追加し続ける場合の問題
• MDN：Promise.all — 結果の集約・拒否とキャンセルの違い
• Node.js：Worker threads — CPU中心の仕事とI/Oの用途の違い