<div dir="auto">OK I understand now, thank you again for your help.<br><br><div data-smartmail="gmail_signature">Best Regards.<br>Jianbin Chen, github-id: funky-eyes </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Alan Bateman <<a href="mailto:alan.bateman@oracle.com">alan.bateman@oracle.com</a>> 于 2025年7月3日周四 14:52写道：<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On 03/07/2025 02:14, Jianbin Chen wrote:<br>
> Sorry to bother you all again. When using virtual threads on JDK 21, <br>
> I've always been concerned about potential pinning situations, so <br>
> during testing in our offline environment, we always add the <br>
> -Djdk.tracePinnedThreads=full parameter. However, we have never seen <br>
> any pinned-related information output. Yesterday I conducted a test <br>
> and found that when using synchronized + object.wait(), even though <br>
> the maximum number of platform threads used by virtual threads has <br>
> already reached the limit, it still cannot output pinned-related logs. <br>
> But if I switch to synchronized + Thread.sleep(), it can output the <br>
> logs. I'm providing my example and JVM parameters below, hoping <br>
> someone can help explain this issue. Thank you very much.<br>
<br>
That rudimentary tracing/debug option printed a stack trace when a <br>
virtual thread parked inside a synchronized method. It didn't help with <br>
Object.wait or other cases.<br>
<br>
Once you get to JDK 24+ you can drop -Djdk.tracePinnedThreads=full as <br>
this system property has no effect. The changes to object monitors in <br>
JDK 24, and the improvements to JFR events for pinning in the same <br>
release, means the tracing option isn't needed.<br>
<br>
-Alan<br>
<br>
</blockquote></div>