JVM 自旋等待由参数间接控制且自适应，不可手动设置精确时间；-XX:+UseAdaptiveSpinning 默认启用，按锁对象统计成功率动态调整次数，上限硬编码为30～100次，仅适用于短临界区、低竞争场景。
自旋等待时间不是靠手动设的，JVM 自己决定
Java 里 LockSupport.park() 或 synchronized 进入轻量级锁竞争时的自旋，并没有开放 API 让你写 setSpinTime(10) 这种调用。所谓“设置”，实际是通过 JVM 参数间接影响，而且只在特定锁状态（如偏向锁撤销后、轻量级锁自旋）下生效。
常见误解是以为能像线程 sleep 那样精确控制自旋毫秒数——其实不能。HotSpot 的自旋是循环检测锁标志位，次数由 JVM 动态估算，和 CPU 核心数、历史成功概率强相关。
-
-XX:+UseSpinning：JDK 6 默认开启，JDK 7+ 已废弃（但部分版本仍识别），开启后才启用自旋逻辑 -
-XX:PreBlockSpin=10：仅在 JDK 6 有效，指定固定自旋次数；JDK 7 起该参数被忽略，改用自适应策略 - 真正起作用的是
-XX:+UseAdaptiveSpinning（JDK 6+ 默认开启），它让 JVM 根据上一次自旋是否抢到锁来动态调整下次次数
自适应自旋到底怎么“适应”？看 hotspot 源码逻辑
HotSpot 在 ObjectSynchronizer::fast_enter 和 BiasedLocking::revoke_and_rebias 等路径中维护每个对象的自旋成功率统计。不是全局统一值，而是按对象（或更准确地说，按锁对象的 hash 值分桶）记录最近几次自旋是否成功。
这意味着：同一个锁在不同线程反复争抢时，JVM 会逐步加大自旋次数；如果连续几次都失败，就会快速退化为挂起线程（进入 OS Mutex 等待）。
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 自旋失败后线程会调用
os::yield_all()或直接 park，避免空转耗尽 CPU - 自旋只发生在多核机器上；单核 CPU 下默认禁用自旋（因为 yield 就等于让出全部时间片）
- 自旋最大次数上限硬编码在 hotspot 源码里（如
ObjectSynchronizer::max_spin_count），通常为 30～100 次，不暴露给用户配置
为什么你看到的“自旋没效果”？三个高频原因
不是策略失效，而是场景不匹配。自旋只对「持有时间极短 + 竞争不激烈」的锁有效。一旦不符合，JVM 会主动放弃。
- 锁内执行了 I/O、sleep、wait、阻塞队列操作 → 线程大概率被挂起，自旋立即终止
- 多个线程持续高频率争抢同一把锁（比如热点计数器）→ JVM 快速判定自旋成功率低，降级为重量级锁
- 使用了
ReentrantLock且未开启公平模式，但底层 AQS 的acquireQueued不走 JVM 自旋逻辑，而是用 CAS + park，此时-XX参数完全无效
验证方式：加 -XX:+PrintGCDetails -XX:+UnlockDiagnosticVMOptions -XX:+PrintCompilation，观察是否出现 spin 相关日志（极少输出，说明自旋已退化）。
想真正控制等待行为？换到应用层做
JVM 层的自旋不可控、不可见、不可调试。真要精细调控，得绕过 synchronized 和内置锁，用显式并发工具。
- 用
LockSupport.tryParkNanos(long nanos)+ 循环 CAS 实现带超时的自旋（注意别漏掉Thread.interrupted()检查） - 对读多写少场景，优先考虑
StampedLock的乐观读，它本质就是无锁自旋 + 版本校验 - 如果业务允许，把临界区拆小，或用
LongAdder替代synchronized counter++，从源头消除竞争
最常被忽略的一点：自旋优化永远排在「减少锁范围」「避免伪共享」「用无锁结构替代」之后。先看代码能不能不锁，再想怎么旋。旋得再快，也快不过不锁。
