Virtual threads created more platform threads

[Alan Bateman]

On 02/07/2025 06:50, Jianbin Chen wrote:
> :
>
> Thank you and everyone for your patient answers. I verified this with 
> JDK 24, and the same example did not show platform thread growth. 
> However, there's one thing I don't understand: why are these threads 
> never reclaimed? Most of them are in a waiting state - isn't this a 
> waste of resources? Sometimes it increases by hundreds of threads. Is 
> there any way to suppress this behavior on JDK 21?

Just to confirm what was already said. The stack trace in the issue 
shows Netty DefaultPromise.await in Object.wait. Prior to JDK 24 this 
pinned the carrier thread. The implementation (prior to JDK 24) attempts 
to compensate for this by arranging for a spare platform thread (FJP 
worker) to be available. This seems to be what you are seeing. The 
number of threads won't grow to more than 256. The "Implementation Note" 
section of the Thread class description documents the system property to 
change this limit if necessary. It's very possible that setting it to a 
number will cause the system to hang/deadlock as no virtual thread can 
make progress if they are all blocked in Object.wait and waiting for 
another virtual thread to notify.

As regards trimming. The idle workers will terminate once a keep alive 
time (30s, not configurable) is reached but only if the system is idle 
(at quiescent in FJP speak). In a busy system, or even a tiny load such 
as heart beat, then it may not happen. There were improvements in JDK 22 
[1] but it still requires that the system be idle for threads to terminate.

-Alan

[1] https://bugs.openjdk.org/browse/JDK-8319662