Ejecute algunas líneas con setTimeout y una promesa, y el orden de salida puede sorprenderlo. El bucle de eventos de JavaScript explica por qué. Es el mecanismo que permite que un lenguaje de subproceso único maneje temporizadores, llamadas de red y clics sin congelarse.

Una vez que lo comprendes, toda una clase de errores confusos empiezan a tener sentido. Ejecutamos cada ejemplo en Node.js 24 y el resultado proviene de esa ejecución. Las reglas básicas de ordenamiento también se aplican en los navegadores, y señalamos en qué se diferencia Node.js. Obtendrá más de esto si ya conoce los conceptos básicos de las promesas de JavaScript.

Por qué existe el bucle de eventos

JavaScript ejecuta su código en un hilo principal, por lo que solo se ejecuta una parte a la vez. Si simplemente esperara una solicitud de red, una página se congelaría hasta que llegara la respuesta.

Entonces JavaScript no espera. El trabajo lento se entrega al entorno host, es decir, al navegador o Node.js, que puede manejarlo en segundo plano. Cuando finaliza ese trabajo, se coloca una devolución de llamada en una cola. El trabajo del bucle de eventos es mover las devoluciones de llamadas en cola a la pila cuando esté libre.

Piense en un chef trabajando solo. El chef mete un plato en el horno y pone un cronómetro, en lugar de mirarlo fijamente. Cuando suena el cronómetro, la tarea pasa a una lista y el chef la retoma después de terminar lo que tiene actualmente entre manos.

las partes moviles

Las tareas a veces se denominan macrotareas. Estrictamente hablando, puede haber varios orígenes de tareas y los detalles exactos difieren entre entornos.

las reglas

1. Ejecute todo el código sincrónico hasta que la pila de llamadas esté vacía.
2. Ejecute todas las microtareas, incluidas las nuevas que se agreguen a lo largo del camino.
3. En un navegador, genere una actualización si es necesario.
4. Tome una tarea de una cola y ejecútela.
5. Vuelva al paso 2.

El detalle más importante: todas microtareas, luego una tarea. La mayoría de los acertijos de bucles de eventos se resuelven aplicando esa única regla.

ver el pedido

console.log("1 sync");
setTimeout(() => console.log("5 timeout"), 0);
Promise.resolve().then(() => console.log("3 promise"));
queueMicrotask(() => console.log("4 microtask"));
console.log("2 sync");

// 1 sync
// 2 sync
// 3 promise
// 4 microtask
// 5 timeout

Esto es lo que pasó. Las dos líneas console.log son ​​sincrónicas, por lo que se ejecutaron primero. La devolución de llamada de promesa y queueMicrotask entraron en la cola de microtareas y se ejecutaron tan pronto como la pila estuvo vacía, en el orden en que se agregaron. La devolución de llamada del temporizador tuvo que esperar un turno de tarea, aunque su retraso era cero.

Las microtareas se ejecutan entre temporizadores

Después de cada tarea, la cola de microtareas se vacía nuevamente. Este ejemplo lo demuestra:

setTimeout(() => {
  console.log("timer 1");
  Promise.resolve().then(() => console.log("promise inside timer 1"));
}, 0);
setTimeout(() => console.log("timer 2"), 0);

// timer 1
// promise inside timer 1
// timer 2

La promesa, que se creó durante el primer cronómetro, se ejecutó antes del segundo cronómetro. Los navegadores modernos y Node.js 11 y posteriores se comportan de esta manera.

donde cabe la espera

await divide una función en dos. Todo lo anterior se ejecuta de forma sincrónica y todo lo posterior se programa como una microtarea. Esto sorprende a mucha gente:

async function task() {
  console.log("A before await");
  await null;
  console.log("C after await");
}

task();
console.log("B after calling task");

// A before await
// B after calling task
// C after await

Una función async no se inicia en segundo plano. Se ejecuta en el mismo hilo hasta llegar al primero await. Esto se aplica incluso cuando se espera algo que no es una promesa real, como null. Consulte nuestra guía JavaScript async/await para obtener más información sobre esta sintaxis.

Bloqueando el bucle

Mientras se ejecuta el código sincrónico, nada más puede hacerlo. Para mostrar esto, configuramos un temporizador de 0 ms y luego mantuvimos el hilo ocupado durante medio segundo:

const start = Date.now();
setTimeout(() => console.log("timer ran after", Date.now() - start, "ms"), 0);
while (Date.now() - start < 500) {}

// timer ran after about 500 ms

El retraso del temporizador es un mínimo, no una garantía. Se ejecutó sólo cuando la pila quedó libre. En una página web, un bucle largo como este significa que los clics no responden y las animaciones se detienen. En un servidor, todas las demás solicitudes tienen que esperar, por lo que una llamada síncrona lenta puede perjudicar a todos los usuarios de un proceso Node.js.

Las causas comunes de bloqueo incluyen bucles enormes, análisis de JSON muy grandes, funciones de archivos sincrónicos como readFileSync en controladores de solicitudes y expresiones regulares catastróficas.

Mantenerse receptivo

