Do CPU‑Intensive Tasks Block Node.js? An Experimental Study of libuv Thread Pool

Node.js developers often wonder whether CPU‑intensive operations, such as cryptographic hashing, will block the event loop. This article presents a simple test that runs multiple encryption tasks to observe their execution time.

First, four encryption tasks are executed consecutively, and the timing results are printed:

Hash:  1232
Hash:  1237
Hash:  1268
Hash:  1297

The start times of the four tasks are identical, and the end times are almost the same, indicating that the tasks were executed concurrently.

The lack of blocking is explained by libuv’s default thread pool, which contains four worker threads. Each of the four encryption tasks is dispatched to a different thread, allowing them to run in parallel without blocking the main event loop.

When a fifth encryption task is added, the output becomes:

Hash:  1432
Hash:  1437
Hash:  1468
Hash:  1497
Hash:  2104

Here the first four tasks still run concurrently, but the fifth task experiences a delay because all four worker threads are busy; it must wait for a thread to become free before it can be processed.

This behavior demonstrates that libuv’s thread pool size determines how many CPU‑bound tasks can run in parallel. Tasks exceeding the pool size are queued until a thread finishes its current work.

The size of the libuv thread pool can be configured via the environment variable UV_THREADPOOL_SIZE . For example, setting UV_THREADPOOL_SIZE=5 expands the pool to five threads.

Running the same test with a pool size of five shows that all five tasks are dispatched concurrently. However, because the test machine has only four CPU cores, the operating system must perform context switching, leading to a noticeable increase in each task’s execution time.