A platform thread is a 1:1 wrapper over an OS thread — heavyweight and scheduled by the kernel. A virtual thread is a lightweight thread managed by the JVM, with its stack on the heap, multiplexed M:N onto a small pool of platform carrier threads. Both are java.lang.Thread.
Cost and count
A platform thread reserves a large stack (often ~1 MB) and consumes a kernel scheduling entity, so a JVM tops out around a few thousand. A virtual thread starts at a few hundred bytes, grows its heap stack on demand, and is created in microseconds — millions can exist at once. That is the whole point: you stop treating threads as a scarce resource you must pool.
Scheduling
Platform threads are scheduled preemptively by the OS. Virtual threads are scheduled cooperatively by the JVM onto carrier threads (a ForkJoinPool). A virtual thread holds a carrier only while running; on a blocking I/O call it unmounts and frees the carrier for other work. There is no preemption between virtual threads, so a tight CPU loop will hog its carrier.
// Platform: scarce, pool them
ExecutorService pool = Executors.newFixedThreadPool(200);
// Virtual: abundant, one per task, never pooled
try (var exec = Executors.newVirtualThreadPerTaskExecutor()) {
for (var task : tasks) exec.submit(task);
}
Thread platform = Thread.ofPlatform().start(r);
Thread virtual = Thread.ofVirtual().start(r);What is the same
Same Thread API, same InterruptedException, same thread-local support, same stack traces and debugger experience. You write ordinary blocking, sequential code. A virtual thread is always a daemon and you cannot set its priority or make it non-daemon — those carry no meaning for it.
When each fits
Virtual threads shine for high-concurrency blocking I/O (thread-per-request servers, fan-out RPC). They give no benefit for CPU-bound work — there you want exactly as many platform threads as cores. The mental model: virtual threads convert blocking-but-simple code into something that scales like async-but-complex code, without the callback coloring.