java锁升级路径为无锁→偏向锁→轻量级锁→重量级锁，单向不可逆；jvm根据竞争动态切换对象头mark word状态，优先使用开销最小的锁以降低同步成本。
Java 通过在对象头的 Mark Word 中动态复用存储空间、引入分层锁状态（偏向锁 → 轻量级锁 → 重量级锁），显著降低无竞争或低竞争场景下的同步开销，从而减少系统耗时。核心不在于“修改”Mark Word，而在于 JVM 根据运行时竞争特征，自动选择开销最小的锁实现方式，并避免过早进入高成本的内核态阻塞。
Mark Word 是锁状态的“状态寄存器”
Mark Word 并非固定结构，而是一个紧凑的、按位复用的动态字段。以 64 位 JVM 为例，它共 64 bit，其中最后 3 位（bit 0–2）是锁状态标识位，直接决定当前锁属于哪种级别：
- 001：无锁状态（未加锁，可存 hashcode / GC年龄等）
- 101：偏向锁（记录偏向线程 ID + epoch，无 CAS 开销）
- 000：轻量级锁（指向线程栈中 Lock Record 的指针）
- 010：重量级锁（指向堆中 Monitor 对象的指针）
锁升级过程完全由 JVM 在运行时根据线程竞争行为触发，无需代码干预。这种“按需升级”避免了所有对象一启动就走重量级锁路径，大幅削减了指令数和内存访问延迟。
三种关键优化机制如何节省耗时
每种锁级别对应明确的性能边界，目标是让绝大多数同步操作停留在前两层：
- 偏向锁：适用于单线程反复进入同一同步块的场景（如 getter/setter、单例初始化）。首次获取时仅一次 CAS 设置线程 ID；后续重入直接比对线程 ID 即可，零同步指令开销。
- 轻量级锁：多线程偶发竞争时启用。线程在自己栈帧中创建 Lock Record，用 CAS 尝试将 Mark Word 替换为该记录地址。成功则进入临界区；失败则触发自旋（默认 10 次），避免立即挂起线程——省去用户态/内核态切换的微秒级代价。
- 重量级锁退让策略：当轻量级锁自旋失败次数超阈值（-XX:PretenureSizeThreshold 等参数影响），才膨胀为重量级锁。此时线程才真正阻塞，但已是“不得已而为之”，把最贵的操作留到最后。
配合 JVM 参数进一步收窄耗时
默认配置已较优，但在特定业务场景下可微调：
- 若应用大量短生命周期对象且极少竞争（如 Web API 高 QPS 低状态服务），可开启
-XX:+UseBiasedLocking（JDK 15+ 默认关闭，但 JDK 8–14 可启用）并适当延长偏向时限（-XX:BiasedLockingStartupDelay=0）； - 若临界区极短（-XX:PreBlockSpin=30）可能减少上下文切换；
- 使用
-XX:+PrintSynchronizationStatistics或 JOL 工具观察实际锁升级比例，若发现大量对象快速升到重量级锁，说明存在真实竞争瓶颈，应优先优化业务逻辑或缩小锁粒度，而非调参。
不依赖 Mark Word 的协同优化
Mark Word 本身只是载体，真正降耗依赖整套机制协同：
- 锁消除：JIT 编译器识别出同步块内变量逃逸不到方法外（如 StringBuffer append），直接删掉 synchronized 字节码；
- 锁粗化：连续多个同步块作用于同一对象，JIT 合并为一个更大范围的同步区域，减少重复加解锁开销；
-
对象头压缩：启用
-XX:+UseCompressedOops可将 Klass Pointer 从 64 位压至 32 位，间接缓解对象头内存压力，提升缓存局部性——这对高频创建同步对象的场景有间接加速效果。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
