自适应自旋机制动态调控轻量级锁自旋次数，依据历史成功率、持有线程状态及系统负载实时调整，目标是在避免挂起开销与防止CPU空转间智能平衡，无需手动配置。
轻量级锁在锁竞争中不是静态的，它会根据实际运行时的争抢情况动态调整行为，核心目标是“能不升级就不升级”，尽量维持在用户态完成同步。
自适应自旋次数
JVM 不固定每次自旋 10 次或 20 次，而是基于历史表现做判断：
- 如果上一次在同一把锁上自旋成功了，且持有锁的线程仍在运行（比如还在 CPU 上执行），那么本次更倾向于多试几次；
- 如果上次自旋失败、锁很快被升级，或者持有线程已进入阻塞态，JVM 就会减少甚至跳过自旋，直接走锁膨胀路径；
- 这种调整由 JVM 内部统计逻辑驱动，无需手动配置，但可通过
-XX:+UseAdaptiveSpinning显式启用（JDK 6+ 默认开启）。
锁膨胀触发条件动态化
是否升级为重量级锁，不仅看自旋次数超限，还结合多个实时信号：
- 当前锁对象近期是否频繁发生竞争（JVM 维护锁对象级别的竞争热度计数）；
- 持有锁的线程是否处于 RUNNABLE 状态（若已 BLOCKED 或 WAITING，说明临界区可能较长，继续自旋意义不大）；
- 同一锁在短时间内是否连续多次膨胀又降级（触发批量锁优化策略，如批量撤销偏向锁后转向轻量级锁）。
锁记录与重入状态的本地化管理
每个线程在栈帧中维护自己的 Lock Record，这使得调整完全在用户态完成：
立即学习“Java免费学习笔记（深入）”；
- 当检测到锁重入，线程直接在自己栈里新增一条 Lock Record，不修改对象头，也不触发 CAS 失败；
- 解锁时逐条清理 Lock Record，只有最后一条释放时才尝试用 CAS 恢复 Mark Word；
- 这种设计让“竞争感知”天然绑定在线程本地，避免跨线程协调开销，也为自适应提供低延迟反馈基础。
配合逃逸分析与锁消除的协同优化
JVM 在 JIT 编译阶段会结合逃逸分析结果影响轻量级锁的实际行为：
- 若发现某个 synchronized 对象从未逃逸出当前方法（比如 new StringBuilder() 被锁住），即使有短暂竞争，也可能直接省略加锁流程（锁消除）；
- 若对象部分逃逸（如仅作为参数传入但未共享），JVM 可能推迟锁膨胀决策，给自旋更多机会；
- 这些优化不是运行时“调整锁”，而是编译期提前规避，本质是轻量级锁机制的上游协同策略。
