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