偏向锁在有其他线程竞争时触发撤销，需进入安全点遍历栈帧检查锁持有状态，超20次撤销则批量禁用该类新对象的偏向锁。
偏向锁在什么条件下会触发撤销
偏向锁不是永久持有的，当有其他线程尝试获取同一把锁时，JVM 就必须撤销当前线程的偏向状态。这个过程不发生在加锁时，而是在 monitorenter 检测到竞争时触发，且需要进入安全点（safepoint）——意味着所有 Java 线程必须暂停，由 VM 线程统一处理。
- 撤销动作本身开销较大：要遍历该对象的栈帧，检查是否还有线程正持有该锁（即锁记录还在其栈中），若有则需升级为轻量级锁；若无，则直接将 Mark Word 恢复为未锁定状态
- 一旦某个类的锁被撤销超过 20 次（默认阈值，由
-XX:BiasedLockingBulkRevokeThreshold控制），JVM 会批量禁用该类所有新对象的偏向锁，后续新建实例直接走轻量级锁路径 - 如果应用启动后长时间运行、多线程频繁争用某类对象锁，偏向锁反而成为性能负优化——此时建议用
-XX:-UseBiasedLocking彻底关闭
轻量级锁如何通过 CAS 实现无阻塞竞争
轻量级锁本质是“基于 CAS 的自旋锁”，它不依赖操作系统互斥量（mutex），而是在线程栈中创建一个 Lock Record，尝试用 CAS 将对象头的 Mark Word 替换为指向该记录的指针。
- 成功：表示抢锁成功，对象进入轻量级锁定状态，Mark Word 高 30 位存
Lock Record地址，低 2 位为00 - 失败：说明已有其他线程抢先设置了该字段，当前线程进入自旋逻辑（默认 10 次，由
-XX:PreBlockSpin控制），反复尝试 CAS；若自旋失败，则膨胀为重量级锁 - 注意：自旋不是空等，JVM 会根据前一次自旋结果和系统负载动态调整次数，但 JDK 6/7 中基本固定为 10 次，JDK 8 后已移除此参数，改由自适应策略决定
锁升级不可逆，但对象可能从未经历完整流程
所谓“锁升级”是描述 Mark Word 状态变迁的术语，并非每个对象都会从偏向→轻量→重量依次走过。实际路径高度依赖运行时场景：
- 单线程反复加锁同一对象：始终停留在偏向锁状态（除非显式禁用或触发批量撤销）
- 两个线程交替执行、无真正竞争：可能长期维持轻量级锁，因为自旋大概率成功
- 多个线程高频争用：很快自旋失败，直接升级为重量级锁，此时 Mark Word 存储的是指向
ObjectMonitor的指针，低 2 位变为10 - 对象被 GC 回收后，其锁状态自然消失；新分配的对象从偏向锁开始（除非所属类已被批量撤销偏向）
如何验证当前对象所处的锁状态
JDK 自带工具 jol（Java Object Layout）是最直接的方式，配合 JVM 参数可观察 Mark Word 布局变化：
立即学习“Java免费学习笔记（深入）”；
import org.openjdk.jol.info.ClassLayout;
public class LockStateDemo {
public static void main(String[] args) throws InterruptedException {
Object obj = new Object();
System.out.println(ClassLayout.parseInstance(obj).toPrintable());
synchronized (obj) {
System.out.println(ClassLayout.parseInstance(obj).toPrintable());
}
}
}
输出中关注 hashCode、age、biased_lock、lock 字段组合。例如：00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001（最后 3 位为 001）表示无锁；... 101 表示轻量级锁；... 010 表示重量级锁；... 101 + 偏向线程 ID 则为偏向锁。
真正容易被忽略的是：锁状态藏在对象头里，而对象头布局受 JVM 版本、是否开启压缩指针（-XX:+UseCompressedOops）、是否启用偏向锁等多重影响，不同环境下的 Mark Word 长度和字段偏移都不同——别只背“最后两位是锁标志”，先确认你的 JVM 实际配置。
