Perhaps I am getting something wrong here but I had a conversation today that left me perplex.

I hear a lot about nodejs not having threads. but that's not entirely true, right?

The precise phrasing is - you cannot spawn (or manage) threads in nodejs. Threads are being managed for you. The underlying implementation in C that gives us the event queue and all has to have threads. right?

And if so, can someone please compare these threads to a java environment by comparing their resource consumption on the server - as I also hear a lot about how nodejs is much less consuming than java.

  • related (possibly a duplicate): What is So Unique About Node.js?
    – gnat
    Commented Apr 18, 2016 at 15:07
  • From a high level view, yes NodeJs doesn't do spawnable threads, it instead uses one thread and performs non-blocking async execution which shares the same thread. There are libraries which seek to allow the threadability of nodejs, but they are not standard in the design.
    – tt9
    Commented Apr 18, 2016 at 15:10
  • @user2313300 but there are threads being spawned by the system wrapping your javascript code in nodejs, correct? and how do those threads weight in comparison to java? are they lighter/heavier/same? Commented Apr 18, 2016 at 15:31
  • Hopefully there is at least one thread ;)
    – Erik Eidt
    Commented Apr 18, 2016 at 16:59
  • This seems like it's already adequately explained here: nodejs.org/en/about Commented Apr 18, 2016 at 21:08

2 Answers 2


Comparing Node.js to Java is somewhat like comparing apples to oranges and more like comparing a dictionary to a grammar textbook (thanks scriptin).

Node.js is a quasi-framework written in JavaScript using Google's V8 JavaScript engine to build the JavaScript code into native machine code that can be used server-side (instead of interpreting the JS code in real-time).

Java is a language (not a framework) to which an implementation of the JDK (i.e. Oracle JDK vs. OpenJDK) can see fit how to implement the underlying language constructs (threads, I/O, etc.).

Node.js does not have a threading model, that is, you cannot spawn a thread directly through any API Node.js has. This is because it utilizes JavaScript (i.e. ECMAScript) which does not support multi-threading (since JavaScript was not originally meant for server side development). This does not mean that it is not multi-threaded. On the contrary, Node.js uses a thread pool to manage a lot of the async-I/O and event system that you (the user of Node.js) can hook into (just like JavaScript on the client). So as you stated:

The precise phrasing is - you cannot spawn (or manage) threads in nodejs.


can someone please compare these threads to a java environment by comparing their resource consumption on the server

In a Java environment, you can spawn threads in user code, but it should be noted that the underlying mechanisms that spawn the threads (i.e. the JVM C code) are the same system API's called to create and manage the threads in Node.js. In other words, both will call pthread_create for POSIX platforms or CreateThread for Windows. In this way, the resources used are the same on that front.

Where this thread model and resource usage differs is when a user wants to create more than 1 thread; multiple threads might mean context switches which can incur additional resources. This is true of any language though, since threading is an OS level concept and not something a language need support, so if you (as the developer) are building a multi-threaded application, you would (should) be aware of these caveats and build your code accordingly (i.e. handle the resources/threads such that the application has as little context switching as feasible).

Continuing from that, you state

as I also hear a lot about how nodejs is much less consuming than java.

This question cannot be directly (read, easily) answered since a simple Node.js app that were ported to Java (or vice versa) could result in varying resource usage based on a slew of different factors and ultimately you would have to do the testing yourself to see which would be better for that scenario.

To this though, the "less consuming" quote is probably referring more to the fact that running a Java based applet would require the Java Virtual Machine and the Java environment, which do consume substantial amounts of resources (for different reasons) compared to Node.js (which runs as a "native" app), but just because something consumes more resources does not mean it's "worse". And this is why additional testing would need be done to confirm.

I hope that can help add clarity.

  • Apples and oranges are very comparable. Comparing Node.js and Java (as a language) is more like comparing a dictionary to a grammar textbook, although Java has its dictionary as well.
    – scriptin
    Commented Apr 18, 2016 at 23:28
  • @scriptin, haha, agree! Like apples and oranges, Node and Java are full of juicy tidbits and seedy goodness :)
    – txtechhelp
    Commented Apr 19, 2016 at 1:51
  • This is wrong. You can spawn new threads in NodeJS. See cluster for instance.
    – kba
    Commented Nov 29, 2016 at 10:15
  • @kba from the link you posted, a cluster is a module that allows you to easily create child processes that all share server ports. .. and The worker processes are spawned using the child_process.fork() method .. so it's actually a fork of a process and not a new thread. A thread is different in that it shares the same memory space with the process, a forked process has a different memory space.
    – txtechhelp
    Commented Nov 30, 2016 at 3:41
  • A fork of a process is a new thread. You are correct in saying that a fork does not share memory with the main thread.
    – kba
    Commented Nov 30, 2016 at 13:11

It is not so much Node.js, it is JavaScript.

Java works with threads. When you need to do multiple things in parallel, you typically assign one thread for each task. When a thread needs to wait for something (a response from a server, a locked resource), that thread is just put to sleep until the resource is available. Other threads can run during that time. Each thread has its own stack and runs its own sequence of instructions independently of the other threads. At any time there can be many threads blocked in some procedure, waiting for various reasons.

JavaScript, for all practical purposes, runs on a single thread. The JavaScript engine will run one piece of code at a time, waiting for the procedure to return before doing anything else. A procedure can not wait because it would freeze the whole application. Therefore a JavaScript application must be coded using many small procedures that do their work and return promptly. They are not allowed to wait in any way.

This is why the Java runtime library is designed with multithreading in mind using a synchronous model (a request to a server does not return before the result is available), while the JavaScript library is written using asynchronous calls for everything that might block (i.e. "don't wait, I'll call you"). In JavaScript, you would call one method to start a request and wait for the java engine to come back to you with the response when it is ready.

So it is true that Node.js has no threads, but it is because it's the way JavaScript works. Node.js actually helps you to deal with this. It makes it easy to program a multitasking application (in the sense of multiple independent workflows running in parallel) by taking charge of weaving that single thread thru all the pieces of code that need to be run, while letting you express independent workflows each running its own sequence of events.

  • OK, I know it is not entirely true when you look at the internal working. That's why I said "for all practical purposes".
    – Florian F
    Commented Apr 18, 2016 at 21:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.