The JVM will find a reasonable balance between these two cases, self-adjusting the amount
it spins before relegating a thread to a queue to be notified. There are parameters to tune the
spinning, but most of them are experimental, and all of them are subject to change, even
within minor update releases.
The only reasonable way to affect how the JVM treats spinning locks is something that
should be done in all cases anyway: make the synchronized blocks as short as possible. That
limits the amount of nonproductive spinning and makes it less likely that the thread will need
to be placed in the notify queue.
THE USESPINNING FLAG
Previous versions of Java supported a flag to enable or disable spin locks: -XX:+UseSpinning . In
Java 7 and beyond, that flag no longer has any effect: the use of spin locks cannot be disabled. For
backward compatibility, that flag is still accepted in Java 7 command lines up through 7u40, but it
is a no-op. Somewhat oddly, the default value for that flag is reported to be false , even through
spinning is always in effect.
Beginning in Java 7u40 (and in Java 8), that flag is no longer supported, and use of the flag will
generate an error.
Each Java thread has a developer-defined priority, which is a hint to the operating system
about how important the program thinks the particular thread is. If you have different threads
doing different tasks, you might think you could use the thread priority to improve the per-
formance of certain tasks at the expense of other tasks running on a lower-priority thread.
Unfortunately, it doesn't quite work like that.
Operating systems calculate a “current” priority for every thread running on a machine. The
current priority takes into account the Java-assigned priority, but it also includes many other
factors, the most important of which is how long it has been since the thread last ran. This
ensures that all threads will have an opportunity to run at some point. Regardless of its prior-
ity, no thread will “starve” waiting for access to the CPU.
The balance between these two factors varies among operating systems. On Unix-based sys-
tems, the calculation of the overall priority is dominated by the amount of time it has been
since the thread has last run—the Java-level priority of a thread has very little effect. On