java中synchronized锁膨胀不可逆，gc仅触发偏向锁批量撤销或类级别禁用，不导致存活对象锁状态降级；新对象分配时才重置为无锁或跳过偏向锁。
Java 中 synchronized 锁的“膨胀”是单向升级过程（无锁 → 偏向锁 → 轻量级锁 → 重量级锁），不可主动降级；但 JVM 在特定 GC 场景下会触发锁状态的批量重置或撤销，这种行为常被误称为“降级”，实为锁状态清理，而非运行时动态降级。
GC 期间可能触发偏向锁批量撤销的条件
偏向锁不会在每次线程退出同步块时自动释放，而是“持有时长无关、竞争才撤销”。但在某些 GC 阶段（尤其是 Full GC 或 CMS 的 concurrent mode failure 后的 STW 阶段），JVM 会检查并批量撤销大量已失效的偏向锁，前提是：
- JVM 启用了偏向锁（-XX:+UseBiasedLocking，默认 JDK 6–15 开启，JDK 15+ 默认关闭）
- 对象已进入老年代，且其 Mark Word 中仍标记为偏向锁状态，但持有线程 ID 已无效（如线程已终止、栈帧销毁）
- GC 过程中触发了安全点（Safepoint），且该次 GC 启用了偏向锁批量撤销逻辑（由 -XX:BiasedLockingBulkRevokeThreshold 控制，默认 40 次单个偏向锁撤销后触发批量撤销）
- 对象所属类被判定为“已批量撤销类”（即该类的实例频繁发生偏向锁撤销），后续新创建实例直接跳过偏向锁，初始化为无锁状态
GC 不会触发轻量级锁或重量级锁的“降级”
轻量级锁和重量级锁的状态存储在对象头 Mark Word 中，其结构与线程栈帧或 Monitor 对象强绑定：
- 轻量级锁依赖线程栈中的 Lock Record，GC 只回收不可达对象，不干预正在使用的锁记录
- 重量级锁关联操作系统 Mutex 和 Monitor 对象，一旦升级，Monitor 生命周期独立于 GC，释放由线程显式解锁或异常退出决定
- JVM 规范和 HotSpot 实现中，不存在 GC 触发轻量级锁回退为偏向锁，或重量级锁变回轻量级锁的机制
真正意义上的“锁状态重置”只发生在对象再分配时
所谓“降级”效果仅出现在新对象创建场景：
- 一个曾被升级为重量级锁的对象被 GC 回收后，其内存空间再次分配给新对象 → 新对象从无锁状态开始，可重新尝试获取偏向锁
- 若该类已被 JVM 标记为“禁用偏向”（如因批量撤销阈值超限），则新实例直接跳过偏向锁，首次加锁即走轻量级锁路径
- 这种重置是对象生命周期层面的清零，不是对存活对象的锁状态降级操作
锁膨胀不可逆，GC 不参与运行时锁级别调整。所谓“GC 时降级”，本质是偏向锁失效清理与类级别偏向禁用，仅影响未来新对象的行为，不影响当前存活对象的锁状态。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
