synchronized 的同步能力由 jvm 底层的 monitor 与对象头 mark word 协同实现，不依赖操作系统互斥量；monitor 关联每个 java 对象，含 _owner、_entrylist、_waitset 三字段；加锁解锁对应 monitorenter/monitorexit 字节码指令；锁状态存于 mark word，按无锁→偏向锁→轻量级锁→重量级锁逐级升级。
synchronized 的同步能力不是靠 Java 代码写的逻辑，而是由 JVM 在底层用 Monitor（监视器锁）配合对象头结构共同实现的。它不依赖操作系统互斥量，也不靠用户态轮询，而是一套内置于 JVM 的、与每个 Java 对象强绑定的协作机制。
Monitor 是 synchronized 的执行核心
每个 Java 对象在创建时，JVM 都会为其隐式关联一个 Monitor 实例（HotSpot 中是 ObjectMonitor 类的对象）。这个 Monitor 就是锁的实际载体，线程真正竞争的是 Monitor 的所有权，而不是“方法”或“代码块”本身。
Monitor 内部有三个关键字段：
- _owner：记录当前持有锁的线程 ID。同一时刻只能有一个线程填入这里；为空表示锁未被占用
- _EntryList：存放所有等待获取该锁的线程（处于 BLOCKED 状态），它们在锁释放后会竞争成为新 owner
- _WaitSet：存放调用 wait() 后主动释放锁并进入 WAITING 状态的线程，需靠 notify() 或 notifyAll() 唤醒
加锁和解锁实际走的是字节码指令
编译器把 synchronized 编译成两条 JVM 指令：monitorenter 和 monitorexit。
- 遇到 monitorenter 时，线程尝试将自己设为 Monitor 的 _owner；失败则进入 _EntryList 阻塞
- 遇到 monitorexit 时（包括正常退出或异常抛出），JVM 自动清空 _owner，并唤醒 _EntryList 中的一个线程
- 即使同步块里发生异常，JVM 也保证 monitorexit 会被执行——这是 synchronized 不用手动 try-finally 也能安全释放锁的根本原因
锁状态存在对象头的 Mark Word 里
Java 对象在堆中布局包含对象头，其中的 Mark Word 是个动态字段，随锁状态变化而复用存储内容：
- 无锁时存哈希值、GC 年龄等
- 偏向锁时存线程 ID 和 epoch
- 轻量级锁时存指向栈中 Lock Record 的指针
- 重量级锁时存指向 Monitor 对象的指针
也就是说，synchronized 初次执行时并不立即创建 Monitor，只有当锁升级到重量级（比如多个线程高竞争）时，才真正分配 Monitor 对象，并把其地址写进 Mark Word。
锁升级是自动发生的性能优化策略
JVM 不是一开始就上重量级锁。它按竞争程度逐步升级，顺序固定为：无锁 → 偏向锁 → 轻量级锁 → 重量级锁，且不可降级。
- 偏向锁适用于单线程反复进入同一同步块的场景，避免 CAS 开销
- 轻量级锁用 CAS 替换系统互斥，减少用户态/内核态切换
- 当自旋失败次数过多或有线程阻塞，就膨胀为重量级锁，真正挂起线程并依赖 Monitor 的 _EntryList 管理等待队列
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
