Performance Issues with Virtual Threads + ThreadLocal Caching in Third-Party Libraries (JDK 25)

Jianbin Chen jianbin at apache.org
Sat Jan 24 13:07:54 UTC 2026


Hi Alan,

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.

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.

Thank you,
Jianbin Chen

Alan Bateman <alan.bateman at oracle.com> 于2026年1月24日周六 16:34写道:

>
>
> On 24/01/2026 05:55, Jianbin Chen wrote:
> > :
> >
> > I constructed the Executor directly with
> > Executors.newVirtualThreadPerTaskExecutor();
> > however, the run results still show that the pooled virtual‑thread
> > behavior outperforms the non‑pooled virtual threads.
>
> This looks like it is benchmarking Thread.sleep so a different topic to
> that of libraries that are caching objects in thread locals.
>
> For the Thread.sleep test then it would easier to discuss if converted
> to a JMH benchmark as there are warmup issues in the test you included.
> Also just to note that the Thread.sleep implementation has changed
> significantly changed since JDK 21 so you will see very different
> results with JDK 25 runs (some of the messages in the discussion speak
> of JDK 21, the subject line in the mails say "JDK 25", so I'm guessing
> you might be testing both).
>
> -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260124/1f580761/attachment.htm>


More information about the loom-dev mailing list