synchronized锁升级是jvm默认启用的自适应优化机制：无锁→偏向锁（记录线程id，免cas）→轻量级锁（cas自旋）→重量级锁（挂起线程），单向不可逆，依赖mark word、安全点和自适应自旋。
是的，synchronized 锁升级本身就是 JVM 为自动优化性能而设计的核心机制。
它不是“额外配置后才生效”的功能，而是从 JDK 1.6 开始就默认启用、由 JVM 在运行时根据真实竞争情况动态决策的一套自适应策略。整个过程对开发者完全透明——你写一个 synchronized 块，JVM 就会按需决定用哪种锁状态，目标只有一个：在保证线程安全的前提下，尽可能少花 CPU 时间、少做系统调用、少触发上下文切换。
synchronized 锁升级如何实现自动性能优化
无锁 → 偏向锁：对象刚创建时谁都没抢，处于无锁状态；第一个线程进来加锁，JVM 立刻把它变成偏向锁，把线程 ID 写进对象头（Mark Word）。之后这个线程再进同一把锁，连 CAS 都不用，只比对 ID 就行——省掉原子操作，快得像没加锁。
偏向锁 → 轻量级锁：第二个线程来了，发现锁已被“偏爱”，就会触发撤销（需停顿所有线程到安全点），然后升级为轻量级锁。这时两个线程靠 CAS 争锁，失败就自旋重试——不进内核、不挂起线程，靠空转等对方快点释放，适合短临同步场景。
轻量级锁 → 重量级锁：如果自旋太多次（JDK 有自适应阈值，比如默认 10 次左右）还没抢到，或者多个线程同时自旋，JVM 就判定“竞争真激烈”，直接膨胀为重量级锁。此时未抢到的线程被操作系统挂起，进入阻塞队列——代价高，但避免了 CPU 白耗，整体更稳。
关键点在于：这三步升级是单向不可逆的。一旦升到重量级锁，就不会再降回去。因为降级要清理 Monitor、恢复 Mark Word、协调所有线程状态，开销反而更大；而且真实业务中，高竞争往往持续存在，没必要反复折腾。
自动优化依赖哪些底层支撑
对象头中的 Mark Word：4 字节或 8 字节内存区域，实时记录锁标志位（如
01=无锁/偏向锁，00=轻量级锁，10=重量级锁）和对应元数据（线程 ID、栈帧指针、Monitor 地址等）。JVM 安全点机制：偏向锁撤销必须在全局安全点执行，确保所有线程暂停，对象状态一致，避免并发修改导致错乱。
自适应自旋：轻量级锁阶段的自旋次数不是固定值，JVM 会根据前几次该锁的自旋成功率动态调整，热锁多旋、冷锁少旋，减少无效等待。
实际效果举例
- 单线程反复调用
synchronized方法 → 始终停留在偏向锁 → 几乎零同步开销； - 两线程交替执行短同步块 → 多数时间走轻量级锁 → 没有线程挂起，吞吐量高；
- 数十个线程抢同一个锁 → 快速升为重量级锁 → 避免 CPU 被自旋占满，系统负载更可控。
不复杂但容易忽略
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
