锁膨胀本身不是性能问题，而是jvm对线程竞争变化的自适应响应；其真正影响性能在于不同阶段放大系统瓶颈：偏向锁频繁撤销引发stw卡顿，轻量级锁自旋过多抬高cpu，重量级锁增多导致调度开销飙升，且膨胀不可逆加剧长期负担。
锁膨胀本身不是性能问题，而是 JVM 对线程竞争变化的自适应响应。它真正影响性能的地方，在于不同阶段放大了不同的系统瓶颈——关键不在于“是否膨胀”，而在于“在哪一阶段频繁触发”以及“是否匹配实际并发模式”。
偏向锁频繁撤销导致规律性卡顿
当大量对象在单线程场景下启用偏向锁，但很快被其他线程争抢时，JVM 必须执行偏向撤销：暂停所有相关线程、进入全局安全点（safepoint）、批量重置对象头。这个过程会引发短暂但可感知的 STW（Stop-The-World）停顿。
- 典型表现：应用出现周期性延迟毛刺（如每秒卡顿几毫秒），GC 日志中伴随 safepoint 等待时间突增
- 常见诱因：短生命周期对象被多个线程轮流访问（如 Web 请求中反复创建又传递的 DTO）、开启偏向锁但业务天然多线程
- 应对建议：高并发服务可考虑关闭偏向锁（-XX:-UseBiasedLocking），或通过 JOL 工具验证对象锁状态分布
轻量级锁自旋过多抬高 CPU 使用率
轻量级锁依赖 CAS 和有限次数的自旋（默认 10 次）来避免阻塞。但如果临界区执行时间偏长，或竞争线程数超过 CPU 核心数，自旋会白白消耗 CPU 资源，却无法及时获取锁。
- 典型表现：单核 CPU 占用率接近 100%，其余核心闲置；jstack 显示大量线程处于 RUNNABLE 状态但实际未进展
- 常见诱因：同步块内含 IO、远程调用、复杂计算等耗时操作；线程数远超可用核心数
- 应对建议：缩短同步范围（只锁必要代码段）、避免在 synchronized 内做阻塞操作；必要时可通过 -XX:PreBlockSpin 调整自旋阈值
重量级锁大量存在引发调度开销飙升
一旦升级为重量级锁，线程就会被挂起并交由操作系统调度。每次阻塞/唤醒都涉及用户态到内核态切换（数百纳秒至微秒级），且等待队列中的线程完全依赖 OS 调度策略，响应不可控。
- 典型表现：线程状态频繁在 RUNNABLE ↔ BLOCKED 间切换；监控中上下文切换（context switch）次数陡增；平均请求延迟明显跳升
- 常见诱因：锁粒度过粗（如整个方法加锁）、共享资源热点集中（如全局计数器、公共缓存）、锁持有时间过长
- 应对建议：改用分段锁（如 ConcurrentHashMap）、读写锁（ReentrantReadWriteLock）、或无锁结构（如 LongAdder）；对高频写场景优先考虑 CAS 类原子操作
锁膨胀不可逆带来的长期负担
重量级锁一旦升级，就不会再降级回轻量级或偏向锁。这意味着即使后续并发压力下降，该对象仍持续走重量级路径，维持较高的同步开销。
- 典型表现：系统负载回落之后，锁相关延迟未同步改善；jstack 中长期存在大量 BLOCKED 线程堆栈
- 常见诱因：对象复用频繁（如连接池、对象池中的实例）、锁对象生命周期长且经历过高竞争期
- 应对建议：避免长期持有同一把锁；对池化对象，可在归还时重置状态（如清空内部锁保护字段）；必要时主动使用 new 实例替代复用
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
