轻量级锁自旋失败不会立即膨胀，而是在至少两个线程竞争且有线程决定阻塞时，由JVM检查Mark Word并升级为重量级锁，使用ObjectMonitor和操作系统互斥量，状态不可逆。
Java 轻量级锁在自旋失败后，并不会“自动”膨胀为重量级锁，而是由 JVM 在**下一次尝试获取该锁时**，根据当前锁状态和竞争情况，直接升级为重量级锁（即使用操作系统互斥量 mutex）。这个过程的关键不在于“自旋失败”本身触发膨胀，而在于**锁对象的 Mark Word 状态变更与竞争检测机制**。
轻量级锁的自旋只是优化手段，不是锁升级的触发条件
轻量级锁在加锁时会尝试用 CAS 将对象头的 Mark Word 替换为指向当前线程栈中 Lock Record 的指针。如果失败（说明有竞争），JVM 会先执行有限次数的自旋（如 10 次，具体由 -XX:PreBlockSpin 控制，JDK 6+ 默认已废弃该参数，实际自旋逻辑更依赖系统负载和锁持有时间）。
但要注意：自旋失败 ≠ 锁膨胀。此时锁仍处于轻量级锁状态，Mark Word 仍保留原值或轻量级锁标识；只是当前线程暂时没抢到锁，可能让出 CPU 或进入阻塞队列等待。
真正触发膨胀的时机：当有线程尝试进入重量级锁获取流程时
锁膨胀发生在**至少两个线程竞争同一把锁，且其中一个线程无法通过轻量级锁机制（CAS + 自旋）成功获取锁，并决定进入阻塞状态**的时刻。此时 JVM 执行以下关键步骤：
立即学习“Java免费学习笔记（深入）”；
- 检查对象头 Mark Word 是否为轻量级锁状态（即是否包含指向 Lock Record 的指针）；
- 调用操作系统 mutex（如 pthread_mutex_t）创建重量级锁，并将 Mark Word 更新为指向 ObjectMonitor 的指针；
- 所有后续对该锁的请求（包括之前自旋失败的线程）都必须走重量级锁的 enter/exit 流程，即挂起、唤醒等系统调用。
换句话说：第一个调用 monitorenter 但发现轻量级锁已失效（比如锁已被其他线程持有且未释放）、且判断继续自旋不划算的线程，会主动发起锁膨胀。
膨胀后的状态不可逆，且影响所有持有者
一旦膨胀为重量级锁：
- 原轻量级锁对应的 Lock Record 失效，线程释放锁时不再恢复轻量级状态；
- 即使之后只剩一个线程访问，该锁也保持重量级，直到对象被 GC（注意：锁状态不会自动降级）；
- ObjectMonitor 中维护着 _EntryList（等待队列）和 _WaitSet（wait 队列），所有阻塞/唤醒均由 JVM 委托 OS 完成。
如何验证锁是否已膨胀？
可通过 -XX:+PrintLocks（部分 JDK 版本支持）、-XX:+PrintBiasedLockingStatistics，或更常用的是使用 JOL（Java Object Layout）工具打印对象头：
- 轻量级锁：Mark Word 低 3 位为
00，剩余位存 Lock Record 地址； - 重量级锁：Mark Word 低 3 位为
10，剩余位存 ObjectMonitor* 地址； - 可通过
ClassLayout.parseInstance(obj).toPrintable()查看实时状态。
