轻量级锁不支持高并发扩容，本质是低竞争场景下的自旋优化机制；当自旋超限或多线程同时争抢时，会升级为重量级锁，导致吞吐断崖下跌。
synchronized 轻量级锁本身不支持“高并发扩容”——它不是可伸缩的锁机制，而是一个过渡态；所谓“边界”和“拐点”，实际是它向重量级锁升级的临界条件。
轻量级锁的本质：自旋竞争 + 无阻塞等待
轻量级锁不是为高并发设计的，而是为低竞争、短持有、线程交替执行的场景优化。它的核心逻辑是：
- 当偏向锁被第二个线程干扰时，JVM 将锁撤销并升级为轻量级锁
- 后续线程通过 CAS 原子操作尝试将对象头中的 Mark Word 替换为指向自己栈帧中锁记录的指针
- 若 CAS 失败（说明已有其他线程在竞争），当前线程会进入自旋（spin）状态，反复重试获取锁，而非立即挂起
- 自旋期间线程仍在用户态运行，避免了内核态切换开销
性能拐点：自旋失败后升级为重量级锁的那一刻
轻量级锁的“拐点”不是由并发线程数绝对值决定的，而是由以下两个动态因素共同触发：
-
自旋次数超限：JDK 默认采用自适应自旋（adaptive spinning），根据前一次在该锁上的自旋成功率动态调整。但一旦某次自旋全部失败，或达到阈值（如默认 10 次，可通过
-XX:PreBlockSpin调整），就会放弃自旋 - 存在多线程同时争抢：当多个线程在同一时刻发起 CAS 竞争（而非交替），轻量级锁无法维持低开销特性，JVM 会直接膨胀为重量级锁，此时所有未获锁线程被挂起，进入操作系统等待队列
典型高并发下的失效表现
在真实高并发压测中（如 500+ 线程争抢同一把锁），轻量级锁往往在极短时间内退化：
- 自旋消耗大量 CPU（尤其在多核机器上，多个线程空转抢同一个缓存行）
- Mark Word 频繁被修改，引发 false sharing，拖慢整体内存访问效率
- 一旦发生锁膨胀，所有排队线程从自旋态集体转入阻塞态，出现明显的吞吐量断崖式下跌和响应延迟尖峰
- 此时 jstack 可见大量线程处于
BLOCKED状态，而非RUNNABLE（自旋中）
如何判断是否已越过拐点？
可通过 JVM 运行时指标辅助识别：
- 启用
-XX:+PrintGCDetails -XX:+PrintSafepointStatistics观察 safepoint 停顿是否突增（重量级锁涉及全局安全点） - 使用
jstat -compiler <pid></pid>查看是否频繁触发锁膨胀（虽不直接显示，但配合jstack可佐证） - 开启
-XX:+UnlockDiagnosticVMOptions -XX:+PrintBiasedLockingStatistics（需配合 JDK 版本）查看偏向锁撤销与轻量级锁膨胀次数 - 生产环境推荐用 async-profiler 抓取锁热点，观察
monitorenter调用是否集中在重量级锁路径
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
