Chạy một vài dòng với setTimeout và một lời hứa, thứ tự đầu ra có thể làm bạn ngạc nhiên. Vòng lặp sự kiện JavaScript giải thích lý do. Đây là cơ chế cho phép ngôn ngữ đơn luồng xử lý bộ tính giờ, cuộc gọi mạng và số lần nhấp mà không bị treo.

Một khi bạn hiểu nó, cả một nhóm lỗi khó hiểu sẽ bắt đầu có ý nghĩa. Chúng tôi đã chạy từng ví dụ trên Node.js 24 và kết quả đầu ra là từ lần chạy đó. Các quy tắc đặt hàng cốt lõi cũng được áp dụng trong các trình duyệt và chúng tôi chỉ ra điểm khác biệt của Node.js. Bạn sẽ thu được nhiều lợi ích hơn từ việc này nếu bạn đã biết kiến ​​thức cơ bản về lời hứa JavaScript.

Tại sao vòng lặp sự kiện tồn tại

JavaScript thực thi mã của bạn trên một luồng chính, do đó chỉ có một đoạn mã chạy tại một thời điểm. Nếu nó chỉ đợi một yêu cầu mạng, một trang sẽ đóng băng cho đến khi có phản hồi.

Vì vậy, JavaScript không chờ đợi. Công việc chậm được chuyển sang môi trường máy chủ, nghĩa là trình duyệt hoặc Node.js, có thể xử lý nó ở chế độ nền. Khi công việc đó kết thúc, một cuộc gọi lại sẽ được đưa vào hàng đợi. Công việc của vòng lặp sự kiện là di chuyển các cuộc gọi lại được xếp hàng đợi vào ngăn xếp khi nó rảnh.

Hãy nghĩ đến một đầu bếp làm việc một mình. Đầu bếp đặt món ăn vào lò nướng và hẹn giờ thay vì nhìn chằm chằm vào nó. Khi đồng hồ reo, nhiệm vụ sẽ được đưa vào danh sách và đầu bếp sẽ thực hiện nó sau khi hoàn thành những gì hiện có trong tay.

Các bộ phận chuyển động

Nhiệm vụ đôi khi được gọi là nhiệm vụ vĩ mô. Nói đúng ra, có thể có một số nguồn nhiệm vụ và chi tiết chính xác khác nhau giữa các môi trường.

Các quy tắc

1. Chạy tất cả mã đồng bộ cho đến khi ngăn xếp cuộc gọi trống.
2. Chạy tất cả vi nhiệm vụ, bao gồm mọi nhiệm vụ mới được thêm vào trong quá trình thực hiện.
3. Trong trình duyệt, hiển thị bản cập nhật nếu đến hạn.
4. Lấy một nhiệm vụ từ hàng đợi và chạy nó.
5. Quay lại bước 2.

Chi tiết quan trọng nhất: tất cả nhiệm vụ vi mô, sau đó là một nhiệm vụ. Hầu hết các câu đố về vòng lặp sự kiện đều được giải bằng cách áp dụng quy tắc duy nhất đó.

Xem thứ tự

console.log("1 sync");
setTimeout(() => console.log("5 timeout"), 0);
Promise.resolve().then(() => console.log("3 promise"));
queueMicrotask(() => console.log("4 microtask"));
console.log("2 sync");

// 1 sync
// 2 sync
// 3 promise
// 4 microtask
// 5 timeout

Đây là những gì đã xảy ra. Hai dòng console.log đồng bộ nên chạy trước. Lệnh gọi lại lời hứa và queueMicrotask đã đi vào hàng đợi vi nhiệm và chúng chạy ngay khi ngăn xếp trống, theo thứ tự chúng được thêm vào. Cuộc gọi lại hẹn giờ phải chờ đến lượt nhiệm vụ, mặc dù độ trễ của nó bằng 0.

Microtask chạy giữa các bộ tính giờ

Sau mỗi tác vụ, hàng đợi vi tác vụ lại được làm trống. Ví dụ này chứng minh điều đó:

setTimeout(() => {
  console.log("timer 1");
  Promise.resolve().then(() => console.log("promise inside timer 1"));
}, 0);
setTimeout(() => console.log("timer 2"), 0);

// timer 1
// promise inside timer 1
// timer 2

Lời hứa được tạo trong bộ tính giờ đầu tiên đã chạy trước bộ tính giờ thứ hai. Các trình duyệt hiện đại và Node.js 11 trở lên hoạt động theo cách này.

