回复：ForkJoinPool-3-worker pool size never size down

[何品(虎鸣)]

Thanks for the update, will that change be backport to j21u?
more context information:
I was using it as
```
 public static final ThreadFactory newVirtualThreadFactory(final String prefix) {
 return Thread.ofVirtual()
 .name(prefix + "-")
 .uncaughtExceptionHandler((t, e) -> {
 log.error("Uncaught exception in HSF biz processor, thread:[{}]", t, e);
 })
 .factory();
 }
 private static final ThreadFactory THREAD_FACTORY = newVirtualThreadFactory("HSFBizProcessor-VIRTUAL-");
 private final Lazy<LogAwareThreadPoolExecutor> executor = Lazy.of(() -> {
 final var executor = new LogAwareThreadPoolExecutor(
 32,
 2500, //max threads
 60,
 TimeUnit.SECONDS,
 new SynchronousQueue<>(false),
 THREAD_FACTORY,
 new ThreadPoolExecutor.AbortPolicy());
 return executor;
 });
```
and there are other executors too.
And when I testing , the threads' number grows to 2205.
And now I just add the `executor.allowCoreThreadTimeOut(true);` too all `ThreadPoolExecutor` which child thread is actual a virtual thread, seems not help much.
I think I should change the code to use the `Semaphore` and never pooling
------------------------------------------------------------------
发件人：Alan Bateman <Alan.Bateman at oracle.com>
发送时间：2024年1月12日(星期五) 20:38
收件人：何品(虎鸣) <hepin.p at alibaba-inc.com>; loom-dev <loom-dev at openjdk.org>
主　题：Re: ForkJoinPool-3-worker pool size never size down
 On 12/01/2024 12:29, 何品(虎鸣) wrote:
Hi I know, it was suggested that not pooling the VirtualThread, when I replace my old executors to use the fancy new `VirtualThreadExecutorFactory` and with the 
`jdk.virtualThreadScheduler.maxPoolSize` set to 2500
after some load testing and the thread size grow to 2205 
and even the stress testing is removed from the system , the thread never adjust to a smaller one. 
 There are changes in JDK 22 [1] so that trimming happens a lot more quickly when the pool is idle.
 -Alan
 [1] https://bugs.openjdk.org/browse/JDK-8319662 <https://bugs.openjdk.org/browse/JDK-8319662 >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240112/45a0cb4a/attachment-0001.htm>