synchronized锁升级由jvm自动触发，无需手动干预；其遵循无锁→偏向锁→轻量级锁→重量级锁的单向不可逆路径，依据线程竞争程度动态选择最轻量策略，核心在于理解各阶段触发条件并避免破坏机制（如调用hashcode导致偏向锁退化）。
直接用 synchronized 就能触发锁升级，不需要手动干预——JVM 会根据实际竞争情况自动选择最轻量的锁策略。关键在于理解升级逻辑、避免干扰机制，让低竞争场景真正落到偏向锁或轻量级锁上。
让偏向锁生效：单线程主导的场景
偏向锁只在“一个线程反复获取同一把锁”时才起作用，且默认从 JDK 15 起已被禁用（JVM 参数 -XX:+UseBiasedLocking 不再生效）。若你用的是 JDK 8–14，可保留默认开启；若用更高版本，需确认是否显式启用（但通常不建议）。
- 确保锁对象生命周期稳定，比如用私有 final 字段而非临时创建的对象
- 避免在锁对象上调用
hashCode()——一旦调用，Mark Word 会写入哈希值，破坏偏向锁结构，直接退化为无锁状态 - 不要在多线程环境下“预热”偏向锁：首次加锁必须由目标线程执行，否则可能直接跳过偏向阶段
控制轻量级锁自旋：减少无谓 CPU 占用
当多个线程交替抢锁（非同时争抢），JVM 会升级为轻量级锁，采用自旋等待而非立即挂起线程。自旋成功则避免内核态切换，性能接近无锁。
- 同步块执行时间尽量短（毫秒级），否则自旋失败概率高，快速升级为重量级锁
- JDK 6+ 默认启用自适应自旋：JVM 会根据前一次在该锁上的自旋结果动态调整本次自旋次数，无需手动配置
- 若发现大量线程卡在自旋（如 CPU 飙高但吞吐未升），说明锁竞争已超出轻量级锁适用范围，应考虑锁拆分或读写分离
避开重量级锁陷阱：减少内核态切换
重量级锁意味着线程阻塞、OS 级互斥量介入、用户态/内核态切换——这是性能断崖点。升级至此不可逆，且后续所有操作都走重量级路径。
- 避免锁粒度过大：不要用
synchronized(this)包裹整个方法体，尤其含 I/O、网络调用或长循环 - 慎用全局锁对象（如
MyClass.class或静态常量），容易成为热点竞争源 - 注意锁对象复用：多个无关业务共用同一个锁对象，会人为制造竞争，哪怕各自逻辑完全独立
配合 JVM 参数做针对性优化
不是所有参数都要调，但了解它们能帮你诊断和验证锁行为：
-
-XX:+PrintCommandLineFlags查看当前是否启用偏向锁（JDK 15+ 基本无效） -
-XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly（需 hsdis）可反汇编观察锁指令，但生产环境不用 - 更实用的是
-XX:+TraceClassLoading+ JOL 工具：运行时打印对象头布局，确认 Mark Word 状态变化 - 高并发服务上线前，可用
-XX:+PrintGCDetails -XX:+PrintGCApplicationStoppedTime观察是否因安全点停顿（偏向锁撤销引发）导致 STW 延迟突增
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
