synchronized锁升级不可逆是HotSpot主动设计选择，因重量级锁状态绑定深、内核态等待难唤醒、竞争判断不可靠、轻量级锁失败已违背偏向前提、批量撤销后禁用偏向、源码无deflate逻辑。
Java 中 synchronized 锁升级不可逆，不是 JVM 实现不完整，而是 HotSpot 明确的设计选择——它权衡了安全性、性能开销与实现复杂度后，主动放弃降级能力。
重量级锁无法回退，核心在于状态绑定太深
一旦升级为重量级锁，对象头 Mark Word 就存入指向 C++ 层 ObjectMonitor 的指针，而 Monitor 是操作系统互斥量（mutex）支撑的重量级结构：
- 线程可能已被挂起在内核态等待队列中，唤醒并重新参与用户态自旋，会引发大量上下文切换
- Monitor 内部包含 Owner、EntryList、WaitSet 等字段，清空或复用需同步多个竞争线程的状态，极易破坏锁语义
- JVM 无法可靠判断“当前真无竞争”：一个线程刚释放锁，另一个可能已在内核排队，表面空闲实则隐含高竞争
轻量级锁失败也不回退偏向，因为前提已失效
轻量级锁自旋失败，说明至少两个活跃线程在争抢。这直接违背了偏向锁“单线程长期持有”的设计前提。此时再尝试写入线程 ID 做偏向，CAS 很可能再次失败，纯属浪费 CPU。
偏向锁撤销后不自动重偏，是因竞争已发生
虽然撤销操作会把对象头恢复为无锁格式（锁标志位 01），但 HotSpot 不会立刻重试偏向：
- 撤销必须在全局安全点（SafePoint）执行，已触发一次 Stop-The-World
- 若紧接着有线程加锁，大概率直接走轻量级锁路径，重偏成功率极低
- 对某类对象批量撤销后，JVM 会禁用该类后续所有对象的偏向锁，跳过偏向阶段
源码层面没有降级逻辑
HotSpot 源码中 ObjectSynchronizer::inflate() 只负责向上膨胀，不存在对应的 deflate() 函数。这不是遗漏，而是刻意省略——降级带来的微弱收益，远低于其引入的竞态风险、内存屏障和分支判断开销。
