Virtual threads and structured concurrency question 116 of 180 senior
When do virtual threads not help?
- They always help
- Correct: For CPU-bound work, where the core count is still the limit, and for anything pinned or native; they solve blocking, not computation
- For any workload with more than 1000 tasks
- For database access
Virtual threads make blocking cheap. They do not create CPU capacity. A thousand virtual threads doing matrix multiplication finish no sooner than a pool of N platform threads, and you have added scheduling overhead. Keep CPU-bound work on a sized pool.
Other cases to name: work that is pinned (native frames, or monitors on an older JVM) gets no benefit;
ThreadLocal caching that assumed a small fixed number of threads can now allocate a copy per task,
which is the reverse of the intended optimisation; and downstream resources such as a connection pool
of 20 remain the real bottleneck, so a million virtual threads just move the queue somewhere less
visible.
Also worth saying: memory is not free either. A deep stack still costs heap, and a million idle threads with deep stacks is a real number in your heap dump.
Quiz yourself on Virtual threads and structured concurrency Suggest a correction