静态变量本身不锁住类，类卸载需同时满足三条件：所有实例被回收、ClassLoader不可达、Class对象无强引用；静态集合缓存、未注销监听器等才是常见卸载障碍。
Java静态变量本身不会阻止类卸载，但它们引用的对象可能成为GC Roots，间接阻碍类卸载。真正决定类能否被回收的，是JVM对类加载器、实例对象和Class对象三者的联合判定。
静态变量为什么不是“锁住类”的铁链
静态变量属于方法区（元空间）中的类数据，它本身只是类的一个属性。即使某个静态变量非null，只要满足类卸载的三个条件，该类依然可以被卸载。关键在于：这个静态变量引用的对象是否构成GC Roots——如果它引用的是一个普通对象，而该对象又没被其他GC Roots可达，那它并不会“拖住”整个类。
- 静态变量只是方法区中的一条引用，不是GC Roots的“源头”，而是可能被GC Roots（如类本身）所持有
- 只有当静态变量引用的对象被其他活跃线程或栈帧间接持有时，才可能延长该对象生命周期，进而影响关联类的卸载时机
- 若静态变量被显式赋值为null，且无其他强引用，它所指向的对象可被回收，但这不自动触发类卸载
类卸载必须同时满足的三个硬性条件
一个类要被JVM卸载，三者缺一不可：
- 该类所有实例（包括子类实例）已在堆中全部被回收
- 加载该类的ClassLoader实例本身已被回收（即ClassLoader对象不可达）
- 代表该类的java.lang.Class对象没有被任何地方强引用（例如未被缓存、未被反射长期持有）
注意：哪怕静态变量还存在，只要ClassLoader已不可达、Class对象无引用、实例全清空，类仍可卸载——此时静态变量所在的类数据结构本身也会从元空间清除。
立即学习“Java免费学习笔记（深入）”；
常见阻碍类卸载的实际场景
静态变量常在无意中成为卸载障碍，主要出现在以下情况：
- 静态集合缓存实例：如public static Map<String, Object> cache = new HashMap<>(); 若未及时清理，会导致实例无法回收，连锁阻碍类卸载
- 静态监听器/回调未注销：Web应用中注册的静态事件监听器，若持有业务对象引用，会形成隐式强引用链
- ThreadLocal配合静态变量使用：静态ThreadLocal变量若未remove()，在线程复用场景下可能长期持有对象，间接延缓卸载
- ClassLoader被静态变量意外持有：比如自定义类加载器被某个static字段引用，导致其无法回收，进而阻断所有由它加载的类卸载
如何验证类是否成功卸载
可通过JVM参数配合日志观察：
- 添加启动参数：-XX:+TraceClassUnloading，运行时输出类卸载日志
- 结合-XX:+PrintGCDetails -verbose:gc，关注Full GC后元空间（Metaspace）使用量是否下降
- 使用jcmd或jmap工具检查运行时类加载情况：
jcmd <pid> VM.native_memory summary或jmap -clstats <pid> - 注意：默认情况下，Bootstrap ClassLoader和Extension ClassLoader加载的类永不卸载；只有自定义ClassLoader加载的类才可能被回收
