是的，java中synchronized在重量级锁阶段不自旋，线程直接阻塞；自旋仅发生在轻量级锁阶段，由jvm自适应机制动态决定是否自旋及持续时间，不可通过参数固定配置。
Java 中悲观锁（如 synchronized）在竞争极度激烈时，不会在重量级锁阶段使用自旋——此时线程直接阻塞，不消耗 CPU。真正能调节自旋行为的，只发生在锁尚未膨胀为重量级锁前的轻量级锁阶段。也就是说，所谓“调节自旋次数”，本质是让 JVM 尽量避免进入重量级锁，或在轻量级阶段更理性地决定是否自旋、自旋多久。
轻量级锁阶段才是自旋发生的唯一窗口
当多个线程争抢同一个对象锁，且该锁处于轻量级状态（即未膨胀）时，后到线程会先尝试自旋获取。一旦自旋失败达到阈值，JVM 立即升级为重量级锁，线程挂起。因此：
- 重量级锁本身没有自旋逻辑，谈“调次数”无意义；
- 所有可影响的自旋行为，都集中在轻量级锁竞争这一短暂过渡期；
- 自旋是否发生、持续多久，由 JVM 自适应机制动态决定，而非固定参数控制。
现代 JVM 不支持直接配置自旋次数
JDK 8u292 及以后、JDK 11/17+ 中，-XX:PreBlockSpin 参数已被废弃，实际不参与决策；-XX:-UseAdaptiveSpinning 在 JDK 10+ 已移除。这意味着：
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 你无法通过 JVM 参数设定“自旋 20 次”这样的固定值；
- 所谓“调节”，是通过改变运行时条件，让自适应机制自动降低自旋倾向；
- 强行关闭自旋（
-XX:-UseSpinning）会导致性能劣化，不推荐。
真正有效的降功耗调节方式
要减少无意义 CPU 消耗，关键不是硬设次数，而是让 JVM 主动“觉得不值得自旋”：
- 缩短临界区执行时间：同步块内避免 IO、sleep、数据库调用、复杂计算，只做纯内存操作（如计数器++），这样持有锁时间短，自旋成功率高，JVM 才愿意多试几次；反之，若屡次自旋失败，JVM 会快速降级为重量级锁，反而规避了长自旋；
-
提升锁持有线程的可观测性：确保持有锁的线程保持
RUNNABLE状态（不进入WAITING或BLOCKED），JVM 才判断“锁即将释放”，否则直接跳过自旋； -
利用
Thread.onSpinWait()降低单次自旋开销：在每次重读锁状态前调用，可缓解 CPU 流水线压力和功耗（尤其在超线程 CPU 上），但必须配合volatile或VarHandle.getVolatile()使用，否则无效甚至引发死循环。
验证与观测建议
确认优化是否生效，应结合：
- 使用
-XX:+PrintGCDetails -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly（需 hsdis）观察锁膨胀日志； - 通过 JFR（Java Flight Recorder）采集
jdk.Locks事件，查看锁是否频繁走轻量级路径及膨胀比例； - 用
perf stat对比自旋循环段的cycles和idq_uops_not_delivered.core，验证onSpinWait()是否降低了前端压力。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
