Why it is considered not a good idea to use vThreads for CPU bound tasks?

[mainul35]

I was revisiting the JugBD session on JDK21 vThreads, and the question popped in my mind to know in greater details about the problems that we can encounter, or in other words, the limitations of vThreads while using for CPU intensive tasks. Can you please share with greater details, please?

[danthe1st]

I am not the maintainer of this repository but I will still try to explain it from my perspective.

The big advantage of virtual threads is that the platform threads can be reused for other tasks (other virtual threads) while some task in blocking/waiting on something like I/O. They allow for higher CPU utilization when only a tiny part of the fraction of the time spent by threads is actually CPU time (when the threads are waiting for the majority of their lifetime).
There are a limited number of platform/carrier threads used for your virtual threads. If you do something CPU-intensive, you are not blocking hence that thread will continue using up one platform thread reducing the number of platform threads that can effectively be used for I/O bound operations via virtual threads resulting in other I/O bound tasks using virtual threads to get less CPU time when they actually want to do something.
In the worst case, you have at least as many CPU-bound tasks as carrier threads. If the CPU-bound tasks never block, the I/O bound tasks won't get to do any work as the JVM may not detach virtual threads if they are doing work. For example, take the following code:

for(int i=0;i<10;i++){
	Thread.startVirtualThread(()->{while(true);});//use up the carrier threads
}
Thread.startVirtualThread(()->System.out.println("Hi"));

If I run this on my system (configured with less than 10 carrier threads), I don't get any output.

On the other hand, the OS scheduler is made for pausing threads that are doing CPU work and allowing other threads to execute.

[mainul35]

Thank you for this detailed answer :)