How do Virtual Threads (Project Loom) change the JVM's threading model in Java 21?

Virtual threads, finalized in Java 21 via JEP 444, add a second kind of Thread that the JVM itself schedules, instead of mapping every Thread 1:1 onto a heavyweight OS thread.

A virtual thread's stack and execution state are represented as a JVM-managed continuation stored on the heap, which starts small and can grow, rather than a fixed multi-megabyte OS thread stack reserved up front. This is what makes creating millions of virtual threads practical, where creating millions of platform threads would exhaust OS resources almost immediately.

Virtual threads are scheduled cooperatively onto a small, fixed pool of ordinary platform threads called carrier threads, by default one per CPU core, using a work-stealing ForkJoinPool scheduler under the hood.

This lets ordinary, sequential, thread-per-request style code, the style most developers already write and reason about easily, scale to huge numbers of concurrent, blocking operations like waiting on I/O without needing to be rewritten in a reactive or callback-based style just to avoid tying up OS threads.

Structurally, the public Thread API stays the same: Thread.ofVirtual().start(...) or Executors.newVirtualThreadPerTaskExecutor() create virtual threads that are used exactly like platform threads from calling code's point of view - the scheduling difference is transparent to most application logic.