Java ClassValue 怎么避免类加载器泄漏

我在排查插件热加载后的堆增长时，最先怀疑的是缓存，却没有马上把所有缓存都改成弱引用。真正需要先确认的是：缓存是否把插件的 Class 当成了父加载器静态对象里的强键。对这种“按类型计算一次结果”的场景，ClassValue 通常是更贴合 JVM 生命周期的方案。它把值关联到具体的 Class，避免一个长期存活的全局 Map, Value> 反向托住插件类型；但线程、监听器和父加载器单例形成的引用链，仍然必须单独清理。

官方 API 文档：https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/ClassValue.html

先把泄漏路径画出来

假设应用本身由父加载器加载，插件由可反复创建的子加载器加载。下面这种缓存很容易留下路径：父加载器的静态字段持有 Map，Map 的键持有插件 Class，而 Class 又能找到定义它的插件加载器。即使插件已经停止使用，父加载器仍然活着，子加载器就没有机会被回收。

这时问题不在于缓存值算错，而在于键的生命周期比插件长。ClassValue 的设计目标正是让值跟随类型关联；JLS 规定，类只有在定义类加载器能够被垃圾回收时才可能卸载，所以代码仍要先切断其他外部强引用。

ClassValue 的迁移写法

把缓存声明在稳定的工具类中，用 get(type) 作为唯一读取入口，把创建逻辑放进 computeValue。API 会为首次访问的类型计算值，并以原子方式安装；并发访问时，调用方最终观察到同一个已安装结果。

public final class HandlerCache {
    // 工具类由稳定的父加载器加载，缓存按 Class 关联，而不是维护全局 Class 键表
    private static final ClassValue VALUES = new ClassValue() {
        @Override
        protected Handler computeValue(Class> type) {
            // 派生值只服务于当前类型，避免再复制到父加载器的静态注册表
            return HandlerFactory.createFor(type);
        }
    };

    public static Handler get(Class> type) {
        // get 负责懒加载；传入 null 会按 API 约定抛出 NullPointerException
        return VALUES.get(type);
    }

    public static void invalidate(Class> type) {
        // 业务规则变化时允许重新计算，不把 remove 当成卸载总开关
        VALUES.remove(type);
    }

    private HandlerCache() {
        // 禁止实例化工具类
    }
}

迁移时不要只做“把 ConcurrentHashMap 换成 ClassValue”这一行修改。重点是检查 HandlerFactory.createFor 返回的对象：如果它随后被放入父加载器的全局集合，或者注册了永不注销的回调，原来的生命周期问题只是换了一个入口。

ClassValue 不能替你清理的引用

我通常把泄漏排查分成两侧看。左侧是 ClassValue 自己管理的类型级关系；右侧是应用代码额外建立的长生命周期关系。后者包括线程池里的任务、线程的 contextClassLoader、ThreadLocal、事件总线监听器，以及父加载器静态单例持有的插件对象。

remove 何时有用，卸载又该怎么查

remove(type) 的语义是移除当前类型的关联值；下次读取会重新执行 computeValue。它适合配置变化、处理器重建或测试隔离，不等于“立刻卸载这个类加载器”。如果 type 仍然被业务对象使用，remove 只会让缓存失效一次。

上线前至少做一份停用清单：停止插件线程，移除事件监听器，清空插件侧 ThreadLocal，恢复线程上下文类加载器，释放父加载器注册表里的对象，再观察类卸载日志或堆分析中的引用路径。只有这些路径都断开，ClassValue 的生命周期优势才真正可见。

常见问题

ClassValue 会不会自动解决所有类加载器泄漏？

不会。它主要解决按 Class 做长期全局强键缓存的问题；线程、监听器、ThreadLocal、静态注册表和线程上下文类加载器仍需要显式收尾。

什么时候还应该使用普通 Map？

如果键并不是 Class，或者缓存需要跨多个类型共享且有明确的淘汰策略，普通 Map 仍然合适。此时要把清理时机和加载器边界写进生命周期设计，而不是期待弱引用或 ClassValue 自动兜底。