Java synchronized 本质是JVM对C++实现的ObjectMonitor的封装，锁的是对象本身而非变量，通过monitorenter/monitorexit指令操作Monitor的_owner、_EntryList和_WaitSet。
Java synchronized 本质是靠 Monitor 实现的
它不是语言层面的魔法，而是 JVM 对 ObjectMonitor 的封装调用。每个 Java 对象头里都藏着一个指向 ObjectMonitor 的指针（在偏向锁撤销或升级后才真正分配），真正加锁、等待、唤醒这些动作，全由这个 C++ 实现的 Monitor 对象完成。
常见错误现象：以为 synchronized(obj) 是“锁住 obj 这个变量”，其实锁的是 obj 引用所指向的堆对象本身；如果 obj 被重新赋值，新旧对象的锁完全无关。
- Monitor 不是 Java 类，不能 new，也不在 Java 堆中，而是在 JVM native 内存里分配
- 一个对象同一时刻只能有一个线程持有其 Monitor，但可以被多个线程争抢或等待
- Monitor 内部有 _owner（当前持有者）、_EntryList（等待获取锁的线程队列）、_WaitSet（调用
wait()后挂起的线程队列）
monitorenter 和 monitorexit 指令怎么工作的
编译器把 synchronized 块转成一对字节码指令：monitorenter 在入口处执行，monitorexit 在所有可能出口（包括异常路径）插入。JVM 执行时，这两条指令会触发对底层 ObjectMonitor 的 acquire/release 操作。
使用场景：你看到 javap -v 输出里的 monitorenter，就说明这段逻辑确实走的是 JVM 内置锁路径，不是被 JIT 优化掉或替换成其他同步机制（比如偏向锁未启用时）。
立即学习“Java免费学习笔记（深入）”；
-
monitorenter先尝试轻量级锁（CAS 替换对象头 Mark Word），失败则膨胀为重量级锁，进入 Monitor 的竞争流程 -
monitorexit必须和配对的monitorenter使用同一个 Monitor，否则抛IllegalMonitorStateException - try-finally 编译后会有两个
monitorexit：一个在正常 return 前，一个在 catch 块里处理异常后
synchronized 方法和代码块的 Monitor 获取时机不同
方法级 synchronized 的锁获取发生在方法调用开始前，由 JVM 在 entry point 自动插入 monitorenter；而同步代码块的锁获取发生在执行到 { 大括号那一行时。这意味着：方法锁更早介入，也更容易因方法内提前 return 或异常导致锁持有时间不可控。
参数差异：方法锁隐式使用 this（实例方法）或类 Class 对象（静态方法）作为锁对象；代码块必须显式传入一个非 null 引用，灵活性更高，但也更容易写出锁粒度不当的代码。
- 静态方法锁的是
MyClass.class，不是某个实例，所有该类的静态同步方法共用一把锁 - 如果同步块里锁的是局部新建对象（如
new Object()），那根本起不到同步作用——每次都是新锁 - JIT 编译后，简单同步块可能被消除（锁消除），但方法级锁更难优化
Monitor 状态变化和线程阻塞的真实开销在哪
真正昂贵的不是 CAS 尝试，而是当 Monitor 已被占用、线程不得不进入 _EntryList 并挂起（park）的时候。这时线程从 RUNNING 变成 WAITING，涉及用户态到内核态切换、调度器介入、上下文保存——一次 park/unpark 往往比百次 CAS 还重。
性能影响：高竞争下，Monitor 会快速从偏向锁 → 轻量级锁 → 重量级锁升级，一旦进入重量级，所有后续争抢都会触发 OS 线程调度，吞吐量断崖下降。
- Monitor 不支持超时获取（不像
ReentrantLock.tryLock(long, TimeUnit)），要么拿到，要么一直等 - wait/notify 必须在已持有 Monitor 的前提下调用，否则抛
IllegalMonitorStateException - 即使没有线程等待，
notify()也不会报错，只是没效果；这点容易被忽略，导致唤醒丢失
Monitor 的复杂性不在代码里，而在多线程环境下状态转换的隐蔽性——比如一个线程刚释放锁，另一个还没来得及 acquire，中间发生的 wait/notify 就可能失效。写的时候得盯着锁对象生命周期和调用顺序，而不是只看语法是否合法。
