Explain the internal working of the scheduler behind virtual threads?

The default scheduler is a dedicated instance of java.util.concurrent.ForkJoinPool running in FIFO mode (as opposed to the LIFO/work-stealing mode used by the common pool for parallel streams), separate from that common pool entirely.

Each worker thread in this pool is a carrier thread. Runnable virtual threads are represented internally as tasks; idle carriers pull the next runnable virtual thread from the queue, mount its continuation, and execute it until it blocks, yields, or finishes.

When a virtual thread becomes unmounted, it isn't re-queued instantly if it's simply waiting - it re-enters the runnable queue only once its blocking condition is satisfied (I/O ready, timer elapsed, lock acquired). The pool's parallelism, and thus how many virtual threads can truly run in parallel at once, is governed by jdk.virtualThreadScheduler.parallelism. While the scheduler is technically pluggable via an internal, non-public JDK mechanism, replacing it isn't a supported or common practice for application code.