Modern Java unleashed: virtual threads revolution & other game-changing features in JDK 21

Virtual threads, part of Project Loom, are a lightweight alternative to platform threads. Unlike traditional threads (1:1 with OS threads), virtual threads are managed entirely by the JVM, not the operating system.

Analogy: Traditional platform threads are like trucks that each carry packages to their destination and wait there until unloading is complete, even if that means waiting hours for someone to sign for it. During that waiting time, the truck is completely unavailable to deliver other packages.

Virtual threads are like a smart delivery system where trucks drop off packages and immediately become available for new deliveries, while a local service handles the waiting and paperwork.

The JVM schedules the virtual threads onto a small pool of carrier (real) threads, suspending them in memory when they block, rather than tying up an OS thread. When a virtual thread performs a blocking I/O operation, it can unmount from its carrier (platform thread). The carrier gets free, so the JVM can mount a different virtual thread on that carrier. That’s why the key efficiency comes from what happens when a virtual thread performs a blocking operation.

Also, this in-memory handling is what makes them so cheap and scalable. They allow us to write synchronous-style code that runs concurrently like asynchronous code.

Since virtual threads are mounted upon platform threads(carriers of the virtual threads), you may consider them an illusion that the JVM provides. They're essentially Java objects allocated on the heap that can be garbage collected when no longer needed.

In Summary, the key efficiency comes from what happens when a virtual thread performs a blocking operation. After running some code, the virtual thread can unmount from its carrier.

Opening a virtual thread is roughly 10x faster than a platform thread and uses around ~1–2 KB of memory compared to ~1MB for a platform thread. Platform threads require a large, contiguous allocation of memory (often around 1MB per thread) to hold their stack, while virtual threads store their stack frames in Java's garbage-collected heap rather than in these monolithic memory blocks and take around ~1KB of memory.

This creates a new thread for each task without the cost of creating an OS thread. You can run thousands, even millions of virtual threads concurrently.

Starting from Spring Boot 3.2, virtual threads can be enabled by configuration:

That’s it. Your controllers, services and database calls will now execute on virtual threads automatically:

Note: Even if userRepository runs in a lightweight virtual thread, because it uses JDBC, the carrier thread will still be blocked during the JDBC call. We will explore this limitation a bit later in the article.

Note: While the property enables virtual threads for web request handling, certain libraries or components might still need explicit configuration (as we will see in the next section for RestClient).

While enabling virtual threads with spring.threads.virtual.enabled=true configures your Spring Boot application to handle incoming web requests using virtual threads, there's an important caveat: HTTP clients like RestClient or RestTemplate used within your application won't automatically use virtual threads.

For our simple test endpoint (/thread-info), this wasn't an issue because we weren't making any outgoing HTTP requests. But if you're building an API that calls other services, you'll need additional configuration:

Then you can use this RestClient in your controller:

Virtual threads offer a fundamentally different approach to concurrency compared to CompletableFuture. While CompletableFuture uses a callback-based programming style, virtual threads allow you to write synchronous-looking code that behaves asynchronously under the hood.

With CompletableFuture, you typically chain operations using methods like thenApply, thenCompose and thenAccept. Virtual threads, on the other hand, let you write simple imperative code that reads more naturally.

Blocking operations like JDBC can run in virtual threads, but with significant limitations:

JDBC is blocking - there's no async or reactive JDBC API in the standard Java JDK (though there are third-party solutions like R2DBC). And with platform threads, this blocking is expensive.

Unfortunately, virtual threads don't fully solve this problem for JDBC. While virtual threads can handle thousands of concurrent operations, JDBC operations typically cause thread pinning. This is partly because many JDBC drivers use synchronised blocks internally, but also because native blocking calls themselves can pin the thread. As a result, the carrier thread remains occupied during database access, limiting scalability.

This means the carrier thread cannot be reused for other virtual threads during that time.

I/O vs. CPU-bound operations: Virtual threads provide significant benefits for I/O-bound applications but don't improve performance for CPU-intensive tasks. A benchmark comparing virtual threads to platform threads for CPU-intensive operations (calculating Fibonacci) showed little difference in throughput - Fast thread.

Thread pinning issues: Virtual threads can get "pinned" to carrier threads in certain scenarios, including when using synchronised blocks/methods or when executing blocking operations in native methods. Spring Framework uses synchronised blocks in various places, though they've been working to revise these to avoid pinning issues.

Framework limitations: Switching from normal threads to virtual threads can have unforeseen consequences for legacy applications, requiring thorough testing.