I'll second what Alan said. What I've found to be true, over and over, is that every API needs its own (broad) performance testing, since memory access patterns, instructions-under-critical-section, and differences in scheduling across different platforms all interact.
It's worth having a look at how busy-waiting is implemented in different java.util.concurrent constructs. Cheers, √ Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: core-libs-dev <core-libs-dev-r...@openjdk.org> on behalf of Alan Bateman <alan.bate...@oracle.com> Sent: Monday, 16 June 2025 17:23 To: Markus KARG <mar...@headcrashing.eu> Cc: core-libs-dev <core-libs-dev@openjdk.org> Subject: Re: Best Practice for Busy Waiting in Java On 16/06/2025 12:09, Markus KARG wrote: > > > In case you MUST use busy-wait, apply the following rules: > > > * NEVER have EMPTY busy-wait loops, but ALWAYS put Thread.onSpinWait() > into it. The performance drop is negligible but the CO2 footprint is > considerably smaller. > > * IF it is acceptable for the waiting thread to not have the > *absolute* maximum throughput, put Thread.yield() before > Thread.onSpinWait() in the busy-wait loop, so CPU cores are more > efficiently used. > > * Never use Thread.sleep() in busy-wait loops. > > * If possible, pin current thread to current CPU core to prevent > inefficient context switches. > > * ...more rules... > > > THAT is what my question is targeting! :-) > It may be possible to provide some guidelines but I don't think they can be turned into rules, e.g. the NEVER example is challenged by methods that do atomic increment/add/etc. as this read+CAS in a tight loop. There are also examples that of tight loops to CAS an object to the add it to a list. The examples of onSpinWait in the JDK might give you some ideas, e.g. using it in conjunction with a max spin count before timed back off or parking. One thing to add to your list is virtual threads where it may be better to park rather than Thread.yield. -Alan
