“旧类残留假死”实为新旧类共存致静态变量指向错乱；因不同classloader加载的同名类其静态域隔离，老类静态变量未释放而新类已初始化，需通过日志、jcmd、jmap及mat定位残留引用与未卸载类。
热部署中“旧类残留假死”，往往不是类真卡住了，而是新旧类共存、静态变量指向错乱，导致逻辑看似运行却返回 null、默认值或旧状态。核心矛盾在于：静态变量属于 Class 对象，而不同 ClassLoader 加载的同名类，其静态域完全隔离——你改了代码、触发重加载，但老类的静态变量还在内存里，新类的静态变量刚初始化，两者互不感知。
确认是否真有多个 Class 实例在运行
这是第一步，也是最关键的判断依据：
- 在关键类中加一行日志：System.err.println("MyService.class = " + MyService.class + ", CL = " + MyService.class.getClassLoader());
- 对比热部署前后输出：若
MyService.class的哈希值变了，或ClassLoader实例变了（比如从RestartClassLoader变成新实例），说明已加载新类；但若业务逻辑仍读到旧值，大概率是某处还拿着老类的引用 - 用
jcmd <pid> VM.class_hierarchy | grep MyService</pid>查看当前 JVM 中是否存在多个MyService类（不同 ClassLoader 加载的会并列显示）
检查静态变量被谁“跨类加载器”误引用
常见陷阱不是你自己写了static MyService instance，而是框架或工具悄悄缓存了老类：
-
Spring 上下文未清理干净：DevTools 热部署后，某些 BeanPostProcessor 或 ApplicationRunner 可能仍持有老类的 Bean 实例，尤其当它被注入到单例中且未标记
@RefreshScope -
日志/序列化工具缓存 Class：Logback 的
LoggerContext、Kryo 的Registration表、Jackson 的SimpleModule都可能缓存老类的Class对象，导致后续反序列化仍走旧逻辑 -
反射元数据残留：如
MyService.class.getDeclaredMethod("doX")结果被静态 Map 缓存，而该 Method 关联着老类的Class，间接锁住整个类加载器
验证静态字段是否被显式赋 null 或覆盖失败
所谓“未释放”，很多时候是代码逻辑把值设成了null，或新初始化没成功：
- 检查所有
static { ... }块：是否有异常抛出？一旦某个静态块执行失败（如配置未就绪、DB 连接超时），JVM 会标记该类为“初始化失败”，后续访问直接报NoClassDefFoundError，而不是你看到的“假死” - 确认静态字段赋值顺序：若
static final String URL = Config.get("url");在static Config config = new Config();之前，而Config构造器又依赖URL，就会形成静默循环依赖，字段保持默认值 - 搜索项目中所有对目标静态字段的赋值语句，确认热部署后是否被重复执行、条件未满足跳过、或被 AOP 拦截失效
用工具定位残留引用链
别靠猜，让 JVM 和工具说话：
- 启动参数加
-XX:+TraceClassLoading -XX:+TraceClassUnloading，观察日志中是否出现[Unloading class com.example.MyService]——没有这行，说明老类加载器根本没回收，静态变量自然还在 - 执行
jmap -clstats <pid></pid>，找java.net.URLClassLoader或org.springframework.boot.devtools.restart.classloader.RestartClassLoader实例数是否持续增长，每个实例加载的类数是否异常高 - 导出 heap dump 后，用 MAT 打开 →Dominator Tree→ 搜索
MyService→ 右键任一实例 →Path to GC Roots（排除 weak/soft）→ 若路径终点是java.lang.Class → static field，再点进去看这个Class对象的classLoader是谁
