Java类变量生命周期从类加载开始至JVM终止，不依赖对象存续，易致热泄露；需用jcmd、JFR、MAT等工具全程观测其加载、初始化及引用滞留。
Java类变量的生命周期从类加载开始，贯穿整个JVM运行期，直到进程终止才真正结束。它不依赖对象创建，也不随对象销毁而释放——只要类没被卸载，其静态变量就一直存在。这种“长驻”特性在常规开发中很便利，但在插件化、热更新或模块动态卸载场景下，极易引发内存滞留甚至热泄露。要准确追踪类变量生命周期，不能只看代码逻辑，得借助JVM原生可观测工具，从加载、初始化到潜在滞留全程抓取证据。
重点关注类加载与静态字段初始化时机
类变量（即static字段）的内存分配和初始值设定发生在“准备阶段”，此时JVM在方法区（JDK8+为元空间）登记类结构，并在堆中对应的java.lang.Class对象里为静态字段分配空间。注意两点：
- 普通static变量（如
public static int count = 1;）在准备阶段赋默认值（0），到初始化阶段才执行赋值语句设为1； - static final基本类型常量（如
public static final int VERSION = 3;）则在准备阶段直接写入真实值，不等初始化； - 引用类型static变量（如
private static List<string> cache = new ArrayList<>();</string>）的赋值语句也属于初始化阶段执行，但new出来的对象本身存于堆中，其生命周期独立于类变量声明。
用jcmd + jhsdb定位静态变量实际驻留位置
当怀疑某个类变量长期持有不该持有的引用时，可组合使用JDK自带工具快速验证：
- 先用
jcmd <pid> VM.native_memory summary粗略观察元空间增长趋势； - 再用
jcmd <pid> VM.class_hierarchy确认目标类是否已被加载，及其加载器类型（如PluginClassLoader）； - 启动
jhsdb clhsdb --pid <pid>，输入inspect <ClassObjectAddress>（可通过scanoops java.lang.Class查到）查看该Class实例的字段值及引用关系； - 对静态集合类，还可执行
printstaticfield <ClassName> <FieldName>直接输出字段当前值与底层对象地址。
通过JFR捕获类加载与静态初始化事件
Java Flight Recorder能记录细粒度的类生命周期事件，无需修改代码：
- 启动应用时添加参数：
-XX:+FlightRecorder -XX:StartFlightRecording=duration=120s,settings=profile,filename=class-lifecycle.jfr； - 在JDK Mission Control中打开录制文件，筛选事件类型为
jdk.ClassDefine（类定义）、jdk.ClassLoad（类加载完成）、jdk.Initialization（类初始化触发）； - 特别关注
jdk.Initialization事件的stack trace，可明确看到哪个线程、在什么上下文里触发了静态块或static字段赋值，有助于识别意外的初始化时机。
结合MAT分析静态引用导致的类加载器滞留
若已发生疑似热泄露，导出堆转储后在Eclipse MAT中：
- 打开Dominator Tree，按Retained Heap排序，找到异常大的ClassLoader实例；
- 右键→Path to GC Roots→排除弱/软引用，观察路径终点是否为某个类的static字段；
- 若路径终点是
com.yourplugin.XxxHelper.SOME_STATIC_MAP，且该Map value中包含Activity、Context或插件资源，则证实该静态字段阻止了ClassLoader回收； - 点击该static字段所在类，查看其源码位置，确认是否缺少卸载时的清理逻辑。
类变量生命周期不可控，但可观测。关键不是避免使用static，而是清楚它何时入场、何时持有哪些引用、又是否在该退出时被主动切断。工具链不是摆设，jcmd看加载、JFR看时机、MAT看引用链——三者配合，才能把“看不见”的生命周期变成可验证的事实。
