重量级锁本质是通过操作系统互斥量（如futex、pthread_mutex）实现线程阻塞与唤醒，而非用户态自旋；触发于synchronized锁升级后，多线程竞争失败时，JVM将对象头锁标志设为10，并关联含OS Mutex的Monitor，调用系统调用使线程陷入内核态挂起。
Java 中的“重量级锁”在激烈竞争时，本质是通过 操作系统层面的互斥量（mutex）或信号量（semaphore） 来实现线程阻塞与唤醒，而不是在用户态自旋或忙等。这发生在 synchronized 锁升级为重量级锁后，当多个线程争抢同一把锁失败时。
重量级锁触发条件
当一个线程尝试获取已被占用的 synchronized 锁，且轻量级锁（CAS 尝试）和偏向锁（线程匹配）都失败后，JVM 会将锁膨胀为重量级锁。此时：
- 对象头中的锁标志位被设为 “10”（表示重量级锁）
- 对象关联一个 Monitor 对象（C++ 实现，位于 JVM 堆外内存），其中包含一个 OS Mutex（如 pthread_mutex_t）和两个等待队列（EntryList、WaitSet）
- 后续竞争线程不再自旋，而是调用操作系统 API 进入休眠（如 Linux 下的 futex_wait 或 pthread_mutex_lock 阻塞）
操作系统互斥量如何介入
JVM 的 Monitor 在底层依赖操作系统的同步原语，典型实现路径如下：
- HotSpot 使用 futex（fast userspace mutex） 作为默认机制：无竞争时纯用户态操作；有竞争时通过 sys_futex 系统调用陷入内核，挂起线程
- 若 futex 不可用（如旧内核），则回退到 pthread_mutex_t —— 它在 glibc 中封装了内核的互斥机制（如 futex 或更底层的内核等待队列）
- 线程阻塞时，JVM 调用 os::PlatformEvent::park()，最终触发系统调用使线程进入 TASK_INTERRUPTIBLE 状态
- 锁释放时，JVM 调用 os::PlatformEvent::unpark()，唤醒等待队列中一个线程，后者重新进入就绪态参与 CPU 调度
激烈竞争下的行为特点
高并发争锁时，重量级锁会暴露操作系统调度开销，表现包括：
立即学习“Java免费学习笔记（深入）”；
- 频繁的用户态/内核态切换（syscall 开销）
- 线程上下文切换（context switch）增多，CPU 缓存失效加剧
- 可能出现“惊群效应”弱化版：notifyAll 唤醒多个线程，但仅一个能抢到锁，其余再次 park
- 锁的持有时间越长、临界区越重，竞争越明显，吞吐下降越显著
为什么不用纯 Java 实现？
因为用户态无法真正“让出 CPU 并等待事件”，必须依赖 OS 提供的阻塞原语：
- Java 线程模型映射到 OS 线程（1:1），park/unpark 底层就是 pthread_cond_wait / pthread_cond_signal
- 自旋锁（如 CAS）在竞争激烈时浪费 CPU，而重量级锁用 OS 调度换 CPU 节省
- 只有 OS 内核能安全管理线程状态、调度优先级、等待队列和唤醒公平性
