Blocking và non-blocking trong Node.js khác nhau như thế nào?

Question

IT Interview Practice · Accepted Answer

Tác vụ **blocking** (chặn) chạy đồng bộ và giữ luồng JavaScript duy nhất cho tới khi xong — trong lúc đó không gì khác chạy được. Tác vụ **non-blocking** (không chặn) khởi động công việc, trả về ngay, rồi trả kết quả sau qua callback, Promise hoặc event, nên luồng vẫn rảnh để làm việc khác.

## Vì sao Node đơn luồng nhưng vẫn non-blocking

JavaScript của bạn chạy trên **một** luồng do **event loop** điều khiển. I/O (file, mạng, DNS) được ủy thác cho **libuv** — thứ dùng cơ chế bất đồng bộ của hệ điều hành và một **thread pool** nhỏ bên dưới. Trong khi công việc đó diễn ra ngoài luồng, event loop tiếp tục xử lý các callback khác. Khi I/O xong, callback của nó được xếp hàng và chạy.

```js
const fs = require("node:fs");

// Blocking: cả tiến trình đợi ở đây; không request nào khác được phục vụ.
const data = fs.readFileSync("big.json");
console.log("done reading");

// Non-blocking: trả về ngay; callback chạy khi I/O xong.
fs.readFile("big.json", (err, data) => {
  console.log("done reading");
});
console.log("this logs first");
```

## Blocking vs non-blocking

| | Blocking | Non-blocking |
|---|---|---|
| Kiểu API | `*Sync` (`readFileSync`) | callback / Promise / `async` |
| Luồng | Giữ event loop | Giải phóng event loop |
| Thông lượng | Một request tại một thời điểm | Nhiều request đồng thời |
| Dùng khi | Script khởi động/CLI | Server, request handler |

## Cái bẫy: tác vụ CPU-bound vẫn chặn

Non-blocking chỉ giúp với **I/O**. Một phép tính đồng bộ nặng (parse JSON payload khổng lồ, crypto, resize ảnh, vòng lặp dày) vẫn chặn event loop ngay cả bên trong hàm `async`, vì bản thân phần tính toán CPU chạy trên luồng JS.

```js
// Chặn event loop suốt vòng lặp, dù được đánh dấu "async".
async function hash(n) {
  let x = 0;
  for (let i = 0; i < n; i++) x += Math.sqrt(i); // CPU-bound, đồng bộ
  return x;
}
```

Hãy đẩy tác vụ CPU-bound sang **`worker_threads`**, một child process, hoặc một queue để event loop luôn phản hồi:

```js
const { Worker } = require("node:worker_threads");
new Worker("./cpu-task.js"); // chạy trên luồng riêng
```

## Nguyên tắc thực hành

- Đừng bao giờ gọi API `*Sync` bên trong request handler của server.
- Dùng I/O bất đồng bộ ở mọi nơi trên đường đi nóng (hot path).
- Đẩy công việc nặng CPU ra khỏi luồng chính.
- Cảnh giác blocking vô tình: `JSON.parse` lớn, crypto đồng bộ, regex backtracking thảm họa.

## Tại sao điều này quan trọng

Mô hình hiệu năng của Node phụ thuộc hoàn toàn vào việc giữ cho luồng event loop duy nhất luôn rảnh. Chỉ một lời gọi blocking lạc lối — một `readFileSync`, một phép hash đồng bộ, một regex chậm — sẽ làm treo **mọi** request đồng thời, không chỉ request gây ra nó. Hiểu cái gì chặn và cái gì không là ranh giới giữa một server mở rộng tới hàng nghìn kết nối và một server đơ khi tải cao.

	Blocking	Non-blocking
Kiểu API	`*Sync` (`readFileSync`)	callback / Promise / `async`
Luồng	Giữ event loop	Giải phóng event loop
Thông lượng	Một request tại một thời điểm	Nhiều request đồng thời
Dùng khi	Script khởi động/CLI	Server, request handler

Vì sao Node đơn luồng nhưng vẫn non-blocking

Blocking vs non-blocking

Cái bẫy: tác vụ CPU-bound vẫn chặn

Nguyên tắc thực hành

Tại sao điều này quan trọng

Câu hỏi liên quan