Node.js میں blocking اور non-blocking operations کے درمیان کیا فرق ہے؟

Question

IT Interview Practice · Accepted Answer

**Blocking** operations synchronous چلتے ہیں اور مکمل ہونے تک واحد JavaScript thread کو تھامے رکھتے ہیں — اس دوران کوئی اور چیز نہیں چل سکتی۔ **Non-blocking** operations کام شروع کرتے ہیں، فوراً واپس آ جاتے ہیں، اور نتیجہ بعد میں کسی callback، Promise، یا event کے ذریعے پہنچاتے ہیں، تاکہ thread دوسرے کام کرنے کے لیے آزاد رہے۔

## Node single-threaded ہونے کے باوجود non-blocking کیوں ہے

آپ کی JavaScript ایک **ہی** thread پر چلتی ہے جسے **event loop** چلاتا ہے۔ I/O (files، network، DNS) کو **libuv** کے سپرد کیا جاتا ہے، جو اندرونی طور پر OS کی async سہولیات اور ایک چھوٹا **thread pool** استعمال کرتا ہے۔ جب وہ کام thread سے باہر ہوتا ہے، event loop دیگر callbacks پر عمل کرتا رہتا ہے۔ جب 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 | بیک وقت کئی requests |
| کب استعمال کریں | Startup/CLI scripts | Servers، request handlers |

## پھندا: CPU-bound کام پھر بھی block کرتا ہے

Non-blocking صرف **I/O** میں مدد کرتا ہے۔ ایک بھاری synchronous حساب (بہت بڑے payload کو JSON parse کرنا، crypto، image resizing، ایک تنگ loop) `async` function کے اندر بھی event loop کو block کرتا ہے، کیونکہ CPU کا کام خود JS thread پر چلتا ہے۔

```js
// "async" ہونے کے باوجود پوری loop کے دوران event loop کو block کرتا ہے۔
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 پر چلتا ہے
```

## بنیادی اصول

- کسی server پر request handler کے اندر کبھی `*Sync` APIs کو کال نہ کریں۔
- hot path میں ہر جگہ async I/O استعمال کریں۔
- CPU-بھاری کام کو main thread سے ہٹا دیں۔
- غیر ارادی blocking سے ہوشیار رہیں: بڑا `JSON.parse`، synchronous crypto، catastrophic backtracking والے regexes۔

## یہ کیوں اہم ہے

Node کا کارکردگی ماڈل مکمل طور پر واحد event-loop thread کو آزاد رکھنے پر منحصر ہے۔ ایک بھٹکی ہوئی blocking کال — ایک `readFileSync`، ایک synchronous hash، ایک سست regex — صرف اسے متحرک کرنے والی request کو نہیں، بلکہ **ہر** بیک وقت request کو روک دیتی ہے۔ یہ سمجھنا کہ کیا block کرتا ہے اور کیا نہیں، ہزاروں connections تک scale ہونے والے server اور بوجھ کے تحت جم جانے والے server کے درمیان فرق ہے۔

	Blocking	Non-blocking
API انداز	`*Sync` (`readFileSync`)	callback / Promise / `async`
Thread	event loop کو تھامتا ہے	event loop کو آزاد کرتا ہے
Throughput	ایک وقت میں ایک request	بیک وقت کئی requests
کب استعمال کریں	Startup/CLI scripts	Servers، request handlers

Node single-threaded ہونے کے باوجود non-blocking کیوں ہے

Blocking بمقابلہ non-blocking

پھندا: CPU-bound کام پھر بھی block کرتا ہے

بنیادی اصول

یہ کیوں اہم ہے

متعلقہ سوالات