synchronized锁升级不可逆是明确工程取舍：一旦升为重量级锁，因绑定OS互斥量、降级开销大且语义风险高、短暂低竞争不意味长期无竞争，故不降级；应聚焦避免过早升级。
Java 中 synchronized 锁升级不可逆，不是设计疏漏，而是明确的工程取舍：一旦锁升到重量级，就不会退回轻量级或偏向锁。这不是“不能降”，而是“不该降、不值得降、技术上难安全地降”。
根本原因有三个
绑定操作系统互斥量，无法轻量还原：重量级锁会将对象与 OS 层的 mutex（互斥量）关联，线程可能被挂起、调度权交由内核管理，栈帧状态也不再可控。JVM 无法在运行时安全重建轻量级锁所需的栈上 Lock Record，更没法恢复偏向锁依赖的线程 ID 和 epoch 校验逻辑。
降级操作本身开销大且语义风险高：要降级，得唤醒阻塞队列中所有线程、重新校验重入计数、同步清理 Monitor 状态、重写 Mark Word……这些动作比维持重量级锁更耗资源，还容易破坏同步契约，比如让本该阻塞的线程误入临界区。
短暂低竞争 ≠ 长期无竞争：即使当前几毫秒没新线程争抢，也不能说明后续不会爆发竞争。强行降级后立刻又升级，等于白做两次重量级切换，徒增开销。
立即学习“Java免费学习笔记（深入）”；
真正该关注的不是“怎么降级”，而是“怎么避免升级”
多数性能问题来自不该升级却升级了。以下行为极易触发过早膨胀：
- 调用对象的 hashCode() 方法——偏向锁对象一旦计算过 hash，Mark Word 就被占用，再加锁直接跳过偏向，走轻量级流程
- 显式关闭偏向锁：-XX:-UseBiasedLocking，让所有新对象失去零开销优势
- 频繁 GC（尤其是 G1 并发标记阶段）触发批量撤销偏向锁，相当于主动放弃优化
可落地的应对策略
虽然运行时不能降级，但可以通过生命周期控制实现等效效果：
- 拆分锁粒度：把一个大锁按业务维度（如用户 ID 哈希取模）拆成多个小锁，降低单锁竞争概率
- 换用更适合的工具：读多写少用 StampedLock 或 ReadWriteLock；高频累加用 LongAdder；复杂状态用 AtomicReference + CAS
- 主动弃旧建新：对长周期高竞争锁对象（如全局缓存锁），设计定时重建机制（例如每小时 new Object()），让旧锁自然退出，新锁从偏向态重新开始
验证是否真升级了，别靠猜
用真实数据判断：
- 启动 JVM 加参数：-XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1，观察偏向锁批量撤销频率
- 运行中执行：jstack -l
，重量级锁会在输出中明确显示 “waiting on monitor entry” 及阻塞线程列表