Nơi chờ đợi phù hợp

await chia một hàm thành hai. Mọi thứ trước khi chạy đồng bộ và mọi thứ sau khi được lên lịch dưới dạng microtask. Điều này khiến nhiều người ngạc nhiên:

async function task() {
  console.log("A before await");
  await null;
  console.log("C after await");
}

task();
console.log("B after calling task");

// A before await
// B after calling task
// C after await

Chức năng async không khởi động ở chế độ nền. Nó chạy trên cùng một luồng cho đến khi đạt đến luồng đầu tiên await. Điều đó thậm chí còn được áp dụng khi chờ đợi một điều gì đó không phải là một lời hứa thực sự, chẳng hạn như null. Xem Hướng dẫn chờ đợi/không đồng bộ JavaScript của chúng tôi để biết thêm về cú pháp này.

Chặn vòng lặp

Trong khi mã đồng bộ chạy, không có gì khác có thể làm được. Để hiển thị điều này, chúng tôi đặt bộ hẹn giờ trong 0 mili giây, sau đó giữ cho luồng bận trong nửa giây:

const start = Date.now();
setTimeout(() => console.log("timer ran after", Date.now() - start, "ms"), 0);
while (Date.now() - start < 500) {}

// timer ran after about 500 ms

Độ trễ của bộ hẹn giờ là tối thiểu, không phải là sự đảm bảo. Nó chỉ chạy khi ngăn xếp trở nên trống. Trên một trang web, vòng lặp dài như thế này có nghĩa là các lần nhấp chuột không phản hồi và hoạt ảnh sẽ dừng lại. Trên máy chủ, mọi yêu cầu khác đều phải chờ, đó là lý do tại sao một cuộc gọi đồng bộ chậm có thể gây tổn hại cho tất cả người dùng quy trình Node.js.

Các nguyên nhân phổ biến của việc chặn bao gồm các vòng lặp lớn, phân tích cú pháp JSON rất lớn, các hàm tệp đồng bộ như readFileSync trong trình xử lý yêu cầu và các biểu thức chính quy thảm khốc.

Luôn đáp ứng

Đối với công việc nặng nhọc, hãy cho vòng lặp sự kiện một cơ hội để thở. Một cách là thỉnh thoảng tạm dừng đồng hồ hẹn giờ để cho phép các tác vụ khác chạy:

const items = [0, 1, 2, 3, 4];

async function processAll() {
  for (const item of items) {
    if (item === 2) await new Promise((r) => setTimeout(r, 0));
    console.log("item", item);
  }
}

setTimeout(() => console.log("other work gets a turn"), 0);
processAll();

// item 0
// item 1
// other work gets a turn
// item 2
// item 3
// item 4

Đồng hồ hẹn giờ khác chạy ở giữa vì chúng tôi đã thực hiện một nhiệm vụ thực sự. Mã thực sẽ mang lại rất nhiều mục hoặc mili giây. Đối với công việc thực sự nặng về CPU, chẳng hạn như xử lý hình ảnh, hãy sử dụng Web Worker trong trình duyệt hoặc luồng công việc trong Node.js, chạy trên các luồng riêng biệt.

Thiếu nhiệm vụ vi mô

Vì vòng lặp làm trống hoàn toàn hàng đợi vi nhiệm vụ trước khi tiếp tục, nên một vi nhiệm vụ tiếp tục lên lịch nhiều hơn có thể dừng mọi thứ khác. Chúng tôi đã thử nghiệm điều này với 100.000 nhiệm vụ vi mô được xâu chuỗi:

let count = 0;
let timerFired = false;
setTimeout(() => { timerFired = true; }, 0);

function spin() {
  count++;
  if (count < 100000) queueMicrotask(spin);
  else console.log("timer fired during microtasks?", timerFired);
}
queueMicrotask(spin);

// timer fired during microtasks? false

Bộ hẹn giờ không thể chạy cho đến khi tất cả chúng được hoàn thành. Nếu chuỗi đó không bao giờ kết thúc, bộ hẹn giờ sẽ không bao giờ kích hoạt và trong trình duyệt, trang sẽ không bao giờ được sơn lại. Lưu ý rằng việc thực hiện await đối với một lời hứa đã được giải quyết không giúp ích gì ở đây vì nó chỉ bổ sung thêm một vi nhiệm khác. Bạn cần một nhiệm vụ thực tế, chẳng hạn như đồng hồ bấm giờ, để giao việc cho người khác.

