0Pricing
Node.js Backend Development Bootcamp · Lección

Por qué el event loop se bloquea con trabajo limitado por CPU

Identifique cálculos bloqueantes y comprenda por qué JavaScript, al ejecutarse en un solo hilo, necesita hilos reales para el paralelismo.

Por qué el event loop se bloquea con trabajo limitado por CPU es una lección gratuita de Node.js Backend Development Bootcamp en CoddyKit. Esta es la lección 1 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de Node.js Backend Development Bootcamp, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de Node.js Backend Development Bootcamp incluye 4 lecciones en total.

Partes de esta lección aún no han sido traducidas y se muestran en inglés.

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.

Preguntas frecuentes

¿La lección «Por qué el event loop se bloquea con trabajo limitado por CPU» es gratis?

Sí — el texto completo de «Por qué el event loop se bloquea con trabajo limitado por CPU» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de Node.js Backend Development Bootcamp, actualiza a CoddyKit PRO. El curso de Node.js Backend Development Bootcamp incluye 4 lecciones en total.

¿Qué aprenderé en «Por qué el event loop se bloquea con trabajo limitado por CPU»?

Identifique cálculos bloqueantes y comprenda por qué JavaScript, al ejecutarse en un solo hilo, necesita hilos reales para el paralelismo. Practicas Node.js Backend Development Bootcamp con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.

¿Necesito experiencia previa para empezar Node.js Backend Development Bootcamp?

No se requiere experiencia previa. Node.js Backend Development Bootcamp en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 1 de 4.

¿Cuánto tiempo toma la lección «Por qué el event loop se bloquea con trabajo limitado por CPU»?

La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.

¿Puedo escribir y ejecutar código en esta lección de Node.js Backend Development Bootcamp?

Sí. Cada lección de Node.js Backend Development Bootcamp incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.

Todas las lecciones de este curso

  1. Por qué el event loop se bloquea con trabajo limitado por CPU
  2. Creación de Worker Threads e intercambio de mensajes
  3. Compartición de memoria con SharedArrayBuffer y Atomics
  4. Construcción de un grupo de workers reutilizable para aumentar el rendimiento
← Volver a Node.js Backend Development Bootcamp