For nearly two decades, writing high-throughput concurrent applications in Java has been an exercise in compromise. Developers were forced to choose between the simplicity of the synchronous 'thread-per-request' model and the scalability of asynchronous, non-blocking code. The former was easy to read but crashed under load; the latter scaled beautifully but descended into 'callback hell,' making debugging and maintenance a nightmare.
That era of compromise ended with the release of Java 21. By introducing Virtual Threads (formerly Project Loom) as a standard feature, Oracle delivered the most significant change to Java concurrency since the introduction of java.util.concurrent in Java 5.
Virtual threads are not just a performance tweak; they are a fundamental shift in how the JVM handles execution units. They allow developers to write simple, synchronous-style code—the kind we all prefer to read—that scales with the efficiency of asynchronous I/O. By decoupling Java threads from operating system resources, we can finally solve the throughput limitations that have plagued server-side Java for years.
The Legacy Problem: Why Platform Threads Hit a Wall
The Cost of Platform Threads
To appreciate the solution, we must understand the bottleneck. Traditionally, instances of java.lang.Thread have been 'Platform Threads.' These are wrappers around heavy operating system (OS) threads, maintaining a 1:1 mapping. When you create a Java platform thread, the OS creates a kernel thread to back it.
This relationship is resource-expensive. A platform thread typically consumes about 1MB of stack memory outside the heap. Furthermore, scheduling these threads requires the OS kernel to perform context switches, which burn CPU cycles saving and restoring registers and cache lines. Because of these constraints, a standard JVM is practically limited to a few thousand active threads. According to Little’s Law, if your throughput is defined by the number of concurrent requests you can handle, this thread limit becomes a hard ceiling on application scalability.
The Blocking Bottleneck
The problem is exacerbated by the nature of modern web applications, which are largely I/O-bound. Consider a standard microservice request that queries a database. When a platform thread executes that query, it blocks. The OS scheduler halts the thread while it waits for the network response.
During this wait—which can last milliseconds or seconds—that expensive OS thread sits idle. It is holding onto memory and system resources but doing absolutely no work. To mitigate this, the Java ecosystem turned to Reactive Programming (RxJava, Spring WebFlux). While effective at unblocking hardware resources, reactive frameworks force developers to abandon standard control flow structures (like loops and try-catch blocks) in favor of complex functional pipelines. This increased the cognitive load significantly and made stack traces nearly impossible to decipher.
Enter Virtual Threads: A Paradigm Shift
What is a Virtual Thread?
Virtual threads sever the 1:1 chain between Java threads and OS threads. They are lightweight, user-mode threads managed entirely by the JVM, not the operating system. Instead of the 1:1 model, Virtual Threads utilize an M:N scheduling model: millions of virtual threads can run on top of a few carrier (platform) threads.
Because they are managed by the JVM, they are incredibly cheap to create. A virtual thread requires only a few hundred bytes of metadata and its stack can grow and shrink dynamically. While spinning up 10,000 platform threads might crash a machine, spinning up 10,000,000 virtual threads is a perfectly valid operation on standard hardware.
The Magic of 'Unmounting'
The true genius of Project Loom lies in how it handles blocking operations. The JVM has been re-engineered to detect when a virtual thread attempts a blocking I/O call (such as reading from a socket).
When a virtual thread blocks, the JVM 'unmounts' it from the carrier thread. The virtual thread’s stack frame is copied from the carrier stack into the heap, effectively freezing its state. The carrier thread—the actual OS thread—is now free. It immediately picks up another virtual thread from the queue and executes it. Once the blocking I/O operation completes, the OS signals the JVM, which moves the suspended virtual thread back onto a ready queue to be 'remounted' onto a carrier thread.
The result is non-blocking behavior with blocking syntax. You write synchronous code, but under the hood, the JVM is performing asynchronous scheduling.
Implementation: Coding with Virtual Threads
Creating Virtual Threads
Adopting virtual threads requires almost no code changes because they still implement the java.lang.Thread API. You can create them directly or via a factory:
// Create and start a virtual thread immediately
Thread.ofVirtual().start(() -> {
System.out.println("Running inside: " + Thread.currentThread());
});
// Using the Builder pattern
Thread vThread = Thread.ofVirtual()
.name("my-virtual-thread")
.unstarted(myRunnable);
vThread.start();However, in most web server contexts (like Spring Boot 3.2+ or Helidon Níma), you will interact with them via an ExecutorService. The new executor spins up a new virtual thread for every single task submitted, rather than pooling them:
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
IntStream.range(0, 10_000).forEach(i -> {
executor.submit(() -> {
Thread.sleep(Duration.ofSeconds(1));
return i;
});
});
} // Executor closes and waits for tasks automaticallyRethinking Concurrency Patterns
Goodbye Thread Pools: For decades, we pooled threads to limit resource consumption. With virtual threads, creation is so cheap that pooling is now an anti-pattern. You should create a new virtual thread for every concurrent task and let the garbage collector handle the cleanup.
Structured Concurrency: Virtual threads pair exceptionally well with the new Structured Concurrency API (currently a preview feature). This paradigm treats multiple tasks running in different threads as a single unit of work, streamlining error handling and cancellation. If one sub-task fails, the others can be automatically cancelled, preventing thread leaks and zombie processes.
Pitfalls and Best Practices
The Pinning Problem
While virtual threads are robust, they have a kryptonite: 'Pinning.' A virtual thread is pinned to its carrier thread if it attempts to yield while inside a synchronized block or a native method (JNI). When pinned, the JVM cannot unmount the virtual thread, meaning the underlying OS thread remains blocked.
If you have long-running blocking operations inside synchronized blocks, you will starve the carrier thread pool. The solution is to modernize your locking strategy. Replace synchronized with ReentrantLock, which allows the virtual thread to unmount correctly:
// Avoid this with Virtual Threads if doing I/O inside
synchronized(lock) {
blockingOperation();
}
// Do this instead
lock.lock();
try {
blockingOperation();
} finally {
lock.unlock();
}When Not to Use Them
Virtual threads are designed for throughput (I/O), not latency (CPU). If your application performs heavy number crunching, video encoding, or cryptographic hashing, virtual threads offer no benefit. In fact, they may add slight overhead due to the switching logic. Continue using platform threads for CPU-bound tasks.
Additionally, be wary of ThreadLocal. Many legacy frameworks store heavy context objects in thread-local variables. Since you might now have millions of threads instead of hundreds, replicating large objects across all of them can rapidly lead to an OutOfMemoryError.
The Future of Java Concurrency
Java 21 has fundamentally altered the landscape of server-side development. We can now return to the simplicity of the 'thread-per-request' model without sacrificing the performance required by modern, high-scale architecture. We no longer have to choose between code that is easy to read and systems that are fast to run.
Virtual threads remove the compromise. They allow us to write boring, linear code that handles millions of concurrent connections. If you haven't yet, it is time to upgrade to JDK 21 and start profiling your I/O-heavy applications. The era of callback hell is over; the era of high-throughput simplicity has begun.
Building high-performance applications requires reliable tools. When you're debugging data payloads or configuring new environments, check out the ToolShelf JSON Formatter and Base64 Encoder—all privacy-first and offline-capable.
Stay secure & happy coding,
— ToolShelf Team