Why doesn't a blocked virtual thread block its carrier platform thread?

When a virtual thread calls a blocking operation the JDK has been updated to recognize, most blocking I/O, Thread.sleep, and many java.util.concurrent locks, the JDK's internal code, rather than simply blocking the OS thread, unmounts the virtual thread's continuation from its current carrier thread and parks it.

Unmounting means the carrier thread is freed immediately to pick up and run a different, ready virtual thread from the scheduler's queue, instead of sitting idle waiting for the original operation to finish.

Once the blocking operation completes, whether data arrives, a timer fires, or a lock becomes available, the virtual thread is placed back on the scheduler's ready queue and gets re-mounted onto some available carrier thread, not necessarily the same one it started on, to resume exactly where it left off.

This mount/unmount cycle is invisible to application code; a blocking call still just looks like a blocking call, but the OS thread underneath it is being time-shared across potentially thousands of logically "blocked" virtual threads.

One caveat: some operations still cannot be unmounted - notably code inside a synchronized block or method that blocks, or certain native/JNI calls - which "pins" the virtual thread to its carrier for that duration, and is a known area to watch for when migrating blocking legacy code to virtual threads.