静态变量不会因类卸载而丢失，实际“丢失”多因多ClassLoader隔离、显式赋null、上下文刷新未重置或静态初始化异常导致。
静态变量不会“因类卸载而丢失”——在绝大多数生产 Java 环境中，类根本不会卸载，静态变量也就一直存在。所谓“丢失”，其实是误判：要么是访问路径出错（比如多 ClassLoader 场景下拿到了错误的 Class 实例），要么是静态变量被显式赋值为
或覆盖，要么是线程上下文切换导致读取了未初始化/未同步的值。
确认是否真发生了类卸载
类卸载是极小概率事件，必须满足三个硬性条件同时成立：
该类所有实例对象已全部被 GC 回收
加载该类的
ClassLoader 实例本身已被回收
（最关键）
对应的
对象没有任何强引用（包括反射、缓存、日志框架持有等）
标准 Spring Boot 应用使用 AppClassLoader 加载业务类，而 AppClassLoader 的生命周期与 JVM 一致，
永不回收
。因此你看到的“静态变量没了”，大概率不是类卸载所致，而是：
代码中执行了
多个模块通过不同 ClassLoader（如 GroovyClassLoader、OSGi BundleClassLoader）重复定义了同名类，造成“看似同一个类，实为不同 Class 对象”
Spring 上下文刷新（
）后，单例 Bean 重建，但静态变量未重置逻辑，导致状态不一致
用代码块顺序定位初始化异常点
静态变量初始化失败常源于静态代码块执行时抛异常，导致类初始化中断，后续访问直接报
（不是
）。排查重点是静态初始化链：
检查所有
块内是否有未捕获的异常（尤其是依赖外部资源：DB 连接、配置中心拉取、文件读取）
确认静态字段声明顺序：Java 按源码从上到下执行初始化，若
在
之前，则
初始化时
为默认值
在关键静态块中加日志（注意：SLF4J 静态 logger 初始化可能自身依赖类加载器，建议用
做兜底）
验证 ClassLoader 隔离问题
当使用动态脚本（Groovy/Janino）、热部署（Spring DevTools）、插件化（自定义 ClassLoader）时，极易出现“同名类不同 Class 对象”。验证方法：
打印静态变量所在类的 ClassLoader：
，对比预期与实际是否一致
检查是否意外触发了多次类加载：例如每次请求都 new 一个
并
，却未复用或清理
用
或
观察元空间增长趋势；若持续上涨且伴随 Full GC，高度疑似类泄漏而非卸载
生产环境最小干预验证方案
不重启、不改代码，快速验证静态状态是否真实丢失：
用 JMX 或 Actuator endpoint（如
）抓当前线程栈，搜索涉及该静态类的调用链，确认是否进入过初始化流程
通过 JVM attach 方式运行 jcmd：
，看类是否在已加载列表中
用
统计对象数量，观察该类实例是否存在；若实例数为 0 但静态字段仍应有效，说明问题不在 GC 而在访问逻辑
临时加一个 HTTP endpoint，返回
和
，比对不同请求的结果是否一致
nulljava.lang.ClassMyClass.staticField = null;ContextRefreshedEventNoClassDefFoundErrorClassNotFoundExceptionstatic { ... }static A = B + 1;static B = 5;AB0System.err.printlnMyClass.class.getClassLoader()GroovyClassLoader()parseClassjcmd VM.native_memory summary jstat -gcmetacapacity /actuator/threaddumpjcmd VM.class_hierarchy | grep YourStaticClass jmap -histo:live MyClass.class.hashCode()MyClass.class.getClassLoader().hashCode()