Virtual threads (Java 21)

The problem they solve

Traditional Java threads (now called platform threads) each map to an operating-system thread, which costs memory (often around 1 MB of stack reserved) and is expensive to create and switch. A server using one platform thread per request could handle only a few thousand requests at once, even though most of those threads spend their time just WAITING for databases and APIs. Developers worked around this with complex asynchronous (reactive) code.

A virtual thread is a thread that the JVM schedules itself. When it blocks on I/O, the JVM parks it (saves its small stack in memory) and runs another virtual thread on the same OS "carrier" thread. Blocking becomes cheap, so you can write simple, readable, blocking code and still handle huge numbers of concurrent requests.

try (ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor()) {
    for (int i = 0; i < 100_000; i++) {
        int id = i;
        executor.submit(() -> {
            Thread.sleep(Duration.ofSeconds(1));    // simulated blocking I/O
            return id;
        });
    }
}   // waits for all; 100,000 sleeping tasks finish in about 1 second

Thread vt = Thread.ofVirtual().name("order-", 0).start(() -> processOrder());
Thread.startVirtualThread(() -> sendSms());
System.out.println(vt.isVirtual());   // true

When they help, and when they do not

Guidelines

• Do not pool virtual threads; create one per task (newVirtualThreadPerTaskExecutor). They are cheap.
• Limit access to scarce resources (database connections, a partner API's rate limit) with a Semaphore or the connection pool, not by limiting threads.
• ThreadLocal works but becomes costly with millions of threads; avoid storing big objects in it.
• Frameworks support them: for example Spring Boot (3.2+) can run request handling on virtual threads with the property spring.threads.virtual.enabled=true.

Pinning (in brief)

In Java 21, a virtual thread that blocks while inside a synchronized block is "pinned" to its carrier OS thread, which reduces the benefit. Java 24 (JEP 491) removed most of this limitation for synchronized. On Java 21, prefer ReentrantLock around blocking I/O in hot paths; on newer JDKs this matters much less.