重量级锁是线程被操作系统挂起并用mutex lock排队的锁机制，触发用户态到内核态切换，开销达数百纳秒至微秒级；表现为jstack中大量blocked线程停在objectmonitor::enter或park，且cpu低、吞吐骤降。
重量级锁就是线程被操作系统挂起的那一刻
当 synchronized 升级为重量级锁，它就不再靠 CPU 自旋或对象头标记硬扛了，而是真真切切地把线程交给操作系统，用 Mutex Lock（互斥量）来排队。这个过程会触发用户态到内核态的切换——也就是常说的“上下文切换”，开销不小，一次可能耗掉几百纳秒甚至微秒级，远超轻量级锁的几十纳秒。
常见错误现象：
- 多个线程频繁争抢同一把锁，jstack 看到大量线程处于 BLOCKED 状态，且堆栈停在 ObjectMonitor::enter 或 park 调用上；
- 应用 CPU 使用率不高，但吞吐骤降、响应变慢，GC 日志没异常，却查不到热点代码——问题很可能卡在锁的阻塞等待上。
- 触发条件：轻量级锁自旋失败 + 竞争持续（JVM 默认自旋10次，由
-XX:PreBlockSpin控制），或存在多个线程同时进入临界区 - 本质代价不是“加锁本身”，而是每次锁获取/释放都伴随一次系统调用（
pthread_mutex_lock/unlock），以及线程状态在RUNNABLE → BLOCKED → RUNNABLE之间的切换 - 注意：即使锁住的是一个空方法，只要升级为重量级，照样触发内核态切换——锁内容是否耗时不影响这个开销
怎么确认你的锁已经变“重”了
别猜，直接看运行时状态。重量级锁最稳的证据是对象头 Mark Word 里存着指向 ObjectMonitor 的指针，而该 monitor 的 _owner 字段非空，且 _EntryList 或 _WaitSet 里有线程节点。
- 用
jhsdb jmap --heap --pid <pid></pid>查对象头（需 JDK 9+），找 Mark Word 值以0x0000000000000001结尾（表示偏向锁未启用）但高位是地址（如0x00007f8a1c00a200），大概率是重量级锁指针 - 更实用：用
jstack -l <pid></pid>，搜索- waiting to lock，后面那个地址就是 monitor 地址；再配合jmap -histo:live <pid> | head -20</pid>看是否有大量java.lang.Thread.State: BLOCKED线程 - 注意：JDK 1.6+ 默认开启偏向锁，如果测试前没关（
-XX:-UseBiasedLocking），刚启动时多数是偏向锁，要等竞争出现后才升级——别在单线程压测初期下结论
为什么不能靠“减少同步块长度”来避免重量级锁
缩短 synchronized 代码块，确实能降低临界区执行时间，但它对是否升级为重量级锁影响极小。决定升级的，是“有没有其他线程正在等这把锁”，而不是“你里面干了啥”。哪怕你只做 count++，只要两个线程几乎同时到达，照样可能膨胀。
- 真正有效的干预点只有三个：降低竞争频率（如分段锁、CAS 替代）、让竞争不集中（如用
ThreadLocal避免共享）、或提前阻止升级（如启动时关闭偏向锁 + 轻量级锁，强制走重量级但配好线程池控制并发数） - 参数
-XX:BiasedLockingStartupDelay=0和-XX:-UseBiasedLocking在高并发服务启动初期很有用，避免偏向锁撤消（revoke）带来的 STW 小暂停 - 别迷信“锁粒度越细越好”——过细的锁（比如每个元素一把锁）会显著增加对象头和 monitor 内存开销，反而推高 GC 压力，得不偿失
轻量级锁自旋失败后，不是立刻进重量级，中间还有个“膨胀过渡”
JVM 不会一拍脑袋就把锁变重。从轻量级锁升级，实际经过“膨胀（inflate）”过程：先尝试分配 ObjectMonitor 对象，初始化其字段（_owner = NULL, _EntryList = NULL 等），再用 CAS 把对象头 Mark Word 改成指向该 monitor 的指针。这个过程本身也有竞争——多个线程同时想 inflate 同一把锁，只有一个成功，其余会退回去继续自旋或直接阻塞。
- 这意味着：同一时刻看到多个线程
BLOCKED，不代表它们全卡在重量级锁的等待队列里，有些可能正卡在 inflate 的 CAS 重试循环中 -
-XX:+PrintGCDetails不管用，要看锁行为得加-XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1，观察no vm operation阶段的停顿是否与锁膨胀相关 - 最容易被忽略的一点：monitor 是堆外分配（C++ new 出来），不受 GC 管理，但会随 Java 对象生命周期被 JVM 异步回收——如果锁长期存在，monitor 对象就一直占着本地内存，可能成为隐形内存泄漏源
重量级锁不是 bug，是 JVM 在竞争不可避时的务实选择；但它的代价藏在上下文切换和内核调度里，看不见摸不着，偏偏又最拖慢高并发场景的实际响应。
