synchronized锁升级本身不直接影响GC执行流程，但被锁对象会成为GC Roots，锁持有期间不可回收，释放后即退出GC Roots；锁状态变化不影响其GC Roots资格，真正决定对象存活的是锁持有时间而非锁级别。
synchronized 锁升级本身不直接影响 GC 的执行流程，但它通过改变对象头（Mark Word）中的锁状态位和参与 GC Roots 的资格，间接影响垃圾回收对对象存活性的判定。
锁对象自动成为 GC Roots
只要一个对象正被 synchronized 持有（即处于任意锁状态：偏向锁、轻量级锁或重量级锁），该对象就会被 JVM 视为 GC Roots 的一部分。这意味着：
- 即使代码中已无其他强引用指向它，只要锁未释放，GC 就不能回收它；
- 锁释放后（monitorexit 执行完毕），对象立即退出 GC Roots 集合；
- 下一次 GC 的可达性分析中，若该对象再无其他引用链可达，就会被正常标记为可回收。
不同锁状态对 GC 的实际影响差异不大
无论是偏向锁、轻量级锁还是重量级锁，只要锁尚未释放，对象就持续属于 GC Roots。锁升级过程（如偏向锁 → 轻量级锁）只改变 Mark Word 中的锁标志位，并不改变“是否在 GC Roots 中”这一事实。因此：
- 锁升级不会额外延长对象生命周期，也不会触发特殊 GC 行为；
- 真正影响 GC 的是锁的持有时间，而非锁的级别；
- 长时持有重量级锁（如同步块内执行耗时 IO）比短时偏向锁更容易导致对象滞留堆中。
大型锁对象可能间接干扰 GC 策略
当被用作锁的对象本身体积较大（例如大数组、Map 缓存容器），且长期被 synchronized 持有时，会产生连锁效应：
立即学习“Java免费学习笔记（深入）”；
- 该对象无法被及时回收，占用堆空间；
- 若它位于年轻代，可能因长期存活而提前晋升到老年代；
- 频繁晋升会加速老年代填充，增加 Full GC 触发概率；
- 这种影响与锁升级无关，但容易在高竞争场景（常触发重量级锁）中集中暴露。
与引用类型完全无关
synchronized 对 GC Roots 的贡献是 JVM 底层硬性机制，不依赖于对象的引用类型：
- 哪怕对象只被弱引用或虚引用持有，只要被 synchronized 锁住，就一定存活；
- finalize() 方法、ReferenceQueue 或 Cleaner 机制均无法绕过这一规则；
- 这是由 monitorenter / monitorexit 字节码指令直接控制的，属于 JVM 运行时保障。
