Java 21 - Virtual Threads

Let's move on from all the exciting features in Java 21 and the fact that it removed the requirement for the "Static Void main." Now, you can simply write "void main," which is easy and straightforward. However, there's no fundamental change in essence.

The significant change that has emerged is going to completely reshape the backend development in the near future, relying heavily on reactive programming. This shift is due to its complexity in debugging despite its advantage in executing asynchronous programming.

Let's explain this simply and focus closely. What does an Async call mean?

In essence, it means that you can execute code without waiting for it to finish. You can continue executing other code, and when it's done, you can deal with its output. This is often referred to as the "Non-Blocking" model, which is now quite common and straightforward in most programming languages.

How does it work? It's simply like having a working thread, and when it's done, it closes. Is this a great improvement that will speed everything up? Yes, but it comes with its own limitations.

The biggest limitation is that every time you need to execute something, you'll need a thread. This is not without a cost because Java used to assign tasks to the operating system's thread pool. No matter how hard you try, there will always be a limit. For example, you can't execute 10,000 threads simultaneously on a machine with limited RAM or a low number of CPU cores due to these limitations.

Now, pay close attention to this next part; it's truly ingenious and remarkable.

Suppose you want to make an API call and you put it in a thread. That's nice, but what if the API takes, say, 4 seconds to complete, and the thread associated with it is currently unused? What's the solution?

Here's where a new term comes into play, called "Virtual Threads." Just from the name, you can see the brilliance of the design.

For example, if your operating system can handle a maximum of 3 threads, Java 21, instead of consuming all 3 and opening them all at once, takes just one and adds a new layer, Virtual, on top of it, and let's say there are 5 virtual threads. So, every real OS thread is connected to 5 virtual threads.

It's a brilliant, brilliant solution in every sense of the word.

Now, let's go back to the example above. If the API takes 4 seconds to complete, the 5 virtual threads will share the work on a single real OS thread. Each one does its own work, and if one takes longer, context switching occurs, but it's on the Java level, not the OS level. ???

It's a genius solution. This means that the task that used to take 17 minutes can now be completed in 4 seconds if we need to open 80,000 virtual threads because there's no lagging, and every second is efficiently used for switching to the next task to be executed.

Of course, it has its limitations, but it's a brilliant solution that will save time and effort.

Back in the day, when we needed threads, we used to do this:

Executors.newFixedThreadPool(100)

And, of course, this was very expensive because we were creating platform threads. Now, we do it like this:

Executors.newVirtualThreadPerTaskExecutor

#java21