Virtual Threads, In Depth

Virtual threads arrived in Java 21 and quietly changed how you should think about concurrency. You may have met them in the Spring path; here we go under the hood - how they work, where they help, and the one pitfall (pinning) that a senior engineer must know.

Platform threads vs. virtual threads

A traditional platform thread is a thin wrapper over an OS thread: expensive (about a megabyte of stack), limited to a few thousand, and wasted while blocked on I/O. A virtual thread is scheduled by the JVM, not the OS - it costs a few hundred bytes, you can have millions, and the JVM unmounts it from its carrier OS thread whenever it blocks:

// each request on its own virtual thread - millions are fine
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    for (var request : requests)
        executor.submit(() -> handle(request));   // blocking code, but cheap to block
}

When handle blocks on a database or HTTP call, the virtual thread unmounts and its carrier OS thread is freed to run another virtual thread. The blocking call looks blocking, but it no longer ties up a scarce OS thread - so simple, readable, imperative code scales like async.

Why this changes the calculus

Before virtual threads, high I/O concurrency forced a hard choice: thread-per-request (simple but limited) or reactive/async (scalable but complex, hard to debug). Virtual threads mostly dissolve that tension: you write straightforward blocking code and get async-level scalability. For the majority of I/O-bound server workloads, virtual threads are now the simpler default, and reactive is reserved for genuine streaming and backpressure needs.

The pinning pitfall

The one thing to watch: a virtual thread can become pinned to its carrier - unable to unmount - if it blocks while holding a synchronized monitor, or during a native call. A pinned thread ties up its OS carrier, defeating the benefit under load:

// risk: blocking inside synchronized pins the virtual thread to its carrier
synchronized (lock) {
    result = blockingIoCall();   // ← pinned! the carrier can't be reused
}

// prefer a ReentrantLock, which does not pin across a blocking call
lock.lock();
try { result = blockingIoCall(); }
finally { lock.unlock(); }

On hot paths, prefer ReentrantLock over synchronized when a lock is held across blocking I/O. (Recent JDKs continue to reduce pinning, but knowing the failure mode is the senior-level detail.)