Node.js event loop nasıl çalışıyor ve mikro görev kuyruğu ne zaman işlenir?

29 Eki 12:00

In Node’s single‑threaded model the micro‑task queue (Promise callbacks, `process.nextTick`) is drained **after every phase** of the libuv event loop, not just after the “poll” phase like many people assume. Think of it like the browser’s event loop: after each macrotask (timers, I/O callbacks, poll, check, close) Node runs a full micro‑task drain before moving on to the next phase. This means a `Promise.then` scheduled inside a timer will run **before** the next timer or I/O callback, but **after** the current phase’s callbacks have finished. Because the micro‑task queue is processed so aggressively, long‑running synchronous code can starve it – the entire loop stalls until that block returns, and all pending micro‑tasks sit idle. That’s why a CPU‑heavy loop or a big `JSON.parse` can make your promises feel “slower” than the same code in a browser where the UI thread can still repaint. To keep the loop responsive you should: break heavy work into smaller chunks (e.g., `setImmediate` or `worker_threads`), prefer `process.nextTick` only for truly critical next‑tick work (it runs before I/O callbacks, so overusing it can starve the poll phase), and keep promise chains shallow. If you need to bump micro‑task priority, wrap the callback in `process.nextTick`—it will run before the regular micro‑task drain, but use it sparingly to avoid starving I/O. Compared to Deno’s event loop (which follows the same spec but isolates tasks in separate isolates), Node gives you more knobs (`setImmediate`, `nextTick`) to fine‑tune when micro‑tasks run, so leveraging those correctly is the key to predictable performance.