synchronized会间接延长锁对象存活时间，因其在持有期间被视作gc roots，即使无其他引用也不会被回收；锁释放后立即退出gc roots，若无可达引用则下次gc即可回收。
synchronized 本身不直接管理对象生命周期，但它会间接延长锁对象的存活时间，影响 GC 对该对象的回收时机。
锁对象在同步期间被视作 GC Root
只要一个对象正被用作 synchronized 的锁（无论通过同步块还是同步方法），JVM 就将其视为活跃的 GC Root。这意味着：
- 即使业务代码中已无其他强引用指向该对象，只要它还被锁着，GC 就不会标记它为可回收；
- 锁释放后（即退出同步块或方法），对象立刻失去 GC Root 身份，下一次 GC 标记阶段若无其他引用链可达，就会正常进入回收流程；
- 这种“保活”行为与引用类型无关——即使是弱引用或虚引用指向的对象，只要被锁住，照样不会被回收。
长耗时同步操作易导致对象意外驻留
若同步块内执行耗时操作（如 I/O、远程调用、复杂计算），锁对象会被持续持有，可能带来以下问题：
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 小型对象虽影响有限，但频繁创建又长期锁住，会增加 Minor GC 压力；
- 大型对象（如大数组、缓存 Map）被锁住时，可能因长期存活而提前晋升到老年代，加剧 Full GC 频率；
- 若锁对象是临时创建的（如
synchronized(new Object())），虽逻辑上用完即弃，但锁未释放前仍无法回收，造成短暂内存浪费。
锁对象选择不当会放大生命周期干扰
锁对象的粒度和复用方式直接影响其生命周期是否合理：
- 避免用业务实体对象（如
User user = new User()）直接作锁，否则其生命周期被同步逻辑绑架； - 优先使用专用锁对象（如
private final Object lock = new Object()），明确控制锁的生命周期边界； - 慎用
this或类对象（MyClass.class）作锁，尤其在对象生命周期较长或类被频繁加载/卸载时，容易引发意料外的驻留。
与 JVM 锁优化机制协同工作
现代 JVM（JDK 6+）对 synchronized 做了多层优化（偏向锁 → 轻量级锁 → 重量级锁），但无论处于哪种状态：
- 锁信息始终记录在对象头 Mark Word 中，GC 在标记阶段会扫描所有被标记为“已锁定”的对象；
- 一旦锁升级为重量级，对象头会存指向 Monitor 的指针，而 Monitor 本身也持有所属对象的强引用，进一步加固 GC Root 关系；
- 锁撤销（如偏向锁撤销）或锁释放后，Mark Word 恢复为无锁状态，对象立即退出 GC Root 集合。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
