Virtual Thread

Introduced in java 19 - Java Virtual Thread, it has potential to improve throughput, giving boost to application availability. It will also reduce memory consumption of the application making it more swifter and efficient. This post is to understand java virtual thread which was introduced lately in java release versions.

If we re-iterate our understanding on Java thread lifecycle executing a database backend call or an external call to process file. A typical lifecycle would have to perform below steps:

1. The thread pool maintains a pool of threads to be assigned some tasks.
2. The thread is waiting in the pool for a new request to come.
3. When a new request knocks, the thread picks up the request so that it can provide service to this request. For example makes a Database call to fetch some records.
4. Until the database finishes its processing the thread waits for response from the backend Database.
5. Once response is back, the thread processes it, and sends back the response to callee.
6. Thread is returned back to the pool.

If we want to assess the efficiency of the above life cycle of thread execution then let me remind you of the steps where the thread was waiting for response from the backend database.

If we repeat this steps for all the threads until the application shuts down then it wont be wrong to state that in most of the applications we see a trend that a significant number of threads predominantly waits most of the time during its life cycle.

We are all aware of jvm "classic" threads, when a classic thread is assigned some task, the classic thread waits for Operating System thread to be assigned. This is purely a 1:1 mapping between jvm classic thread and operating system thread. Until an operating system thread is assigned to the classic thread, the classic thread cannot perform any operation.

Now, to improve application thread execution management jvm has included virtual threads. With the new concept a virtual thread will be assigned to platform thread only when it executes real work.

If we refer back to our steps mentioned in the thread life cycle, virtual thread will be assigned to platform thread in step #3 and step #5, and the platform thread will use OS thread for execution. In all other steps, virtual thread will be residing as objects in the Java heap memory region just like any of your application objects.

Thus, Java’s virtual threads incur minimal overhead, so there can be many, many, many of them.

Do I need to learn new interfaces for virtual threads?

No!!. All the existing APIs that work with current platform threads, will work with virtual threads. However, the creation of virtual threads relies on new method 'Thread.startVirtualThread()'.

Runnable task = () -> {     System.out.println("Hello Virtual Thread!");  }; Thread.startVirtualThread(task);        

There are other methods of creating virtual threads

1. Thread.ofVirtual().start(Runnable);

2. Thread.ofVirtual().unstarted(Runnable);

3. Executors.newVirtualThreadPerTaskExecutor();

4. Executors.newThreadPerTaskExecutor(ThreadFactory);

Performance impact of Virtual Threads

Java virtual threads are lightweight than platform threads. Studies done in this link will give more insights on the performance of virtual threads. However, in a nutshell:

1. If your application either have lot of threads or large stack size (i.e. -Xss), then switching to virtual threads would reduce your application’s memory consumption.
2. If your application is creating new threads frequently (instead of leveraging thread pool), switching to virtual threads can improve your application’s response time.

Finally, another aspect that works correctly in virtual threads but deserves being revisited for better scalability is thread-local variables, both regular and inheritable. Virtual threads support thread-local behavior the same way as platform threads, but because virtual threads can be very numerous, thread locals should be used only after careful consideration.