自适应自旋机制动态调控轻量级锁的自旋次数，依据历史成功率、持有线程状态、系统负载等实时调整，而非固定参数控制；-XX:PreBlockSpin已失效，现代JVM无直接配置方式。
现代 JVM（HotSpot，Java 8u292 及以后、Java 11+、Java 17+）中，轻量级锁的自旋次数**不再由固定参数硬编码控制**，而是由“自适应自旋（Adaptive Spinning）”机制全自动、实时调控。你无法通过命令行参数直接设定一个恒定的自旋次数，但可以间接影响其行为逻辑。
自适应自旋不是“可配置”的固定值
过去（Java 6 早期）曾用 -XX:PreBlockSpin=10 设定默认自旋上限，但该参数在启用自适应后已失效——JVM 内部会忽略它。当前所有主流 JDK 版本默认开启自适应，且无等效替代参数。所谓“修改”，实质是调整影响自适应决策的底层条件，而非覆盖次数本身。
真正起作用的三个调控维度
虽然不能设“自旋15次”，但可通过以下方式实质性改变 JVM 的自旋倾向：
- CPU 核心数与负载：JVM 在单核环境自动禁用自旋；多核空闲时更激进。可通过 -XX:+UseSpinning（已默认开启）确认启用，但无法反向关闭自旋逻辑
- 锁竞争历史信号：同一把锁若连续几次自旋失败，JVM 会快速降级为重量级锁流程。这意味着“让锁持有时间变短”或“减少临界区阻塞操作”（如避免 synchronized 块内 sleep、IO、DB 查询），能显著提升自旋成功率，从而让 JVM 主动延长下次自旋窗口
- 线程状态可观测性：若持有锁的线程处于 RUNNABLE 状态（未被挂起），JVM 判定“锁即将释放”，更愿多给几轮自旋；反之，若检测到其进入 TIMED_WAITING 或 BLOCKED，立即跳过自旋。因此，保持同步块内纯 CPU 计算，有助于维持高自旋意愿
哪些操作看似“修改”实则无效或危险
以下常见尝试在现代 JVM 中基本不起作用或违背设计原则：
立即学习“Java免费学习笔记（深入）”；
- -XX:PreBlockSpin=N：参数仍可写，但 HotSpot 源码中已被标记为 deprecated，实际不参与自适应计算
- -XX:-UseAdaptiveSpinning：该开关在 JDK 10+ 已被移除，强制禁用会导致回退到过时的静态策略，且可能引发性能劣化
- 手动插入 Thread.onSpinWait()：该方法仅是提示 CPU 当前处于忙等待，对 JVM 自旋次数决策无任何影响，它不参与锁获取流程控制
可观测与验证方式
要确认自适应是否生效、锁是否走轻量级路径，建议结合以下手段：
- 使用 -XX:+PrintGCDetails -XX:+PrintSafepointStatistics 辅助判断线程调度压力
- 通过 JFR（Java Flight Recorder）录制锁事件，筛选
jdk.JavaMonitorEnter，观察monitorClass和state字段，识别是否发生自旋等待（state = SPINNING）或直接阻塞（state = BLOCKED） - 配合 -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly（需 hsdis）查看热点锁的汇编指令，确认是否存在 CAS + 循环结构
