Node.js માં blocking અને non-blocking ઓપરેશન વચ્ચે શું તફાવત છે?

Question

IT Interview Practice · Accepted Answer

**Blocking** ઓપરેશન સિંક્રોનસ રીતે ચાલે છે અને એકમાત્ર JavaScript થ્રેડને તેઓ પૂરા ન થાય ત્યાં સુધી પકડી રાખે છે — તે દરમિયાન બીજું કંઈ ચાલી શકતું નથી. **Non-blocking** ઓપરેશન કામ શરૂ કરે છે, તરત જ પાછું ફરે છે, અને પરિણામ પછીથી callback, Promise, અથવા event દ્વારા પહોંચાડે છે, જેથી થ્રેડ બીજી વસ્તુઓ કરવા માટે મુક્ત રહે છે.

## Node સિંગલ-થ્રેડેડ હોવા છતાં 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: આખી પ્રક્રિયા અહીં રાહ જુએ છે; બીજી કોઈ વિનંતી પૂરી પડાતી નથી.
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 ને મુક્ત કરે છે |
| થ્રૂપુટ | એક સમયે એક વિનંતી | ઘણી સમાંતર વિનંતીઓ |
| ક્યારે વાપરવું | સ્ટાર્ટઅપ/CLI સ્ક્રિપ્ટ | સર્વર, વિનંતી હેન્ડલર |

## ફાંદો: CPU-bound કામ હજી પણ block કરે છે

Non-blocking માત્ર **I/O** માં જ મદદ કરે છે. ભારે સિંક્રોનસ ગણતરી (વિશાળ payload નું JSON પાર્સિંગ, ક્રિપ્ટો, ઇમેજ રિસાઇઝિંગ, ચુસ્ત લૂપ) `async` ફંક્શનની અંદર પણ event loop ને block કરે છે, કારણ કે CPU નું કામ પોતે JS થ્રેડ પર ચાલે છે.

```js
// "async" હોવા છતાં આખા લૂપ દરમિયાન event loop ને block કરે છે.
async function hash(n) {
  let x = 0;
  for (let i = 0; i < n; i++) x += Math.sqrt(i); // CPU-bound, સિંક્રોનસ
  return x;
}
```

CPU-bound કામને **`worker_threads`**, ચાઇલ્ડ પ્રોસેસ, અથવા કતારમાં ખસેડો જેથી event loop પ્રતિભાવશીલ રહે:

```js
const { Worker } = require("node:worker_threads");
new Worker("./cpu-task.js"); // અલગ થ્રેડ પર ચાલે છે
```

## અંગૂઠાના નિયમો

- સર્વર પર વિનંતી હેન્ડલરની અંદર ક્યારેય `*Sync` API ને કૉલ ન કરો.
- હોટ પાથ (hot path) પર બધે async I/O વાપરો.
- CPU-ભારે કામને મુખ્ય થ્રેડમાંથી ખસેડો.
- આકસ્મિક blocking થી સાવધ રહો: મોટું `JSON.parse`, સિંક્રોનસ ક્રિપ્ટો, વિનાશક બેકટ્રેકિંગ વાળા regex.

## આ શા માટે મહત્વનું છે

Node નું પર્ફોર્મન્સ મોડલ સંપૂર્ણપણે એકમાત્ર event-loop થ્રેડને મુક્ત રાખવા પર આધાર રાખે છે. એક ભટકેલો blocking કૉલ — એક `readFileSync`, એક સિંક્રોનસ hash, એક ધીમો regex — તેને ટ્રિગર કરનારી માત્ર એક જ નહીં પણ **દરેક** સમાંતર વિનંતીને અટકાવી દે છે. શું block કરે છે અને શું નથી કરતું તે સમજવું એ હજારો કનેક્શન સુધી સ્કેલ થતા સર્વર અને લોડ હેઠળ થીજી જતા સર્વર વચ્ચેનો તફાવત છે.

	Blocking	Non-blocking
API શૈલી	`*Sync` (`readFileSync`)	callback / Promise / `async`
થ્રેડ	event loop ને પકડી રાખે છે	event loop ને મુક્ત કરે છે
થ્રૂપુટ	એક સમયે એક વિનંતી	ઘણી સમાંતર વિનંતીઓ
ક્યારે વાપરવું	સ્ટાર્ટઅપ/CLI સ્ક્રિપ્ટ	સર્વર, વિનંતી હેન્ડલર

Node સિંગલ-થ્રેડેડ હોવા છતાં non-blocking કેમ છે

Blocking vs non-blocking

ફાંદો: CPU-bound કામ હજી પણ block કરે છે

અંગૂઠાના નિયમો

આ શા માટે મહત્વનું છે

સંબંધિત પ્રશ્નો