JVM对轻量级锁和偏向锁的优化发生在运行时，由JIT编译器与对象头状态协同实现；逃逸分析仅影响锁消除，不决定偏向锁或轻量级锁的启用，后者依赖Mark Word动态变更和线程竞争情况。
Java 并发中，JVM 对轻量级锁和偏向锁的优化不是编译期完成的，而是运行时由即时编译器（JIT）和对象头状态协同实现的；所谓“编译期优化”容易误解——synchronized 关键字在编译阶段只生成 monitorenter 和 monitorexit 字节码指令，真正的锁策略决策全部发生在运行时。
逃逸分析是锁消除的前提，不是轻量级锁或偏向锁的直接依据
逃逸分析（Escape Analysis）由 JIT 编译器在方法内联后执行，用于判断对象是否“逃逸”出当前线程或方法作用域：
- 若一个对象在方法内创建、未被返回、未被赋值给静态字段或传入其他线程可见结构（如全局容器），JVM 认定它“未逃逸”
- 未逃逸的对象，JVM 可能做三件事：栈上分配、标量替换、锁消除
- 注意：锁消除只针对 完全无竞争可能 的锁，比如
StringBuffer sb = new StringBuffer(); sb.append("a").append("b");中的同步方法调用——JIT 会直接去掉monitorenter/exit指令 - 但逃逸分析 不决定 是否启用偏向锁或轻量级锁；它只影响“要不要加锁”，而偏向/轻量级锁解决的是“怎么高效加锁”
偏向锁的启用与撤销全在运行时，依赖对象头 Mark Word 动态变更
偏向锁不是编译器生成的，而是 JVM 在对象首次被 synchronized 进入时，检查其 Mark Word 状态后动态设置的：
- 对象新建后处于无锁状态（Mark Word 标志位为
01，biased_lock=0） - 首次加锁时，若开启偏向锁（默认开启），JVM 尝试用 CAS 将当前线程 ID 写入 Mark Word，并将 biased_lock 设为 1 → 进入偏向锁状态
- 后续同一线程再次进入，只需比对 Mark Word 中线程 ID 是否匹配，无需 CAS 或互斥操作
- 当有其他线程尝试获取该锁时，触发偏向锁撤销（revoke）：暂停目标线程，将对象升级为轻量级锁（Mark Word 改为指向栈中 Lock Record，标志位变
00）
轻量级锁靠 CAS 和自旋维持低开销，不依赖逃逸分析
轻量级锁是无竞争或短竞争场景下的过渡机制，核心是避免进入操作系统互斥量：
立即学习“Java免费学习笔记（深入）”；
- 当偏向锁被撤销，或对象初始就不支持偏向（如已禁用偏向锁），JVM 在加锁时会在当前线程栈中创建一个 Lock Record，用 CAS 将其地址写入对象 Mark Word
- 若 CAS 成功，锁获取成功；失败则说明存在竞争，进入自旋等待（默认最多 10 次）
- 自旋期间线程不挂起，仍在用户态轮询 Mark Word 是否恢复为无锁/轻量级状态；自旋失败才膨胀为重量级锁
- 整个过程完全基于运行时对象状态和线程栈操作，与逃逸分析无关
真正影响锁行为的配置项都在 JVM 启动参数里
开发者可通过参数显式控制这些机制是否生效，而非通过代码或编译选项：
-
-XX:+UseBiasedLocking：启用偏向锁（JDK 15+ 默认关闭，JDK 8–14 默认开启） -
-XX:BiasedLockingStartupDelay=0：跳过启动延迟，让偏向锁立即可用 -
-XX:+UseHeavyMonitors：强制禁用所有优化锁，全部走重量级路径（调试用） -
-XX:PreBlockSpin=15：调整轻量级锁自旋次数 - 逃逸分析需配合
-XX:+DoEscapeAnalysis（JDK 8+ 默认开启）
