ความแตกต่างระหว่างการทำงานแบบ blocking และ non-blocking ใน Node.js คืออะไร?

Question

IT Interview Practice · Accepted Answer

การทำงานแบบ **blocking** ทำงานแบบ synchronous และยึดครอง JavaScript thread เดียวไว้จนกว่าจะเสร็จ — ในระหว่างนั้นไม่มีอะไรอื่นทำงานได้ ส่วนการทำงานแบบ **non-blocking** จะเริ่มงาน คืนค่ากลับทันที และส่งผลลัพธ์กลับมาในภายหลังผ่าน callback, Promise หรือ event ดังนั้น thread จึงว่างพอที่จะทำสิ่งอื่นได้

## ทำไม Node จึงเป็น single-threaded แต่ยัง non-blocking

JavaScript ของคุณทำงานบน thread **เดียว** ที่ขับเคลื่อนด้วย **event loop** I/O (ไฟล์ เครือข่าย DNS) จะถูกมอบหมายให้ **libuv** ซึ่งใช้ความสามารถแบบ async ของ OS และ **thread pool** ขนาดเล็กภายใต้ฝากระโปรง ในขณะที่งานนั้นเกิดขึ้นนอก thread event loop ก็ประมวลผล callback อื่น ๆ ต่อไป เมื่อ I/O เสร็จสิ้น callback ของมันจะถูกจัดคิวและรัน

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

// Blocking: ทั้ง process รออยู่ที่นี่ ไม่มี request อื่นได้รับการให้บริการ
const data = fs.readFileSync("big.json");
console.log("done reading");

// Non-blocking: คืนค่ากลับทันที callback รันเมื่อ I/O เสร็จสิ้น
fs.readFile("big.json", (err, data) => {
  console.log("done reading");
});
console.log("this logs first");
```

## Blocking กับ non-blocking

| | Blocking | Non-blocking |
|---|---|---|
| รูปแบบ API | `*Sync` (`readFileSync`) | callback / Promise / `async` |
| Thread | ยึด event loop ไว้ | ปล่อย event loop ให้ว่าง |
| Throughput | ทีละ request | หลาย request พร้อมกัน |
| ใช้เมื่อ | สคริปต์ startup/CLI | เซิร์ฟเวอร์, request handlers |

## กับดัก: งานแบบ CPU-bound ยังคง block อยู่ดี

Non-blocking ช่วยได้เฉพาะกับ **I/O** เท่านั้น การคำนวณแบบ synchronous ที่หนัก (การ JSON parse payload ขนาดใหญ่, crypto, การปรับขนาดรูปภาพ, ลูปที่แน่น) จะ block event loop แม้อยู่ภายในฟังก์ชัน `async` เพราะงาน CPU นั้นเองรันอยู่บน JS thread

```js
// Block event loop ตลอดทั้งลูป แม้จะเป็น "async" ก็ตาม
async function hash(n) {
  let x = 0;
  for (let i = 0; i < n; i++) x += Math.sqrt(i); // CPU-bound, synchronous
  return x;
}
```

ย้ายงานแบบ CPU-bound ไปที่ **`worker_threads`**, child process หรือ queue เพื่อให้ event loop ยังตอบสนองได้:

```js
const { Worker } = require("node:worker_threads");
new Worker("./cpu-task.js"); // รันบน thread แยกต่างหาก
```

## หลักการง่าย ๆ

- อย่าเรียก API `*Sync` ภายใน request handler บนเซิร์ฟเวอร์เด็ดขาด
- ใช้ async I/O ทุกที่ใน hot path
- ย้ายงานที่หนัก CPU ออกจาก main thread
- ระวัง blocking โดยไม่ตั้งใจ: `JSON.parse` ขนาดใหญ่, crypto แบบ synchronous, regex ที่มี catastrophic backtracking

## ทำไมจึงสำคัญ

โมเดลประสิทธิภาพของ Node ขึ้นอยู่กับการรักษา thread ของ event loop เดียวให้ว่างทั้งหมด การเรียก blocking ที่หลงมาเพียงครั้งเดียว — `readFileSync` หนึ่งครั้ง, hash แบบ synchronous หนึ่งครั้ง, regex ที่ช้าหนึ่งตัว — จะทำให้ **ทุก** request ที่ทำงานพร้อมกันหยุดชะงัก ไม่ใช่แค่ request ที่เป็นตัวกระตุ้น การเข้าใจว่าอะไร block และอะไรไม่ block คือความแตกต่างระหว่างเซิร์ฟเวอร์ที่สเกลได้ถึงหลายพันการเชื่อมต่อ กับเซิร์ฟเวอร์ที่ค้างเมื่อรับโหลด

	Blocking	Non-blocking
รูปแบบ API	`*Sync` (`readFileSync`)	callback / Promise / `async`
Thread	ยึด event loop ไว้	ปล่อย event loop ให้ว่าง
Throughput	ทีละ request	หลาย request พร้อมกัน
ใช้เมื่อ	สคริปต์ startup/CLI	เซิร์ฟเวอร์, request handlers

ทำไม Node จึงเป็น single-threaded แต่ยัง non-blocking

Blocking กับ non-blocking

กับดัก: งานแบบ CPU-bound ยังคง block อยู่ดี

หลักการง่าย ๆ

ทำไมจึงสำคัญ

คำถามที่เกี่ยวข้อง