JavaScript is single-threaded but handles asynchronous operations using the event loop and concurrency model; it offloads async tasks to Web APIs, queues their callbacks, and processes microtasks (like Promises) before macrotasks (like setTimeout), ensuring responsiveness; 1. The call stack executes functions synchronously; 2. Web APIs handle async operations and enqueue callbacks; 3. The microtask queue runs all its tasks before any macrotask; 4. The event loop checks the call stack and prioritizes microtasks; 5. UI rendering occurs between macrotasks; this explains why Promise callbacks run before setTimeout even with zero delay, and why long microtask chains can block updates, making understanding the model essential for writing efficient, non-blocking code.

JavaScript is famously single-threaded — but somehow, it handles asynchronous operations like AJAX calls, timers, and user interactions without freezing the browser. This magic lies in its event loop and concurrency model. Let’s break it down in plain terms and see how JavaScript manages to stay responsive despite running on a single thread.

How JavaScript Handles Concurrency Without Threads

Even though JavaScript runs on a single thread, it doesn’t mean it can only do one thing at a time. Instead, it uses a concurrency model based on an event loop and a task queue (or callback queue) to manage asynchronous operations.

Here’s the core idea:

• JavaScript executes code synchronously by default.
• When an async operation (like setTimeout, fetch, or DOM events) is encountered, it’s handed off to Web APIs (browser) or C APIs (Node.js).
• Once the async task completes, a callback is placed in a queue.
• The event loop continuously checks if the call stack is empty. If it is, it pushes the next callback from the queue onto the stack to run.

This model is called run-to-completion, meaning each function runs fully before any other code runs — no preemption.

The Components of the Event Loop System

To understand the event loop, you need to know the key players:

1. Call Stack
   A LIFO (last-in, first-out) structure that tracks which function is currently executing.

2. Heap
   Where objects are stored in memory.

3. Web APIs (in browsers)
   Browser-provided APIs like setTimeout, XMLHttpRequest, or event listeners. They run outside the JS engine.

4. Callback Queue (Task Queue)
   Holds callbacks ready to be executed (e.g., from setTimeout).

5. Microtask Queue
   A higher-priority queue for promises, queueMicrotask, and MutationObserver callbacks.

6. Event Loop
   The mechanism that checks the call stack and queues, deciding what to run next.

How the Event Loop Works Step by Step

Imagine this code:

console.log("Start");

setTimeout(() => {
  console.log("Timeout");
}, 0);

Promise.resolve().then(() => {
  console.log("Promise");
});

console.log("End");

What’s the output?

Start
End
Promise
Timeout

Here’s why:

1. "Start" is logged (sync).
2. setTimeout is handed to Web API. It waits 0ms, then goes to the callback queue.
3. The Promise resolves immediately, and its .then() callback goes to the microtask queue.
4. "End" is logged (sync).
5. The call stack is now empty.
6. The event loop checks the microtask queue first — runs the promise callback → "Promise".
7. Then, it checks the callback queue → runs setTimeout → "Timeout".

? Key Rule: After each task, the event loop processes all microtasks before drawing the next frame or handling more tasks.

Microtasks vs Macrotasks

Not all async tasks are equal. They fall into two categories:

• Macrotasks (Task Queue)
  Examples: setTimeout, setInterval, I/O, UI rendering, postMessage.
  One macrotask runs per cycle.

• Microtasks (Microtask Queue)
  Examples: Promises, queueMicrotask, MutationObserver.
  All microtasks are processed before the next macrotask.

This priority difference is crucial. Microtasks can delay UI updates or other timeouts if too many are queued.

Example:

setTimeout(() => console.log("Macro"), 0);
Promise.resolve().then(() => console.log("Micro"));

// Output:
// Micro
// Macro

Even though both are delayed, the microtask runs first.

What Happens During a Single Event Loop Tick?

1. Execute the current script (or function).
2. Once the call stack is empty:
   • Run all pending microtasks (in order, until the queue is empty).
3. Optionally: Render updates to the UI (browser does this once per frame, typically every 16ms).
4. Pull the next macrotask from the task queue and run it.
5. Repeat.

This is why long-running microtask chains can block rendering — they starve the UI.

Common Pitfalls and Gotchas

• Infinite microtask loops can freeze the page:

  Promise.resolve().then(() => {
    console.log("Never stops");
    Promise.resolve().then(arguments.callee);
  });

  This never gives the event loop a chance to process other tasks.

• setTimeout(fn, 0) isn’t truly immediate — it waits for the next macrotask cycle, after all microtasks.

• UI updates wait until the current task and microtasks finish. So:

  button.textContent = "Loading...";
  // You might not see the update yet!
  heavyCalculation(); // Blocks rendering

  To fix, you can yield control:

  setTimeout(() => heavyCalculation(), 0);

In Node.js: A Slightly Different Flavor

Node.js also uses an event loop, but it’s based on libuv and has more phases:

• Timers (setTimeout, setInterval)
• Pending callbacks
• Idle, prepare
• Poll (retrieve new I/O events)
• Check (setImmediate)
• Close callbacks

And Node has both:

• process.nextTick() — even higher priority than microtasks (runs before promises).
• setImmediate() — runs in the "check" phase, after I/O callbacks.

So in Node:

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

Output:

nextTick
Promise
setTimeout
setImmediate

process.nextTick is not part of the microtask queue — it’s processed after each phase, not after each task.

Summary: The Big Picture

• JavaScript is single-threaded but uses non-blocking async APIs.
• The event loop coordinates execution between the call stack and task queues.
• Microtasks (Promises) run before macrotasks (setTimeout).
• UI rendering happens between macrotasks.
• Misusing microtasks or blocking the main thread can hurt performance.

Understanding this model helps you write more predictable, non-blocking code — especially when dealing with promises, async/await, or performance-critical UI updates.

Basically, the event loop is JavaScript’s way of saying: “I’ll finish what I’m doing first, then handle what’s waiting — but I’ll check the urgent stuff before the regular mail.”

The above is the detailed content of A Deep Dive into the JavaScript Event Loop and Concurrency Model. For more information, please follow other related articles on the PHP Chinese website!