0Pricing
Node.js Backend Development Bootcamp · Lezione

Perché l’event loop si blocca con il lavoro vincolato dalla CPU

Individui i calcoli bloccanti e comprenda perché JavaScript, essendo single-threaded, richiede thread reali per il parallelismo.

Perché l’event loop si blocca con il lavoro vincolato dalla CPU è una lezione Node.js Backend Development Bootcamp gratuita su CoddyKit. Questa è la lezione 1 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento Node.js Backend Development Bootcamp, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso Node.js Backend Development Bootcamp include 4 lezioni in totale.

Parti di questa lezione non sono ancora state tradotte e vengono mostrate in inglese.

One Thread to Run Them All

Node.js runs your JavaScript on a single thread. Every request handler, timer callback, and promise continuation takes turns executing on that one thread, coordinated by the event loop.

This design is brilliant for I/O-bound work: while you wait for a database query or an HTTP response, the thread is free to handle other requests. The waiting happens elsewhere (in the OS and libuv's thread pool), not in your JavaScript.

But there is a catch. If a single callback decides to do heavy computation, that one thread is busy crunching numbers and nothing else can run until it finishes. In this lesson we explore exactly why CPU-bound work stalls the event loop.

The Event Loop in One Picture

The event loop is a simple idea: a loop that repeatedly pulls the next ready callback from a queue and runs it to completion before pulling the next one.

  • A timer fires → run its callback.
  • A socket has data → run its callback.
  • A promise resolves → run its continuation.

Crucially, callbacks are cooperative: the loop cannot interrupt a callback in the middle. JavaScript has no preemption. Each callback must voluntarily return to give the loop a chance to do anything else.

const server = require('http').createServer((req, res) => {
  // This callback must RETURN quickly so the loop can serve
  // the next request. The loop won't interrupt it midway.
  res.end('ok');
});

server.listen(3000, () => {
  console.log('Listening on http://localhost:3000');
});

I/O-Bound vs CPU-Bound

Understanding the stall starts with classifying work:

  • I/O-bound: most time is spent waiting for an external resource — disk, network, database. The CPU is mostly idle.
  • CPU-bound: most time is spent computing — hashing, image resizing, parsing huge JSON, compression, cryptography, big loops. The CPU is pinned at 100%.

Node's single-threaded model shines for I/O-bound workloads because waiting does not occupy the thread. It struggles with CPU-bound workloads because computing does occupy the thread — and there is only one.

Async I/O Does Not Block

Asynchronous I/O is non-blocking precisely because the heavy waiting is delegated. When you call an async file read, Node hands the work to libuv (and the OS), registers a callback, and immediately returns control to the event loop.

The loop is free to handle thousands of other things while the disk does its job. When the read completes, your callback is queued. The thread never sat idle spinning.

This is the key insight: awaiting I/O is free for the event loop. The thread is released back to do other work.

const fs = require('fs/promises');

async function main() {
  console.log('before read');
  // Control returns to the loop while the disk works.
  const data = await fs.readFile(__filename, 'utf8');
  console.log('read', data.length, 'bytes');
}

main();
console.log('this prints BEFORE the read finishes');

A CPU-Bound Function That Blocks

Now contrast that with computation. A tight loop summing a billion numbers does not wait for anything — it keeps the thread fully occupied from start to finish.

While heavyCompute() runs, the event loop is frozen. No timers fire, no incoming requests are accepted, no promise continuations run. The whole process appears hung until the function returns.

Run this and notice that the program produces no output at all until the loop finishes — there is no point where control returns to the loop mid-computation.

function heavyCompute() {
  let total = 0;
  for (let i = 0; i < 2_000_000_000; i++) {
    total += i;
  }
  return total;
}

console.time('compute');
const result = heavyCompute();
console.timeEnd('compute');
console.log('result =', result);

Proof: Timers Starve During Computation

Here is a direct demonstration of the stall. We schedule a timer for 100ms, then immediately start a CPU-bound loop that takes much longer.

You might expect the timer to fire after 100ms. It does not. The loop is busy computing and cannot interrupt itself to run the timer callback. The timer only fires after the computation returns — often seconds late.

This is the event loop stall in its purest form: a queued callback that is ready to run but is denied the thread.

const start = Date.now();

setTimeout(() => {
  console.log('Timer fired after', Date.now() - start, 'ms (asked for 100)');
}, 100);

// Block the single thread for ~2 seconds.
const end = Date.now() + 2000;
while (Date.now() < end) {
  // busy-wait, no I/O, no yielding
}
console.log('Blocking loop done after', Date.now() - start, 'ms');

async/await Does NOT Help CPU Work

A common misconception: wrapping CPU work in an async function or adding await will make it non-blocking. It will not.

async/await only yields the thread at an actual await point that suspends on a real asynchronous operation (I/O, a timer, a microtask). A pure computation has no such suspension point — it runs synchronously regardless of the async keyword.

In the snippet, marking the function async changes nothing: the loop still blocks for the full duration of the loop.

async function compute() {
  let total = 0;
  // No await inside a hot loop = still fully synchronous.
  for (let i = 0; i < 2_000_000_000; i++) {
    total += i;
  }
  return total;
}

setTimeout(() => console.log('timer wanted at 50ms'), 50);

console.time('compute');
compute().then((r) => {
  console.timeEnd('compute');
  console.log('result =', r);
});

Why This Wrecks a Backend

On a server, one blocked thread means every concurrent client suffers. While one request runs a 3-second CPU task, all other requests queued on that thread wait the full 3 seconds before they are even read.

  • Latency spikes for unrelated endpoints.
  • Health-check pings time out, and orchestrators may kill the "unresponsive" process.
  • Throughput collapses: one core, one task at a time.

The server is not crashed — it is simply monopolized. This is why a single heavy synchronous handler can take down an entire Node service under load.

const http = require('http');

http.createServer((req, res) => {
  if (req.url === '/heavy') {
    let t = 0;
    for (let i = 0; i < 5_000_000_000; i++) t += i; // blocks everyone
    return res.end('done ' + t);
  }
  // /ping cannot respond while /heavy is running on the same thread
  res.end('pong');
}).listen(3000);

Chunking Helps a Little, Not Enough

One partial mitigation is to break the work into chunks and setImmediate between them, letting the loop breathe between slices.

This keeps the server responsive — pings can be answered between chunks — but it does not add parallelism. The computation still runs on the one thread, now interleaved with other callbacks, so the total wall-clock time for the heavy task usually gets longer, not shorter.

Chunking trades latency-for-others against throughput-for-the-task. It cannot use a second CPU core. For true parallelism you need real threads.

function computeChunked(total, i, end, done) {
  const sliceEnd = Math.min(i + 10_000_000, end);
  for (; i < sliceEnd; i++) total += i;
  if (i < end) {
    // Yield to the loop, then continue next tick.
    setImmediate(() => computeChunked(total, i, end, done));
  } else {
    done(total);
  }
}

computeChunked(0, 0, 2_000_000_000, (r) => console.log('result =', r));
setInterval(() => console.log('loop still alive'), 200);

The Real Fix: Move Off the Main Thread

Because JavaScript on the main thread is single-threaded and cooperative, the only way to run CPU-bound work in parallel — using more than one CPU core — is to move it to a separate thread of execution.

Node gives you options:

  • Worker Threads (worker_threads): real OS threads inside the same process, each with its own event loop and V8 isolate. Ideal for CPU-bound tasks.
  • Cluster / child processes: separate processes, more isolation, higher overhead.

The main thread offloads the heavy job, stays responsive to I/O, and collects the result via a message when the worker finishes.

A Worker Thread Keeps the Loop Free

Here is the shape of the solution. The main thread spawns a Worker that runs the heavy computation on a different thread and a different core. The main event loop stays free to serve requests and respond to timers.

When the worker finishes, it posts a message back. The main thread's callback runs that result through the event loop — non-blocking, parallel, and scalable across cores.

This is the foundation of CPU-bound parallelism in Node, which the rest of this course builds on.

const { Worker, isMainThread, parentPort } = require('worker_threads');

if (isMainThread) {
  const worker = new Worker(__filename);
  worker.on('message', (sum) => console.log('worker result =', sum));

  // Main loop is NOT blocked: this timer fires on time.
  setInterval(() => console.log('main thread responsive'), 200);
} else {
  let total = 0;
  for (let i = 0; i < 2_000_000_000; i++) total += i;
  parentPort.postMessage(total);
}

Quick Check

A Node HTTP handler runs a synchronous 4-second image-hashing loop. During those 4 seconds, what happens to a second client hitting a different, lightweight endpoint?

Recap

Key takeaways from this lesson:

  • Node runs JavaScript on a single, cooperative event-loop thread — callbacks run to completion and cannot be interrupted.
  • I/O-bound work is non-blocking because waiting is delegated to libuv/OS; the thread is released.
  • CPU-bound work occupies the thread the entire time, freezing timers, requests, and promise continuations — the event loop stalls.
  • async/await does not help pure computation; it only yields at real asynchronous suspension points.
  • Chunking with setImmediate restores responsiveness but adds no parallelism and cannot use extra cores.
  • The real solution is Worker Threads: move CPU-bound work to a separate thread/core so the main loop stays free.

Domande Frequenti

La lezione «Perché l’event loop si blocca con il lavoro vincolato dalla CPU» è gratuita?

Sì — il testo completo di «Perché l’event loop si blocca con il lavoro vincolato dalla CPU» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso Node.js Backend Development Bootcamp, passa a CoddyKit PRO. Il corso Node.js Backend Development Bootcamp include 4 lezioni in totale.

Cosa imparerò in «Perché l’event loop si blocca con il lavoro vincolato dalla CPU»?

Individui i calcoli bloccanti e comprenda perché JavaScript, essendo single-threaded, richiede thread reali per il parallelismo. Eserciti Node.js Backend Development Bootcamp con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.

Ho bisogno di esperienza per iniziare Node.js Backend Development Bootcamp?

Non è richiesta alcuna esperienza precedente. Node.js Backend Development Bootcamp su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 1 di 4.

Quanto tempo richiede la lezione «Perché l’event loop si blocca con il lavoro vincolato dalla CPU»?

La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.

Posso scrivere ed eseguire codice in questa lezione Node.js Backend Development Bootcamp?

Sì. Ogni lezione Node.js Backend Development Bootcamp include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.

Tutte le lezioni di questo corso

  1. Perché l’event loop si blocca con il lavoro vincolato dalla CPU
  2. Creazione di Worker Thread e passaggio dei messaggi
  3. Condivisione della memoria con SharedArrayBuffer e Atomics
  4. Creazione di un worker pool riutilizzabile per il throughput
← Torna a Node.js Backend Development Bootcamp