Cơ chế hoạt động của Event Loop trong Trình duyệt

Tóm tắt nhanh (TL;DR)

Event loop điều phối các task, microtask và cơ hội cập nhật giao diện trong trình duyệt. Nếu một microtask liên tục tạo thêm microtask mới, trình duyệt có thể không có cơ hội xử lý tương tác hoặc vẽ khung hình tiếp theo. Để hiểu nguyên nhân, hãy bắt đầu bằng thứ tự thực thi quan sát được, rồi phân biệt những điều được đặc tả với lựa chọn của bộ lập lịch.

💡 Quy tắc bỏ túi: Mã JavaScript đồng bộ trong một task chạy đến khi kết thúc. Khi đến microtask checkpoint, trình duyệt xử lý các microtask đã xếp hàng, kể cả microtask phát sinh trong lúc xử lý. Sau đó event loop có thể chọn task tiếp theo hoặc thực hiện bước cập nhật kết xuất nếu thích hợp. Đừng coi mọi nguồn task là một FIFO toàn cục.

• Call Stack tuân thủ nguyên tắc Run-to-Completion: Đoạn mã JavaScript đồng bộ đang chạy trên ngăn xếp sẽ luôn thực thi trọn vẹn đến cùng mà không bị ngắt quãng bởi bất kỳ callback sự kiện nào khác.
• Microtask Checkpoint luôn vét cạn 100%: Các phản hồi Promise (.then, .catch) và queueMicrotask() được xử lý ngay khi Call Stack trống rỗng. Mọi microtask mới phát sinh trong quá trình này cũng sẽ bị hút vào và xử lý dứt điểm ngay trong cùng một checkpoint.
• Rendering hoàn toàn tách biệt khỏi chu kỳ Task: Trình duyệt không vẽ lại sau mỗi callback. Quá trình cập nhật giao diện diễn ra tại các Rendering Opportunity đồng bộ theo tần số quét màn hình, và requestAnimationFrame() được kích hoạt ngay trước các bước tính toán Style và Layout.
• Macrotasks đến từ nhiều nguồn tác vụ (Task Sources) độc lập: Bộ hẹn giờ (setTimeout), tương tác người dùng và sự kiện mạng nằm trong các hàng đợi riêng biệt do bộ điều phối trình duyệt quản lý, không phải một hàng đợi FIFO đơn lẻ.
• Lỗi dễ gặp (microtask starvation): Một chuỗi microtask liên tục tự thêm việc mới có thể ngăn trình duyệt nhận input và cập nhật giao diện. Muốn chia nhỏ công việc nặng, hãy nhường quyền qua cơ chế scheduling thích hợp thay vì tạo thêm microtask.

Dự đoán thứ tự thực thi từ một ví dụ nhỏ

Trong trang web, đoạn mã sau in gì trước?

console.log("A");
setTimeout(() => console.log("timer"), 0);
Promise.resolve().then(() => console.log("promise"));
console.log("B");

A
B
promise
timer

Hai câu lệnh đồng bộ chạy trước. Handler của Promise chạy trong microtask sau phần mã đồng bộ; callback của timer là một task chạy sau đó. setTimeout(..., 0) không có nghĩa callback được chạy ngay lập tức.

Ba vùng làm việc: Call Stack, Task Queues và Microtask Queue

Chu trình làm việc của Microtask Checkpoint

console.log('Script bắt đầu');

setTimeout(() => {
  console.log('Timer callback');
}, 0);

Promise.resolve().then(() => {
  console.log('Promise microtask 1');
}).then(() => {
  console.log('Promise microtask 2 (lồng nhau)');
});

console.log('Script kết thúc');

Thứ tự in ra màn hình:

Script bắt đầu
Script kết thúc
Promise microtask 1
Promise microtask 2 (lồng nhau)
Timer callback

Timer chỉ hẹn thời điểm sớm nhất

setTimeout(fn, 0) không cam kết callback chạy đúng sau 0 mili-giây: nó vẫn đợi công việc hiện tại hoàn tất, các microtask liên quan và lịch xử lý task của trình duyệt. Trình duyệt còn có chính sách riêng cho timer lồng nhau và tab chạy nền.

Nhiều task source không đồng nghĩa một hàng FIFO

Các task do timer, tương tác người dùng và networking tạo ra có thể thuộc nguồn khác nhau. Thứ tự giữa các nguồn này phụ thuộc vào quy tắc của HTML và lựa chọn của trình duyệt. Vì vậy, không nên khẳng định mọi timer luôn chạy trước hoặc sau mọi sự kiện input. Hãy thể hiện thứ tự bắt buộc bằng quan hệ phụ thuộc rõ ràng.

Promise job trở thành microtask thế nào?

ECMAScript định nghĩa Promise reaction job; môi trường trình duyệt tích hợp việc lên lịch các job đó với microtask checkpoint của HTML. Handler .then() vì thế không chạy đồng bộ khi vừa đăng ký. Đây là mô hình hữu ích để dự đoán trace, nhưng không nên áp dụng nguyên xi sang Node.js vì runtime đó có thêm cơ chế scheduling riêng.

