Java 21 Virtual Threads: A Simple Path to High Concurrency

Virtual threads became stable in Java 21 after years of development under the name Project Loom. In one sentence: you can now run millions of concurrent tasks with the simplicity of the classic thread-per-request model, but without the cost of platform threads.

This post explains what virtual threads are, why they matter, and how to use them in real code — plus the pitfalls to know before you fall into them. For more Java content, see my Java page.

The problem: platform threads are expensive

A classic Java thread (a platform thread) maps one-to-one to an operating-system thread. Each reserves ~1 MB of stack and is scheduled by the OS. We’d love “one thread per request” because the code stays simple and readable — but after a few thousand threads, memory and context-switching costs stop you.

That’s why for years we reached for reactive and asynchronous APIs: CompletableFuture, callback chains, reactive streams… Performant, but hard to read and debug.

What is a virtual thread?

A virtual thread is a lightweight thread scheduled by the JVM. It is not permanently bound to an OS thread; it only mounts onto a carrier platform thread while it is actually doing work (using the CPU). When it blocks on an I/O call (network, file, database), the JVM unmounts it from the carrier and hands the carrier to another virtual thread.

The result: tens of thousands of virtual threads run on a handful of OS threads.

flowchart TD
    subgraph JVM
      V1[Virtual thread 1] --> C1[Carrier thread]
      V2[Virtual thread 2] --> C1
      V3[Virtual thread 3] --> C2[Carrier thread]
      V4[Virtual thread N] -.waiting on I/O.-> P[(Parked)]
    end
    C1 --> OS[(OS thread pool)]
    C2 --> OS

How to create one

The simplest way to start a virtual thread:

1
Thread.startVirtualThread(() -> {
2
    System.out.println("Hello, virtual world!");
3
});

In practice you manage tasks with an ExecutorService. The key is to use the executor that starts a new virtual thread per task.

1
import java.util.concurrent.Executors;
2

3
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
4
    for (int i = 0; i < 10_000; i++) {
5
        int taskId = i;
6
        executor.submit(() -> {
7
            // I/O-bound work — e.g. an HTTP call
8
            var result = callRemoteService(taskId);
9
            process(result);
10
        });
11
    }
12
} // executor.close() waits for all tasks to finish

Those 10,000 tasks run without opening 10,000 OS threads, and the code stays fully synchronous and readable.

Step by step: enabling it in Spring Boot

With Spring Boot 3.2+ you can enable virtual threads with a single setting:

When to use it, when to avoid it

Watch out: the “pinning” trap

If a virtual thread blocks on I/O while inside a synchronized block, it gets pinned to its carrier thread and can’t release it. Lots of pinning can erase the entire benefit of virtual threads.

1
synchronized (lock) {
2
    // ❌ Long I/O under a lock → pinning
3
    var data = database.query(sql);
4
    cache.put(key, data);
5
}

1
private final ReentrantLock lock = new ReentrantLock();
2

3
// ✓ ReentrantLock does not cause pinning
4
lock.lock();
5
try {
6
    var data = database.query(sql);
7
    cache.put(key, data);
8
} finally {
9
    lock.unlock();
10
}

Conclusion

Virtual threads make concurrency in Java simple again: write synchronous code, yet scale high. The key rules:

• Start a new virtual thread per task; don’t pool.
• Use them for I/O-bound work; stay on classic pools for CPU-bound work.
• Avoid synchronized + long I/O; use ReentrantLock.
• Always measure.

For more, browse the #java and #concurrency tags, or the curated Java page.