热部署中单例类无法被回收是因类加载器隔离失效与静态引用强持有共同导致；单例若持有业务对象、被跨模块静态引用或执行不可逆操作，便会阻塞热部署；应改为ClassLoader级唯一、切断外部静态依赖并配合工具干预。
热部署中单例类无法被回收，本质是类加载器隔离失效与静态引用强持有共同作用的结果。jvm 中单例对象通常以 static 字段形式长期驻留，而热部署依赖新类加载器加载更新后的类——若旧单例仍被其他静态变量、缓存、监听器或第三方框架（如 spring 容器早期注册的 bean）隐式引用，旧类就无法卸载，新类也就无法生效，最终表现为“修改了代码但没变化”或“重启后才生效”。
确认单例是否成为热部署瓶颈
不是所有单例都会阻塞热部署，关键看它是否：
- 持有业务对象（如 DAO、Service 实例、配置容器）的强引用；
- 被非当前模块的类（如工具类、日志上下文、全局事件总线）静态引用；
- 在类初始化阶段（static {} 块）执行了不可逆操作（如注册到 JVM Shutdown Hook、启动守护线程、绑定本地资源句柄）。
可通过 JRebel 的 jrebel-diag 或 IDEA 的 “HotSwap” 日志观察是否提示 Cannot reload class: com.example.MySingleton — referenced by static field 类似警告。
改造单例类，支持类加载器解耦
避免将单例实现为“JVM 级唯一”，转为“当前 ClassLoader 级唯一”：
- 去掉
private static final MySingleton INSTANCE这类硬编码单例，改用ThreadLocal<MySingleton>或基于当前类加载器的 Map 缓存（如ConcurrentHashMap<ClassLoader, MySingleton>）； - 把构造逻辑移到实例方法中，而非
static初始化块； - 若必须用静态字段，确保在热部署触发时主动清理，例如监听 Spring 的
ContextRefreshedEvent或 JRebel 的ReloadEvent，调用INSTANCE = null并清空其内部状态。
切断外部对单例的静态依赖
很多升级失败并非单例自身问题，而是它被别的地方“钉住”了：
- 检查是否有工具类（如
ConfigUtils.getSingleton()）直接返回该单例，改为每次通过 Spring ApplicationContext 获取（Spring 管理的 Bean 默认支持热替换）； - 排查日志框架（如 Logback 的
LoggerContext）、监控 SDK（如 SkyWalking Agent）、序列化工具（如 FastJSON 全局配置）是否在初始化时持有了你的单例引用； - 禁用或重写
readResolve()和writeReplace()方法——它们在反序列化时可能重建旧实例，干扰类加载边界。
配合热部署工具做运行时干预
以 JRebel 为例，可针对性处理：
- 在
rebel.xml中显式排除单例类所在包的自动监控（<exclude>com.example.singleton</exclude>），改由你控制其生命周期； - 使用
@InstanceProvider注解（JRebel 提供）标注单例工厂方法，让 JRebel 在重载时调用该方法重建实例； - 若使用 Spring Boot DevTools，确保单例类不在
spring.devtools.restart.exclude黑名单里，否则它根本不会被扫描重载。
不复杂但容易忽略。核心就一条：让单例“活在当前类加载器里”，而不是“钉在整个 JVM 里”。
