重量级锁底层依赖操作系统互斥量（mutex）和objectmonitor实现线程阻塞与唤醒，涉及用户态到内核态切换、上下文开销大、由os调度器管理，故称“重量级”。
Java 中的重量级锁（Heavyweight Lock）底层依赖操作系统提供的互斥机制，核心是通过 ObjectMonitor（监视器对象）与 操作系统互斥量（Mutex） 协同完成线程阻塞和唤醒，从而实现真正的互斥。
监视器锁（Monitor）不是 Java 关键字，而是 JVM 内部结构
每个 Java 对象在 JVM 中都关联一个 ObjectMonitor 实例（存储在对象头或同步块对应的栈帧中）。它由 C++ 实现，包含以下关键字段：
- _owner：指向持有该锁的线程（或 NULL）
- _WaitSet：等待被 notify 的线程队列（调用 wait() 后进入）
- _EntryList：等待获取锁的线程队列（竞争失败后挂起前加入）
- _recursions：重入计数（支持 synchronized 可重入）
当线程执行 synchronized(obj) 时，JVM 会尝试通过 CAS 修改 _owner 字段。若失败，则进入竞争流程，最终可能触发操作系统级别的阻塞。
重量级锁如何触发操作系统介入
轻量级锁和偏向锁失效后（如多线程高竞争），JVM 会将锁膨胀为重量级锁。此时：
- 所有后续竞争线程不再自旋，而是调用
ObjectMonitor::enter() - 该方法内部会调用
os::mutex_lock()（平台相关），例如 Linux 下使用pthread_mutex_t - 线程真正进入内核态，被 OS 调度器挂起（
pthread_mutex_lock阻塞），直到锁释放并被唤醒
注意：_EntryList 中的线程并非直接调用系统调用，而是由 JVM 在锁释放时统一唤醒其中一个，并由其再次尝试获取 mutex —— 这避免了“惊群效应”。
锁释放时的唤醒逻辑很关键
当持有锁的线程退出 synchronized 块，JVM 调用 ObjectMonitor::exit()：
- 先将
_owner置为 NULL - 若
_EntryList非空，从中取出一个线程，将其状态设为 RUNNABLE，并唤醒（Linux 下调用pthread_cond_signal或类似机制） - 若存在
_WaitSet中的线程（即调用了 wait），则不会在此刻唤醒——需显式 notify
这个过程确保了只有一个线程能真正重新进入临界区，达成互斥。
为什么说它是“重量级”
因为涉及：
- 用户态到内核态的切换（上下文切换开销大）
- 操作系统线程调度参与（不可控、延迟高）
- 内存屏障 + 全局锁（如 Mutex 内部可能用 futex 或更重的 sys_futex(FUTEX_WAIT)）
- 无法避免的队列管理与唤醒决策（JVM 自己维护 _EntryList）
相比 CAS 自旋或偏向锁的纯用户态操作，它的代价明显更高，但能保证强一致性与公平性（默认非公平，但可配置）。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
