<div dir="ltr">Hi Alan,<br><br>I ran my example on JDK 21 because it uses Thread.sleep. In an earlier message on the mailing list I learned that virtual‑thread performance on JDK 25 was worse for this kind of scenario compared with JDK 21, and that the issue is supposed to be fixed in JDK 25.0.3 — which has not been released yet. <br><br>That said, this does not affect the main point of my message: I’m asking for advice about using pooled virtual threads to work around third‑party libraries that implement buffer pools via ThreadLocal.<br><br>Thank you,  <br>Jianbin Chen</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Alan Bateman <<a href="mailto:alan.bateman@oracle.com">alan.bateman@oracle.com</a>> 于2026年1月24日周六 16:34写道：<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 24/01/2026 05:55, Jianbin Chen wrote:<br>
> :<br>
><br>
> I constructed the Executor directly with <br>
> Executors.newVirtualThreadPerTaskExecutor();<br>
> however, the run results still show that the pooled virtual‑thread <br>
> behavior outperforms the non‑pooled virtual threads.<br>
<br>
This looks like it is benchmarking Thread.sleep so a different topic to <br>
that of libraries that are caching objects in thread locals.<br>
<br>
For the Thread.sleep test then it would easier to discuss if converted <br>
to a JMH benchmark as there are warmup issues in the test you included. <br>
Also just to note that the Thread.sleep implementation has changed <br>
significantly changed since JDK 21 so you will see very different <br>
results with JDK 25 runs (some of the messages in the discussion speak <br>
of JDK 21, the subject line in the mails say "JDK 25", so I'm guessing <br>
you might be testing both).<br>
<br>
-Alan<br>
</blockquote></div>