Node.js Backend Development Bootcamp · 课时

事件循环为何会被 CPU 密集型工作阻塞

识别阻塞计算，并理解为什么单线程 JavaScript 需要真正的线程来实现并行。

事件循环为何会被 CPU 密集型工作阻塞 是 CoddyKit 上的免费 Node.js Backend Development Bootcamp 课时。这是第 1 节课，共 4 节。你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。这是 Node.js Backend Development Bootcamp 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 Node.js Backend Development Bootcamp 课程共包含 4 节课。

本课时的部分内容尚未翻译，以英文显示。

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.

常见问题解答

「事件循环为何会被 CPU 密集型工作阻塞」课时是免费的吗？

是的 — 「事件循环为何会被 CPU 密集型工作阻塞」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 Node.js Backend Development Bootcamp 课程的其余内容，请升级到 CoddyKit PRO。 Node.js Backend Development Bootcamp 课程共包含 4 节课。

「事件循环为何会被 CPU 密集型工作阻塞」这节课中我会学到什么？

识别阻塞计算，并理解为什么单线程 JavaScript 需要真正的线程来实现并行。你通过在浏览器中直接运行的动手代码来练习 Node.js Backend Development Bootcamp，全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 Node.js Backend Development Bootcamp 需要有经验吗？

无需任何先前经验。CoddyKit 上的 Node.js Backend Development Bootcamp 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。这是第 1 节课，共 4 节。

「事件循环为何会被 CPU 密集型工作阻塞」课时需要多长时间？

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。

我能在这节 Node.js Backend Development Bootcamp 课中编写并运行代码吗？

能。每节 Node.js Backend Development Bootcamp 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

← 返回 Node.js Backend Development Bootcamp