Para trabajos pesados, déle al bucle de eventos la oportunidad de respirar. Una forma es hacer una pausa en un temporizador de vez en cuando, lo que permite ejecutar otras tareas:

const items = [0, 1, 2, 3, 4];

async function processAll() {
  for (const item of items) {
    if (item === 2) await new Promise((r) => setTimeout(r, 0));
    console.log("item", item);
  }
}

setTimeout(() => console.log("other work gets a turn"), 0);
processAll();

// item 0
// item 1
// other work gets a turn
// item 2
// item 3
// item 4

El otro cronómetro corrió a la mitad, porque cedimos con una tarea real. El código real produciría cada cierto número de elementos o milisegundos. Para trabajos que realmente requieren mucha CPU, como el procesamiento de imágenes, utilice un Web Worker en los navegadores o un subproceso de trabajo en Node.js, que se ejecutan en subprocesos separados.

Hambre de microtareas

Dado que el bucle vacía completamente la cola de microtareas antes de continuar, una microtarea que sigue programando más puede detener todo lo demás. Probamos esto con 100.000 microtareas encadenadas:

let count = 0;
let timerFired = false;
setTimeout(() => { timerFired = true; }, 0);

function spin() {
  count++;
  if (count < 100000) queueMicrotask(spin);
  else console.log("timer fired during microtasks?", timerFired);
}
queueMicrotask(spin);

// timer fired during microtasks? false

El cronómetro no pudo correr hasta que todos terminaron. Si esa cadena nunca terminara, los temporizadores nunca se activarían y, en un navegador, la página nunca se volvería a pintar. Tenga en cuenta que ceder con await en una promesa resuelta no ayuda aquí, porque solo agrega otra microtarea. Necesitas una tarea real, como un cronómetro, para darle un turno a los demás.

Representación en navegadores

Un navegador normalmente tiene la oportunidad de pintar entre tareas. Eso explica un error común:

spinner.hidden = false;
doHeavyWork();              // blocks the thread
spinner.hidden = true;

La ruleta nunca aparece porque el navegador no tuvo oportunidad de renderizar entre esas líneas. Para solucionarlo, deje pasar un marco antes de que comience el trabajo pesado, o traslade ese trabajo a un trabajador. Para el código que cambia elementos visuales, requestAnimationFrame se ejecuta justo antes de la siguiente pintura, lo que la convierte en la herramienta adecuada para la animación.

Diferencias de Node.js

Node.js tiene su propio bucle de eventos con varias fases, incluidos temporizadores, sondeo de E/S y setImmediate. También tiene process.nextTick, que se ejecuta en su propia cola. Esto es lo que vimos al ejecutarlos desde dentro de una función asíncrona:

setTimeout(() => console.log("timeout"), 0);
setImmediate(() => console.log("immediate"));
process.nextTick(() => console.log("nextTick"));
Promise.resolve().then(() => console.log("promise"));

// promise
// nextTick
// immediate
// timeout

Muchos artículos afirman que nextTick siempre supera las promesas y que un cronómetro supera a setImmediate. Nuestro resultado muestra que no es tan simple. Nuestro código ya se estaba ejecutando dentro de una microtarea, por lo que la cola de promesa continuó primero. Y se sabe que el orden de setTimeout y setImmediate varía según desde dónde se llaman. Así que no escribas código que dependa del orden exacto de estos. Si una cosa debe suceder tras otra, encadénelas explícitamente.

cuestionario de entrevista

Intente calcular el orden antes de leer la respuesta:

console.log("a");
setTimeout(() => console.log("b"), 0);
Promise.resolve().then(() => {
  console.log("c");
  setTimeout(() => console.log("d"), 0);
  Promise.resolve().then(() => console.log("e"));
});
console.log("f");

Nuestra ejecución imprimió a, f, c, e, b, d. He aquí por qué:

1. a y f son sincrónicos, por lo que se ejecutan primero.
2. La pila está vacía, por lo que se ejecutan las microtareas: c, luego la nueva microtarea e, en la misma ronda.
3. Ahora una tarea: el temporizador b, que se puso en cola primero.
4. Luego, la siguiente tarea: el temporizador d, que se puso en cola durante la microtarea.

Errores comunes

• Pensar setTimeout es exacto. El retraso es sólo mínimo.
• Pensar async significa otro hilo. El código asíncrono todavía se ejecuta en el hilo principal entre esperas.
• Usar dormir para arreglar el orden. Esperar a la condición real es mucho más confiable, lo que también se aplica a las pruebas inestables.
• Usando forEach con await. No espera entre elementos. Consulte Métodos de matriz de JavaScript.
• Realizar un trabajo pesado sincrónico en un controlador de servidor. Una solicitud puede retrasar todas las demás solicitudes.

Conclusión

Recuerde la regla básica: ejecute la pila hasta que esté vacía, ejecute todas las microtareas, luego ejecute una tarea y repita. Todo lo demás se deriva de ello. Para que se mantenga, escriba su propia versión del cuestionario anterior, prediga el resultado en papel y luego ejecútelo. Equivocarse y comprender por qué le enseñará más que cualquier diagrama.

Preguntas frecuentes

sigue aprendiendo