静态变量导致插件热泄露，因其强引用阻止类加载器回收；需排查静态集合、单例及反向引用，并在卸载时主动清理、改用弱引用、避免跨插件共享，最后验证类加载器可回收。
静态变量生命周期与 JVM 一致，从类加载起就存在，直到进程退出才释放。这一特性本为设计便利服务，但在插件化场景中极易演变为“热泄露”温床——插件卸载后，其类加载器本该被回收，但若插件代码中存在静态变量持有了插件自身类、实例、资源或上下文对象，就会形成强引用链，阻止类加载器（ClassLoader）被 GC 回收，进而导致整个插件的类、字节码、静态字段、甚至 native 资源持续滞留内存，即所谓“插件热泄露”。
识别静态变量引发的热泄露关键路径
插件热泄露的本质不是对象没释放，而是类加载器无法卸载。而静态变量正是最常见卡住类加载器的 GC Root 类型之一。重点排查以下三类静态引用：
-
静态集合缓存了插件内部对象：如
private static Map<String, PluginContext> contextCache = new HashMap<>();，其中 value 是插件专属 Context，它又隐式持有 Activity、Service 或插件 ClassLoader -
静态单例持有了插件类或资源：例如插件自定义的
public class PluginManager { private static PluginManager instance;，而该 instance 的成员字段引用了插件的Resources、AssetManager或某个Fragment -
工具类静态字段反向引用插件类：比如插件内定义了
public class PluginUtils { public static Class<?> CALLBACK_CLASS = PluginCallback.class; }，而PluginCallback是插件模块内的非 public 类——只要该类未被显式卸载，其所在的 ClassLoader 就无法被回收
用 MAT 快速定位“钉死”类加载器的静态字段
导出堆快照后，在 Eclipse MAT 中执行以下操作：
- 打开 Dominator Tree，按
java.lang.ClassLoader排序，找出疑似插件类加载器（如PluginClassLoader@0x...）的 Retained Heap 异常偏高 - 右键该 ClassLoader → Path to GC Roots → 勾选 exclude all weak/soft/phantom references
- 观察引用链终点：若路径最终落在
java.lang.Class → static field，且该 Class 属于插件包名（如com.example.plugin.*），则基本锁定问题源头 - 进一步点开该 static field 所在类，查看其声明位置——通常就是插件中某个
public static final或private static字段
修复时必须切断的三重引用
仅清空集合或置 null 不够，需确保插件卸载时彻底解除所有强引用绑定：
-
卸载钩子中主动清理静态状态：在插件
onDestroy()或uninstall()流程里，显式调用PluginUtils.clearCache()、PluginManager.destroyInstance()等，并将静态字段设为null -
避免静态字段直接引用插件类型：不要写
private static PluginConfig config;，改用弱持有或延迟加载；若必须缓存，value 使用WeakReference<PluginConfig>包裹 -
禁止跨插件共享静态容器：宿主中定义的
static Map<String, Object> globalRegistry若被插件 put 进自身对象，等同于把插件“焊死”在宿主生命周期里——应改用基于 ClassLoader 隔离的注册表，或通过接口+SPI 解耦
上线前验证是否真正解耦
修复后不能只看 OOM 是否消失，要验证类加载器是否可回收：
- 连续执行插件安装 → 启动 → 卸载 → 再安装，重复 5 次以上
- 每次卸载后，用
jcmd <pid> VM.native_memory summary观察Class区是否回落；或用jstat -class <pid>查看 loaded class count 是否未持续增长 - 抓取卸载后的堆快照，MAT 中搜索插件包名下的
java.lang.Class实例数，确认不再残留旧版本类
