Apakah perbezaan antara operasi blocking dan non-blocking dalam Node.js?

Question

IT Interview Practice · Accepted Answer

Operasi **blocking** berjalan secara segerak (synchronous) dan memegang satu-satunya thread JavaScript sehingga ia selesai — tiada apa-apa lain boleh berjalan pada masa itu. Operasi **non-blocking** memulakan kerja, kembali serta-merta, dan menyampaikan hasilnya kemudian melalui callback, Promise, atau event, jadi thread kekal bebas untuk melakukan perkara lain.

## Mengapa Node bersifat single-threaded tetapi non-blocking

JavaScript anda berjalan pada **satu** thread yang dipacu oleh **event loop**. I/O (fail, rangkaian, DNS) diserahkan kepada **libuv**, yang menggunakan kemudahan async OS dan sebuah **thread pool** kecil di sebalik tabir. Sementara kerja itu berlaku di luar thread, event loop terus memproses callback lain. Apabila I/O selesai, callback-nya beratur dan dijalankan.

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

// Blocking: keseluruhan proses menunggu di sini; tiada request lain dilayani.
const data = fs.readFileSync("big.json");
console.log("done reading");

// Non-blocking: kembali serta-merta; callback berjalan apabila I/O selesai.
fs.readFile("big.json", (err, data) => {
  console.log("done reading");
});
console.log("this logs first");
```

## Blocking lawan non-blocking

| | Blocking | Non-blocking |
|---|---|---|
| Gaya API | `*Sync` (`readFileSync`) | callback / Promise / `async` |
| Thread | Memegang event loop | Membebaskan event loop |
| Throughput | Satu request pada satu masa | Banyak request serentak |
| Guna bila | Skrip startup/CLI | Server, request handler |

## Perangkap: kerja CPU-bound masih blocking

Non-blocking hanya membantu dengan **I/O**. Pengiraan segerak yang berat (parsing JSON bagi payload besar, crypto, mengubah saiz imej, gelung ketat) menyekat event loop walaupun di dalam fungsi `async`, kerana kerja CPU itu sendiri berjalan pada thread JS.

```js
// Menyekat event loop sepanjang gelung, walaupun bersifat "async".
async function hash(n) {
  let x = 0;
  for (let i = 0; i < n; i++) x += Math.sqrt(i); // CPU-bound, synchronous
  return x;
}
```

Pindahkan kerja CPU-bound ke **`worker_threads`**, satu child process, atau satu queue supaya event loop kekal responsif:

```js
const { Worker } = require("node:worker_threads");
new Worker("./cpu-task.js"); // berjalan pada thread berasingan
```

## Petua praktikal

- Jangan sesekali panggil API `*Sync` di dalam request handler pada server.
- Guna async I/O di mana-mana pada hot path.
- Pindahkan kerja berat CPU keluar dari thread utama.
- Berhati-hati dengan blocking tidak sengaja: `JSON.parse` besar, crypto segerak, regex dengan catastrophic backtracking.

## Mengapa ia penting

Model prestasi Node bergantung sepenuhnya kepada memastikan satu-satunya thread event loop kekal bebas. Satu panggilan blocking yang tersasar — sebuah `readFileSync`, sebuah hash segerak, sebuah regex perlahan — menghentikan **setiap** request serentak, bukan hanya yang mencetuskannya. Memahami apa yang menyekat dan apa yang tidak ialah perbezaan antara server yang menskala kepada beribu-ribu sambungan dan server yang membeku di bawah beban.

	Blocking	Non-blocking
Gaya API	`*Sync` (`readFileSync`)	callback / Promise / `async`
Thread	Memegang event loop	Membebaskan event loop
Throughput	Satu request pada satu masa	Banyak request serentak
Guna bila	Skrip startup/CLI	Server, request handler

Mengapa Node bersifat single-threaded tetapi non-blocking

Blocking lawan non-blocking

Perangkap: kerja CPU-bound masih blocking

Petua praktikal

Mengapa ia penting

Soalan berkaitan