It' s recommended by JDK developers that virtual threads should never be pooled, because they are really cheap to create and destroy. I am a little confusing about the pooling idea, since pooling usually means two things:
I understand that JDK developers want us to never reuse a virtual thread, and the lifecycle question confuses me, because if there are multiple virtual thread having lifecycle as long as the application itself, it might sounds like pooling without reuse.
So should a virtual thread die fast, or having a short bounded lifecycle, or is it OK that multiple virtual threads were blocking, once in a while waken up to process some tasks, and having a really long lifecycle?
There are several main reasons why objects might be pooled.
They are expensive to create or destroy. Pooling means that you get to amortize these costs over multiple uses.
They consume a finite resource that you want to manage the consumption of. Pooling means that you can bound the resource consumption by setting a limit to the pool.
Both of these considerations apply to platform threads; creating them is expensive, and they consume significant memory. If you created a platform thread for every task, you could easily run out of memory.
Note that pooling is very rarely a benefit on its own; at best, it is better than the alternatives (such as unbounded thread creation.) Used objects are usually worse than new objects, since they might have leftover state from previous use (such as orphaned ThreadLocal values.)
Neither of these considerations apply to virtual threads.
It is possible, however, that code running in a virtual thread may require the use of a finite resource, such as a database connection. In these cases, you want to manage the consumption of those resources, such as pooling the connections, or using a semaphore to limit how many of a certain kind of task can run at once. But none of these considerations argue for pooling virtual threads.