Hiển thị trong trình duyệt

Một trình duyệt thường có cơ hội vẽ giữa các tác vụ. Điều đó giải thích một lỗi phổ biến:

spinner.hidden = false;
doHeavyWork();              // blocks the thread
spinner.hidden = true;

Công cụ quay vòng không bao giờ xuất hiện vì trình duyệt không có cơ hội hiển thị giữa các dòng đó. Để khắc phục, hãy để một khung đi qua trước khi công việc nặng bắt đầu hoặc chuyển công việc đó cho một công nhân. Đối với mã thay đổi hình ảnh, requestAnimationFrame chạy ngay trước lần vẽ tiếp theo, điều này khiến nó trở thành công cụ phù hợp cho hoạt ảnh.

Sự khác biệt của Node.js

Node.js có vòng lặp sự kiện riêng với nhiều giai đoạn, bao gồm bộ tính giờ, bỏ phiếu I/O và setImmediate. Nó cũng có process.nextTick, chạy trong hàng đợi riêng của nó. Đây là những gì chúng ta thấy khi chạy chúng từ bên trong một hàm async:

setTimeout(() => console.log("timeout"), 0);
setImmediate(() => console.log("immediate"));
process.nextTick(() => console.log("nextTick"));
Promise.resolve().then(() => console.log("promise"));

// promise
// nextTick
// immediate
// timeout

Nhiều bài báo nói rằng nextTick luôn đánh bại những lời hứa và đồng hồ bấm giờ sẽ đánh bại setImmediate. Kết quả của chúng tôi cho thấy nó không đơn giản như vậy. Mã của chúng tôi đã chạy trong một microtask, vì vậy hàng đợi lời hứa sẽ được thực hiện trước tiên. Và thứ tự của setTimeout và setImmediate được biết là khác nhau tùy thuộc vào nơi chúng được gọi. Vì vậy, đừng viết mã phụ thuộc vào thứ tự chính xác của chúng. Nếu điều này phải xảy ra sau điều khác, hãy xâu chuỗi chúng một cách rõ ràng.

Bài kiểm tra phỏng vấn

Cố gắng sắp xếp thứ tự trước khi đọc câu trả lời:

console.log("a");
setTimeout(() => console.log("b"), 0);
Promise.resolve().then(() => {
  console.log("c");
  setTimeout(() => console.log("d"), 0);
  Promise.resolve().then(() => console.log("e"));
});
console.log("f");

Cuộc chạy của chúng tôi đã in ra a, f, c, e, b, d. Đây là lý do tại sao:

1. a và f là đồng bộ nên chúng chạy trước.
2. Ngăn xếp trống nên các tác vụ vi mô sẽ chạy: c, sau đó là vi tác vụ mới e, trong cùng một vòng.
3. Bây giờ có một tác vụ: bộ đếm thời gian b, được xếp hàng đầu tiên.
4. Sau đó, nhiệm vụ tiếp theo: bộ đếm thời gian d, được xếp hàng đợi trong microtask.

Những lỗi thường gặp

• Suy nghĩ setTimeout là chính xác. Độ trễ chỉ ở mức tối thiểu.
• Suy nghĩ async nghĩa là một luồng khác. Mã không đồng bộ vẫn chạy trên luồng chính giữa các lần chờ.
• Sử dụng chế độ ngủ để khắc phục thứ tự. Chờ đợi theo điều kiện thực tế đáng tin cậy hơn nhiều, điều này cũng áp dụng cho kiểm tra không ổn định.
• Sử dụng forEach với await. Nó không chờ đợi giữa các mục. Xem Các phương thức mảng JavaScript.
• Thực hiện công việc đồng bộ nặng nề trong trình xử lý máy chủ. Một yêu cầu có thể trì hoãn mọi yêu cầu khác.

Lời kết

Hãy nhớ quy tắc cốt lõi: chạy ngăn xếp cho đến khi trống, chạy tất cả các vi tác vụ, sau đó chạy một tác vụ và lặp lại. Mọi thứ khác đều theo sau nó. Để làm cho nó dễ hiểu, hãy viết phiên bản bài kiểm tra ở trên của riêng bạn, dự đoán kết quả ra giấy và sau đó thực hiện nó. Việc mắc sai lầm và hiểu được lý do tại sao sẽ dạy cho bạn nhiều điều hơn bất kỳ sơ đồ nào.

Câu hỏi thường gặp

Tiếp tục học hỏi