Cover image for Is Node.js really single-threaded?

Is Node.js really single-threaded?

santhu210 profile image Santhosh Reddy Originally published at distributedstack.dev ・2 min read

Many developers wonder at some point in their Node.js programming journey that, is Node.js really single-threaded? If it is, how is it able to do asynchronous execution? Some people understand it in terms of even loop, but there is more to it. I hope you understand what event loop is since you are reading this. But, if you don’t, check out this awesome talk by Philip Roberts.

In Chrome, Javascript runs in a single thread. You are sharing the same thread for rendering as well as your code execution. Chrome actually employs multi-process architecture, which means that each tab, plugin in your browser is getting a new process. And any crash or block is not effecting others. When JS code is executed in the browser, it is essentially blocking the browser painting or render since there is no thread to do the same. But before it picks something from the callback queue after the current call stack is empty, browser paint actually takes precedence. That’s about the browser. But, how do things go in a backend JS runtime, Node.js?

The answer to the above question, Node.js is single-threaded similar to Javascript. So, your JS code is running in a single thread(main thread) in consensus with the event loop and callback queue. But, Node.js is not purely Javascript code. Some of it is C++ code, some things when done asynchronously like network calls, file system tasks, DNS lookup, etc. are actually not handled by the main thread. Node.js does this optimization of using C++ code(which has access to multiple threads) internally for these tasks, which helps in reducing the execution time when used correctly. Node.js actually does offload the asynchronous tasks to C++ code, where it has the provision to use multiple threads to speed up execution, but if you force it to be sync(using only the synchronous version of the API), you are binding it not to do this optimization.

Posted on by:

santhu210 profile

Santhosh Reddy


Senior Software Developer, Tech enthusiast


markdown guide

I will do a joke. It will be very bad.

So Node.js is married-threaded.


It's been 6 hours. How to get this out of my head? It's very bad. 😣


So does this mean that there's no advantage in running Node on a super beefy 16 core machine?


Honestly, if you're looking to make use of heavy multithreading; Javascript just isn't the language you should be looking at I'm fraid


From what I can tell (correct me if I'm wrong), this uses service workers under the hood.
Those have the problem that you're not able to share memory, so if you want to pass large amounts of data around, you're effectively copying it every time it moves between threads.
While perhaps not problematic for some, I see this cause problems on large scale if you're not careful about what you're passing around; as well as the issue that suddenly you're not passing by reference whereas a regular function call would (for objects etc).


It's a practice to spawn multiple instances of the app with this type of setup.
Have a look at cluster module.



Also check nodejs.org/api/worker_threads.html and threads.js.org/
You can truly have multiple threads now in Node. Handling Race condition is on you though, for now atleast. Best use case for workers is for logging and I/O operations.


To get started with multiple instances, have a look at pm2. You can spawn as many instances as your cpu cores.



More an aside, but this was a great Node.js course on Frontend Masters that I did once. It touches on the usage of libuv under the hood for anyone who finds this discussion topic fascinating frontendmasters.com/courses/server...


Asynchronous execution does not mean parallel execution. Node runs asynchronous tasks concurrently.


True to some extent(per each worker). But, offloading multiple tasks to libuv thread pool essentially make it parallel.