1. Introduction
In this tutorial, we’ll show the difference between traditional threads in Java and the virtual threads introduced in Project Loom.
Next, we’ll share several use cases for virtual threads and the APIs that the project has introduced.
Before we start, we need to note this project is under active development. We’ll run our examples on early access loom VM: openjdk-15-loom+4-55_windows-x64_bin.
Newer versions of the builds are free to change and break current APIs. That being said, there was already a major change in the API, as the previously used java.lang.Fiber class has been removed and replaced with the new java.lang.VirtualThread class.
2. High-Level Overview of Thread vs. Virtual Thread
At a high level, a thread is managed and scheduled by the operating system, while a virtual thread is managed and scheduled by a virtual machine. Now, to create a new kernel thread, we must do a system call, and that’s a costly operation.
That’s why we’re using thread pools instead of reallocating and deallocating threads as needed. Next, if we’d like to scale our application by adding more threads, due to the context switching and their memory footprint, the cost of maintaining those threads may be significant and affect the processing time.
Then, usually, we don’t want to block those threads, and this results in usages of non-blocking I/O APIs and asynchronous APIs, which might clutter our code.
On the contrary, virtual threads are managed by the JVM. Therefore, their allocation doesn’t require a system call, and they’re free of the operating system’s context switch. Furthermore, virtual threads run on the carrier thread, which is the actual kernel thread used under-the-hood. As a result, since we’re free of the system’s context switch, we could spawn many more such virtual threads.
Next, a key property of virtual threads is that they don’t block our carrier thread. With that, blocking a virtual thread is becoming a much cheaper operation, as the JVM will schedule another virtual thread, leaving the carrier thread unblocked.
Ultimately, we wouldn’t need to reach out for NIO or Async APIs. This should result in more readable code that is easier to understand and debug. Nevertheless, the continuation can potentially block a carrier thread — specifically, when a thread calls a native method and performs blocking operations from there.
3. New Thread Builder API
In Loom, we got the new builder API in the Thread class, along with several factory methods. Let’s see how we can create standard and virtual factories and make use of them for our thread execution:
Runnable printThread = () -> System.out.println(Thread.currentThread());
ThreadFactory virtualThreadFactory = Thread.builder().virtual().factory();
ThreadFactory kernelThreadFactory = Thread.builder().factory();
Thread virtualThread = virtualThreadFactory.newThread(printThread);
Thread kernelThread = kernelThreadFactory.newThread(printThread);
virtualThread.start();
kernelThread.start();
Here’s the output of the above run:
Thread[Thread-0,5,main]
VirtualThread[<unnamed>,ForkJoinPool-1-worker-3,CarrierThreads]
Here, the first entry is the standard toString output of the kernel thread.
Now, we see in the output that the virtual thread has no name, and it’s executing on a worker thread of the Fork-Join pool from the CarrierThreads thread group.
As we can see, regardless of the underlying implementation, the API is the same, and that implies we could easily run existing code on the virtual threads.
Also, we don’t need to learn a new API to make use of them.
4. Virtual Thread Composition
It is a continuation and a scheduler that, together, make up a virtual thread. Now, our user-mode scheduler may be any implementation of the Executor interface. The above example has shown us that, by default, we run on the ForkJoinPool.
Now, similarly to a kernel thread – which can be executed on the CPU, then parked, rescheduled back, and then resumes its execution – a continuation is an execution unit that can be started, then parked (yielded), rescheduled back, and resumes its execution in that same way from where it left off and still be managed by a JVM instead of relying on an operating system.
Note that the continuation is a low-level API, and that programmers should to use higher-level APIs like the builder API to run virtual threads.
However, to show how it’s working under-the-hood, now we’ll run our experimental continuation:
var scope = new ContinuationScope("C1");
var c = new Continuation(scope, () -> {
System.out.println("Start C1");
Continuation.yield(scope);
System.out.println("End C1");
});
while (!c.isDone()) {
System.out.println("Start run()");
c.run();
System.out.println("End run()");
}
Here’s the output of the above run:
Start run()
Start C1
End run()
Start run()
End C1
End run()
In this example, we ran our continuation and, at some point, decided to stop the processing. Then once we re-ran it, our continuation continued from where it left off. By the output, we see that the run() method was called twice, but the continuation was started once and then continued its execution on the second run from where it left off.
This is how blocking operations are meant to be processed by the JVM. Once a blocking operation happens, the continuation will yield, leaving the carrier thread unblocked.
So, what happened is that our main thread created a new stack frame on its call stack for the run() method and proceeded with the execution. Then, after the continuation yielded, the JVM saved the current state of its execution.
Next, the main thread has continued its execution as if the run() method returned and continued with the while loop. After the second call to continuation’s run method, the JVM restored the state of the main thread to the point where the continuation has yielded and finished the execution.
5. Conclusion
In this article, we discussed the difference between the kernel thread and the virtual thread. Next, we showed how we could use a new thread builder API from Project Loom to run the virtual threads.
Finally, we showed what a continuation is and how it works under-the-hood. We can further explore the state of Project Loom by inspecting the early access VM. Alternatively, we can explore more of the already standardized Java concurrency APIs.
