Java virtual threads in outline: what changes and what does not

What it is

JEP 444 describes a virtual thread as an instance of java.lang.Thread that is not tied one-to-one to an operating-system thread. A scheduler (a ForkJoinPool in FIFO mode whose parallelism defaults to the number of available processors) mounts a virtual thread on a platform thread, its carrier; when the virtual thread blocks on I/O or another blocking JDK operation it unmounts and the carrier takes other work. Stacks live in the heap as stack-chunk objects and grow and shrink. Thread.ofVirtual(), Thread.startVirtualThread(r) and Executors.newVirtualThreadPerTaskExecutor() create them, and they are always daemon threads. The JEP is explicit that virtual threads are not faster threads: they provide scale (throughput), not speed (latency), and CPU-bound work gains nothing from having more of them than there are cores.

Why it matters

For engineers arriving from Go or from C# async, the point is that Java keeps the thread-per-request style, including loops, try/catch and ordinary blocking JDBC or HTTP calls, while removing the OS-thread ceiling that pushed code into reactive or CompletableFuture pipelines. Code built on ExecutorService migrates by swapping the executor, which is why the JEP offers Executors.newThreadPerTaskExecutor alongside the virtual-thread factory.

How to apply

• Do not pool virtual threads; create one per task. To limit concurrency towards a downstream resource, use a Semaphore, which both the JEP and the core-libraries guide name as the intended construct.
• Review ThreadLocal use: a thread-local cache of an expensive object, sensible in a pool of fifty threads, is created per request under virtual threads. The JEP points to scoped values as an alternative.
• Check pinning: in JDK 21 a virtual thread that blocks inside a synchronized block or method, or inside a native frame, pins its carrier. -Djdk.tracePinnedThreads=full and the JFR event jdk.VirtualThreadPinned (enabled by default with a 20 ms threshold) show where. JEP 491 in JDK 24 removes pinning for synchronized and Object.wait() and drops the jdk.tracePinnedThreads property (the JFR event stays); native frames, class loading and class initialisers still pin.
• Expect flat thread dumps to be useless with a million threads; the JEP adds jcmd <pid> Thread.dump_to_file -format=json.
• Keep platform threads for CPU-bound loops and for work that never blocks.

Pitfalls

Some blocking operations (many file-system calls, Object.wait() before JDK 24) capture the OS thread; the scheduler compensates temporarily up to jdk.virtualThreadScheduler.maxPoolSize. Libraries that hold monitors around I/O limit scaling until updated. Frameworks must opt in; a server still on a fixed platform-thread pool sees no change. Structured concurrency, a separate JEP, is the intended way to manage groups of virtual threads.