Virtual threads, final since Java 21, are lightweight threads scheduled by the JVM onto a small pool of carrier threads. When one blocks on I/O it unmounts and frees its carrier, so a million concurrent tasks cost little. Practically, you write straightforward blocking code again and use a thread per request instead of an executor with a fixed pool, and you never pool virtual threads because creating one is cheap.
Why interviewers ask this
This is the biggest change to Java concurrency in a decade, so it separates people who track the platform from people who stopped at Java 8. The interviewer wants to hear the unmounting behavior, that virtual threads help with blocking I/O and not with CPU bound work, and that pooling them is an antipattern. It also opens up pinning, thread locals and how you now limit concurrency.
How to structure your answer
- Define them as JVM scheduled threads with cheap creation.
- Explain mounting and unmounting on a carrier thread during blocking calls.
- Say what changes in your code: thread per task, no pooling.
- Name the limits: CPU bound work, pinning, thread local cost.
Example answer
A virtual thread is scheduled by the JVM rather than the operating system, so it costs a few hundred bytes instead of a megabyte of stack. When it blocks on a socket read, it unmounts from its carrier platform thread and the carrier goes off to run something else, then it remounts when the data arrives. That means the old reason for pooling threads disappears. I use an executor that creates a virtual thread per task, and the code stays plain blocking code, which is far easier to read and debug than a chain of callbacks. Two things I keep in mind. First, they do nothing for CPU bound work, since you still only have as many cores as you have; the win is on I/O heavy request handling. Second, they remove the accidental concurrency limit that a fixed pool used to give me, so if I am calling a database with a fifty connection pool I put a semaphore or the pool itself in front, otherwise ten thousand virtual threads all pile onto it at once.
Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.
See how it worksFollow-up questions to expect
- What causes a virtual thread to pin its carrier, and is that still a problem?
- How do you limit concurrency to a downstream resource without a thread pool?
- Why are thread locals more expensive when you have a million threads?
Related java developer questions
Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.
Predict my questions