synchronized锁升级本质是mark word的8字节位操作与monitor状态协同：无锁→偏向锁→轻量级锁→重量级锁，每次升级修改mark word并按新语义解释，monitor在重量级锁时被创建并管理_owner、_count和_entrylist。
要看 synchronized 锁升级的底层原理，核心就盯住两件事：对象头里的 Mark Word 怎么变，以及线程在竞争时怎么跟 Monitor 打交道。它不是抽象概念，而是内存里实实在在的位操作和状态跳转。
锁状态全靠 Mark Word 的 8 字节编码
Java 对象在堆中布局包含对象头，其中 Mark Word 占 8 字节（64 位 JVM + 压缩指针）。这 8 字节复用严重——同一块内存，不同状态下存不同东西：
- 无锁状态：存哈希码、分代年龄、锁标志位（01）
- 偏向锁：存线程 ID、Epoch、偏向锁标识（标志位仍是 01，但第 3 位为 1）
- 轻量级锁：存指向当前线程栈帧中“锁记录（Lock Record）”的指针，标志位变成 00
- 重量级锁：存指向 C++ 实现的 ObjectMonitor 对象的指针，标志位变成 10
每次锁升级，本质就是 JVM 修改这 8 字节的值，并按新语义解释它。没有新增字段，也不改对象大小，纯靠位重定义实现零开销切换。
Monitor 是锁行为的执行体
Monitor 不是 Java 类，是 HotSpot 用 C++ 实现的同步原语（ObjectMonitor），每个对象关联一个。它有三个关键字段：
- _owner：记录当前持有锁的线程指针
- _count：可重入计数器（进一次 +1，出一次 -1）
- _entryList：竞争失败、被挂起的线程队列（Blocked 状态）
当锁升级到重量级，Mark Word 就写入指向这个 Monitor 的指针；后续所有加锁/解锁/等待/唤醒操作，都通过操作 Monitor 的这三个字段完成。轻量级锁阶段 Monitor 还没被创建，只有真要阻塞时才懒加载。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
升级不是主动“选”，而是被动“退让”
锁升级不是 JVM 预判后提前升，而是一次次竞争失败触发的退让过程：
- 偏向锁撤销：另一个线程来抢锁 → JVM 在安全点暂停所有线程 → 清空偏向信息 → 升为轻量级锁
- 轻量级锁膨胀：自旋一定次数（默认 10 次）仍抢不到 → 放弃 CPU 空转 → 创建 Monitor → 把自己挂进 _entryList → Mark Word 改写为 Monitor 指针
整个过程不可逆。一旦升级到重量级，即使之后长期只有单线程访问，也不会降回轻量级或偏向锁——避免反复判断和状态清理的开销。
字节码是入口，monitorenter 是起点
你写的 synchronized(obj) { ... }，编译后变成：
- 字节码指令
monitorenter：尝试获取 obj 关联的 monitor 所有权 - 字节码指令
monitorexit：释放所有权
JVM 执行 monitorenter 时，会根据 Mark Word 当前值决定走哪条路径：检查线程 ID（偏向）、CAS 替换锁记录（轻量）、还是调用操作系统 mutex（重量）。所有分支最终都汇聚到 Monitor 的状态机上。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
