<div dir="auto"><div>Hi Alan,</div><div dir="auto"><br></div><div dir="auto">Thank you for your detailed explanation, but I still have some questions.</div><div dir="auto"><br></div><div dir="auto">I added these parameters to limit platform threads: </div><div dir="auto">-Djava.util.concurrent.ForkJoinPool.common.parallelism=2 -Djdk.virtualThreadScheduler.parallelism=2 -Djdk.virtualThreadScheduler.maxPoolSize=2 -Djava.util.concurrent.ForkJoinPool.common.maximumSpares=2.<div dir="auto"> </div><div dir="auto">Initially, I only added `jdk.virtualThreadScheduler.maxPoolSize=2`, but I found it had no effect. I then thought this parameter only limits the number of platform threads for normal virtual threads and doesn't cover cases with pinned threads. So I added the java.util.concurrent.ForkJoinPool.common.maximumSpares parameter again, but it still had no effect - the threads keep growing. My JDK version is Temurin OpenJDK 21.0.7+6. I've also attached the jstack stack trace information.<br><br><div data-smartmail="gmail_signature" dir="auto">Best Regards.<br>Jianbin Chen, github-id: funky-eyes </div></div><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">Alan Bateman <<a href="mailto:alan.bateman@oracle.com">alan.bateman@oracle.com</a>> 于 2025年7月2日周三 14:31写道：<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On 02/07/2025 06:50, Jianbin Chen wrote:<br>
> :<br>
><br>
> Thank you and everyone for your patient answers. I verified this with <br>
> JDK 24, and the same example did not show platform thread growth. <br>
> However, there's one thing I don't understand: why are these threads <br>
> never reclaimed? Most of them are in a waiting state - isn't this a <br>
> waste of resources? Sometimes it increases by hundreds of threads. Is <br>
> there any way to suppress this behavior on JDK 21?<br>
<br>
Just to confirm what was already said. The stack trace in the issue <br>
shows Netty DefaultPromise.await in Object.wait. Prior to JDK 24 this <br>
pinned the carrier thread. The implementation (prior to JDK 24) attempts <br>
to compensate for this by arranging for a spare platform thread (FJP <br>
worker) to be available. This seems to be what you are seeing. The <br>
number of threads won't grow to more than 256. The "Implementation Note" <br>
section of the Thread class description documents the system property to <br>
change this limit if necessary. It's very possible that setting it to a <br>
number will cause the system to hang/deadlock as no virtual thread can <br>
make progress if they are all blocked in Object.wait and waiting for <br>
another virtual thread to notify.<br>
<br>
As regards trimming. The idle workers will terminate once a keep alive <br>
time (30s, not configurable) is reached but only if the system is idle <br>
(at quiescent in FJP speak). In a busy system, or even a tiny load such <br>
as heart beat, then it may not happen. There were improvements in JDK 22 <br>
[1] but it still requires that the system be idle for threads to terminate.<br>
<br>
-Alan<br>
<br>
[1] <a href="https://bugs.openjdk.org/browse/JDK-8319662" rel="noreferrer noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8319662</a><br>
</blockquote></div></div></div>