自适应自旋通过JVM动态统计锁的近期自旋成功率、持有线程状态、系统负载等实时调整自旋次数，JDK 6起默认启用；它在锁长期占用、高并发争用或单核CPU等场景会降级为阻塞。
自适应自旋到底怎么“自适应”？
它不是靠固定次数硬等，而是 JVM 在运行时动态记账：同一个锁上最近几次自旋成功没、持有锁的线程是不是还在跑、上次成功用了多少次循环——这些数据会被实时统计，下次再抢这个锁时，就按“历史战绩”决定自旋多久。比如上次在 userLock 上 7 次就拿到锁，这次可能直接给 12 次机会；如果连续两次都旋到上限都没抢到，下次就干脆不旋，直接挂起线程。
- 自旋次数完全由 JVM 内部监控逻辑控制，
-XX:PreBlockSpin参数只影响「非自适应模式」下的默认值，开启自适应后基本失效 - 判断依据包括：锁对象的近期自旋成功率、当前持有锁线程是否处于
RUNNABLE状态、系统负载、CPU 核数等 - 这个机制从 JDK 6 开始默认启用，无需额外参数；关闭它反而要加
-XX:-UseAdaptiveSpinning
为什么不能全靠自旋？哪些场景它会“罢工”？
自适应只是优化策略，不是万能解药。当锁被长时间占用（比如同步块里做了 I/O 或 sleep），自旋再聪明也白搭——CPU 白转，线程卡死，吞吐暴跌。这时候 JVM 会快速降级：一旦检测到某把锁反复自旋失败，后续对该锁的所有请求都会跳过自旋，直接走传统阻塞流程。
- 典型失效场景：
synchronized块内调用Thread.sleep(100)、数据库查询、文件读写、远程 RPC 调用 - 高并发下若大量线程同时争同一把锁，自适应可能来不及收敛，仍会出现短时 CPU 飙高（
top看到 Java 进程 %CPU 接近 100%） - 单核 CPU 上自旋几乎无意义——没有其他线程能及时释放锁，纯属空耗
怎么验证自适应真的在工作？
不能只看参数，得看锁对象的实时状态和 GC 日志里的线索。最直接的方式是用 jstack 抓线程堆栈，观察 java.lang.Thread.State: RUNNABLE 下有没有大量线程卡在 Unsafe.park 前的忙循环附近；更准的是打开 JVM 锁竞争日志：
-XX:+PrintGCDetails -XX:+PrintSafepointStatistics -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -Xlog:monitoring=debug
- 关键指标看
spin和block的比例：如果某锁长期spin=0, block=1000+，说明自适应已判定它不适合自旋 - 用
jol（Java Object Layout）工具打印对象头，对比不同阶段mark word中锁标志位变化，可间接佐证是否走过轻量级锁+自旋路径 - 注意：JDK 15+ 默认禁用偏向锁（
-XX:+UseBiasedLocking已废弃），但自适应自旋仍有效，它作用于轻量级锁阶段
开发时最容易忽略的三个细节
很多人调了 -XX:PreBlockSpin=50 就以为“加大自旋力度”，结果发现毫无改善——因为根本没进自旋逻辑。问题常出在锁粒度或对象生命周期上。
- 锁对象要是堆上“真对象”，别用
new Object()临时变量——逃逸分析可能把它标为栈上分配，连 monitor 都不创建，更谈不上自旋 - 频繁新建锁对象（如每次方法调用都
new ReentrantLock()）会导致自适应无法积累历史数据，相当于每把锁都是“新手”，永远按保守策略来 - GC 会影响自适应判断：如果自旋期间触发了 STW GC，持有锁线程被暂停，等待线程却还在空转，JVM 可能误判为“锁持有时间长”，加速降级
自适应自旋不是开关，是 JVM 在锁争用、线程状态、硬件条件之间做的实时权衡——它聪明，但依赖你给它靠谱的锁对象和合理的同步范围。