Đường ống kết xuất giao diện (Rendering Pipeline)

Một sai lầm rất phổ biến là nghĩ rằng trình duyệt sẽ vẽ lại màn hình ngay sau mỗi tác vụ hay microtask. Thực tế, việc vẽ lại hoàn toàn độc lập và được điều phối bởi chu kỳ quét của màn hình (Refresh Rate).

Phòng thí nghiệm Event Loop (Interactive Lab)

Trải nghiệm trực quan cách Event Loop điều phối giữa Call Stack, Microtasks, Timers và Rendering Pipeline:

console.log('A');
setTimeout(() => console.log('timer'), 0);
Promise.resolve().then(() => console.log('promise'));
console.log('B');

Hiện tượng đói tài nguyên (Starvation) và đóng băng Main Thread

Tình huống minh họa (giả định): giao diện không phản hồi do microtask

Một ứng dụng web chat realtime xử lý hàng loạt tin nhắn nhận về qua WebSocket. Khi một lô tin nhắn 500 items ùa về, lập trình viên sử dụng một hàm đệ quy để xử lý từng tin nhắn:

function processMessageBatch(messages: Message[]) {
  if (messages.length === 0) return;
  const msg = messages.shift()!;
  renderMessage(msg);
  // Cố gắng "chia nhỏ" bằng queueMicrotask thay vì xử lý loop đồng bộ:
  queueMicrotask(() => processMessageBatch(messages));
}

• Hậu quả: Dù không có một vòng lặp for dài gây blocking Call Stack, UI vẫn bị "đóng băng" suốt 1.2 giây! Người dùng nhấp chuột vào nút "Gửi" hay thanh nhập liệu đều hoàn toàn bất động. Chỉ số INP (Interaction to Next Paint) báo đỏ nghiêm trọng (>1000ms).
• Nguyên nhân cốt lõi: Lập trình viên nhầm lẫn giữa queueMicrotask() và việc nhường luồng (yielding) cho trình duyệt. queueMicrotask() không bao giờ nhường quyền điều khiển cho Task Queue hay Rendering Pipeline; nó tiếp tục giữ chặt checkpoint cho đến khi queue rỗng 100%.
• Cách khắc phục chuẩn: Nếu muốn nhường luồng cho trình duyệt vẽ lại UI và nhận input click, phải đẩy công việc ra Macrotask hoặc sử dụng scheduler chuẩn:

  // Giải pháp hiện đại: scheduler.yield() nếu hỗ trợ, dự phòng sang setTimeout 0
  async function processMessageBatch(messages: Message[]) {
    for (const msg of messages) {
      renderMessage(msg);
      if ('scheduler' in window && 'yield' in (window as any).scheduler) {
        await (window as any).scheduler.yield();
      } else {
        await new Promise((resolve) => setTimeout(resolve, 0));
      }
    }
  }

So sánh Event Loop giữa Trình duyệt và Node.js

Bài tập kiểm tra tư duy

Hãy dự đoán thứ tự in ra console của đoạn mã sau:

console.log('A');

setTimeout(() => {
  console.log('timer');
}, 0);

Promise.resolve().then(() => {
  console.log('promise');

  queueMicrotask(() => {
    console.log('nested microtask');
  });
});

queueMicrotask(() => {
  console.log('queued microtask');
});

console.log('B');

A
B
promise
queued microtask
nested microtask
timer

Checklist rà soát mã nguồn cho Kỹ sư

• Thời lượng tác vụ (Task Duration): Mọi tác vụ trên Main Thread có hoàn thành dưới ngưỡng 50ms (ngưỡng Long Task trong DevTools) không?
• Giới hạn Microtask: Các lời gọi queueMicrotask() hoặc chuỗi Promise đệ quy có điểm dừng rõ ràng để thoát khỏi checkpoint không?
• Không phỏng đoán thứ tự Task Source: Tránh dựa vào giả định rằng timer sẽ luôn chạy trước hay sau một sự kiện người dùng không liên quan.
• Lên lịch hoạt ảnh chuẩn: Các thao tác cập nhật DOM liên tục hoặc animation đã được đưa vào requestAnimationFrame() chưa?
• Phân tách ranh giới môi trường: Đảm bảo không mang các API đặc thù của Node (process.nextTick, setImmediate) sang code chạy trên trình duyệt.

Tài liệu quy chuẩn

• WHATWG HTML Standard — Event Loops — Đặc tả quy chuẩn thế giới về Event Loop, hàng đợi tác vụ và microtask checkpoint trên trình duyệt.
• WHATWG HTML Standard — Timers — quy tắc và độ trễ của timer.
• ECMAScript 2026 — Jobs — Promise jobs và host scheduling.
• W3C Prioritized Task Scheduling API — Đặc tả chuẩn về scheduler.yield() và scheduler.postTask().