Java 21 Virtual Threads and Structured Concurrency

Direct Answer

Virtual threads are lightweight JVM-managed threads that mount on a small pool of OS (carrier) threads. When a virtual thread blocks on IO, it unmounts, freeing the carrier for another virtual thread. This enables a thread-per-request model at scale without the memory cost of millions of platform threads.

Deep Dive & Architecture

Virtual threads (JEP 444, Java 21 GA) are lightweight, JVM-managed threads that let you write simple one-thread-per-request blocking code while scaling to millions of concurrent threads.

They look and feel identical to java.lang.Thread (they are subclasses) but are scheduled by the JVM onto a small pool of carrier threads (by default, ForkJoinPool sized to CPUs).

When a virtual thread hits a blocking I/O call (socket read, HTTP, JDBC), the JVM unmounts it from the carrier — stack gets parked on the heap, carrier goes to serve another virtual thread. The memory cost is kilobytes, not megabytes — a platform thread's 1 MB default stack becomes a resizable heap object. Create them with Thread.ofVirtual().start(task) or Executors.newVirtualThreadPerTaskExecutor(). The goal: kill thread pools for I/O-bound server code and let you write straight-line blocking logic without callback hell or reactive complexity.

Pinning is when a virtual thread cannot be unmounted from its carrier — usually because it's inside a synchronized block or executing a native (JNI) frame. While pinned, any blocking I/O holds the carrier thread, defeating the whole point of Loom. If many virtual threads pin simultaneously on blocking I/O, carriers get exhausted: no virtual thread can run because there's no free carrier.

Common Mistakes & Pitfalls

Assuming virtual threads make CPU-bound code faster. They don't. Virtual threads only help when threads block on IO — they free the carrier thread to run other virtual threads during the block.