Node.js में blocking और non-blocking ऑपरेशन के बीच क्या अंतर है?

Question

IT Interview Practice · Accepted Answer

**Blocking** ऑपरेशन synchronous रूप से चलते हैं और एकमात्र JavaScript थ्रेड को तब तक रोके रखते हैं जब तक वे पूरे न हो जाएं — इस बीच और कुछ नहीं चल सकता। **Non-blocking** ऑपरेशन काम शुरू करते हैं, तुरंत लौट आते हैं, और परिणाम बाद में callback, Promise, या event के ज़रिए पहुँचाते हैं, जिससे थ्रेड अन्य काम करने के लिए मुक्त रहता है।

## Node single-threaded होने के बावजूद non-blocking क्यों है

आपका JavaScript **एक** थ्रेड पर चलता है जिसे **event loop** चलाता है। I/O (फ़ाइलें, नेटवर्क, DNS) **libuv** को सौंपा जाता है, जो पर्दे के पीछे OS की async सुविधाओं और एक छोटे **thread pool** का उपयोग करता है। जब वह काम थ्रेड से बाहर होता है, तब event loop अन्य callbacks को प्रोसेस करता रहता है। जब I/O पूरा होता है, तो उसका callback कतार में डाला जाता है और चलाया जाता है।

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

// Blocking: पूरी प्रक्रिया यहाँ प्रतीक्षा करती है; कोई अन्य request सर्व नहीं होती।
const data = fs.readFileSync("big.json");
console.log("done reading");

// Non-blocking: तुरंत लौटता है; I/O पूरा होने पर callback चलता है।
fs.readFile("big.json", (err, data) => {
  console.log("done reading");
});
console.log("this logs first");
```

## Blocking vs non-blocking

| | Blocking | Non-blocking |
|---|---|---|
| API शैली | `*Sync` (`readFileSync`) | callback / Promise / `async` |
| थ्रेड | event loop को रोके रखता है | event loop को मुक्त करता है |
| थ्रूपुट | एक समय में एक request | कई समवर्ती requests |
| कब उपयोग करें | Startup/CLI स्क्रिप्ट | सर्वर, request handler |

## जाल: CPU-bound काम फिर भी block करता है

Non-blocking केवल **I/O** में मदद करता है। एक भारी synchronous गणना (विशाल payload का JSON parsing, crypto, image resizing, कसा हुआ loop) `async` फ़ंक्शन के अंदर भी event loop को block करती है, क्योंकि CPU का काम स्वयं JS थ्रेड पर चलता है।

```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"); // अलग थ्रेड पर चलता है
```

## अंगूठे के नियम

- सर्वर पर request handler के अंदर कभी भी `*Sync` API को कॉल न करें।
- हॉट पाथ (hot path) में हर जगह async I/O का उपयोग करें।
- CPU-भारी काम को मुख्य थ्रेड से हटा दें।
- आकस्मिक blocking से सावधान रहें: बड़ा `JSON.parse`, synchronous crypto, विनाशकारी backtracking वाले regex।

## यह क्यों महत्वपूर्ण है

Node का performance मॉडल पूरी तरह से एकमात्र event-loop थ्रेड को मुक्त रखने पर निर्भर करता है। एक भटका हुआ blocking कॉल — एक `readFileSync`, एक synchronous hash, एक धीमा regex — केवल उस एक request को नहीं, बल्कि **हर** समवर्ती request को रोक देता है जिसने इसे ट्रिगर किया। क्या block करता है और क्या नहीं, यह समझना ही उस सर्वर के बीच का अंतर है जो हज़ारों कनेक्शन तक स्केल करता है और उस सर्वर के बीच जो लोड के तहत जम जाता है।

	Blocking	Non-blocking
API शैली	`*Sync` (`readFileSync`)	callback / Promise / `async`
थ्रेड	event loop को रोके रखता है	event loop को मुक्त करता है
थ्रूपुट	एक समय में एक request	कई समवर्ती requests
कब उपयोग करें	Startup/CLI स्क्रिप्ट	सर्वर, request handler

Node single-threaded होने के बावजूद non-blocking क्यों है

Blocking vs non-blocking

जाल: CPU-bound काम फिर भी block करता है

अंगूठे के नियम

यह क्यों महत्वपूर्ण है

संबंधित प्रश्न