Virtual Threads (Java 21)

#Introduction

Traditional Java threads are platform threads — thin wrappers around OS threads. They're expensive, so servers cap them at a few hundred, and when every thread is waiting on a database or HTTP call, the server can't accept more work even though the CPU is idle. Virtual threads are lightweight threads managed by the JVM, so cheap that you can run millions of them — making the simple one thread per request style scale again.

#Platform Threads vs Virtual Threads

#How Virtual Threads Work

Virtual threads run on a small pool of platform threads called carrier threads (a ForkJoinPool sized to the number of cores):

Your code still looks blocking — plain restTemplate.getForObject() or jdbcTemplate.query() — but the underlying OS thread never sits idle waiting. You get the scalability of asynchronous code with the readability of synchronous code.

#Creating Virtual Threads

// Start one directly
Thread vt = Thread.ofVirtual().name("order-", 1).start(() -> processOrder(order));

// Shorthand
Thread.startVirtualThread(() -> sendEmail(user));

// Most common: an executor that creates a new virtual thread per task
try (ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor()) {
    for (Order order : orders) {
        executor.submit(() -> processOrder(order));
    }
}   // close() waits for all tasks

// A factory for frameworks that accept ThreadFactory
ThreadFactory factory = Thread.ofVirtual().name("worker-", 0).factory();

Ten Thousand Concurrent Blocking Tasks

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    IntStream.range(0, 10_000).forEach(i ->
            executor.submit(() -> {
                Thread.sleep(Duration.ofSeconds(1));   // simulates a 1-second I/O call
                return i;
            }));
}

This finishes in about one second. With a fixed pool of 200 platform threads it would take about 50 seconds; with 10,000 platform threads it would need roughly 10 GB of reserved stack.

#Thread-per-Request, Again

Virtual threads improve throughput for I/O-bound concurrency: many requests that spend most of their time waiting. They don't make any single request faster, and they don't help CPU-bound work — there are still only as many carriers as cores.

#Pinning

A virtual thread is pinned when it can't unmount while blocked, so it holds its carrier thread hostage:

On Java 21–23, long blocking calls inside synchronized (for example, a JDBC driver that synchronizes internally) could exhaust all carrier threads. The usual fix was replacing synchronized with ReentrantLock around blocking code. Diagnose with -Djdk.tracePinnedThreads=full (Java 21–23) or the JFR event jdk.VirtualThreadPinned.

#Rules for Using Virtual Threads

Don't Pool Them

Pooling exists to amortize expensive creation — virtual threads are cheap. Create a new virtual thread per task; newVirtualThreadPerTaskExecutor() does exactly that.

Limit Concurrency with Semaphores, Not Pool Sizes

With platform threads, a pool of 20 implicitly limited calls to a fragile service to 20. With virtual threads, nothing limits them — so 10,000 requests become 10,000 simultaneous calls. Protect downstream resources explicitly:

private final Semaphore paymentApiPermits = new Semaphore(20);

public Receipt charge(Payment p) throws InterruptedException {
    paymentApiPermits.acquire();
    try {
        return paymentClient.charge(p);
    } finally {
        paymentApiPermits.release();
    }
}

Database connection pools (HikariCP) still cap database concurrency — size them deliberately, because thousands of virtual threads will now queue for connections.

Be Careful with ThreadLocal

Each virtual thread has its own thread-locals. With millions of threads, caching large objects in ThreadLocals (a common trick with pooled platform threads) multiplies memory use. Prefer ScopedValue (final in Java 25) for request context.

They Don't Help CPU-Bound Work

For computation, use a bounded platform-thread pool or Fork/Join sized to the cores.

#Virtual Threads in Spring Boot

Spring Boot 3.2+ on Java 21 enables them with one property:

spring.threads.virtual.enabled=true

This makes Tomcat/Jetty handle each request on a virtual thread, and configures @Async, @Scheduled task execution, and several messaging listeners to use virtual threads.

#Structured Concurrency (Preview)

Structured concurrency (StructuredTaskScope, still a preview API in recent JDKs) treats a group of related subtasks as one unit of work: they start together, are joined together, and if one fails the others are cancelled.

// Preview API — requires --enable-preview, and its exact shape has changed between JDK releases
try (var scope = StructuredTaskScope.open()) {
    var user   = scope.fork(() -> userService.find(id));
    var orders = scope.fork(() -> orderService.recent(id));
    scope.join();                                      // waits for both; fails if either fails
    return new Dashboard(user.get(), orders.get());
}

It brings to concurrent code what structured programming brought to control flow: subtasks can't outlive the block that created them, so there are no leaked threads and cancellation is automatic. Until it's final, CompletableFuture or an ExecutorService in try-with-resources is the production choice.

#Virtual Threads vs Reactive Programming

For many typical CRUD and microservice workloads, virtual threads give most of the scalability benefit with much simpler code. Reactive still shines for streaming and complex event-driven pipelines.

#Key Takeaways

• Virtual threads are lightweight JVM-managed threads, final in Java 21.
• Blocking calls unmount them from carrier threads, so millions can wait concurrently.
• They boost throughput for I/O-bound work, not CPU-bound work.
• Don't pool them; limit concurrency explicitly.
• synchronized pinning was fixed in Java 24; native calls can still pin.
• Spring Boot enables them with spring.threads.virtual.enabled=true.