Java ClassValue 怎么缓存类级元数据：类型值计算、remove 与类卸载边界

做反射扫描、注解解析或序列化适配时，元数据通常只和某一个 Class 有关。把它们塞进全局 Map, Value> 看似直接，却很容易忘记清理类加载器。Java 的 ClassValue 提供了更贴合这个关系的缓存入口：第一次读取时计算，后续按类复用，必要时还能让某个类的值失效。

如果缓存值的生命周期应该跟着某个 Class 走，优先考虑 ClassValue；如果需要跨类查询、按业务键淘汰或统一统计，普通缓存通常更合适。

先把缓存对象和 Class 的关系说清楚

典型场景是给 DTO 建立字段访问器。扫描注解需要遍历字段，第一次调用成本不低；但同一个 DTO 的字段结构不会因为一次请求而改变。此时缓存键天然是 Class>，缓存值则可以是不可变的 AccessorPlan。

普通 HashMap 还要额外处理并发初始化、类加载器隔离和清理时机。ClassValue 把“按 Class 取值”的主路径收拢起来，调用方只需要定义 computeValue。

static final ClassValue TYPE_NAME = new ClassValue() {
    @Override
    protected String computeValue(Class> type) {
        return type.getName();
    }
};

这段代码里的节点关系很简单：调用方通过 ClassValue.get 取值，缺失时进入 computeValue，结果回到该 Class 对应的缓存槽位。

ClassValue.get 与 computeValue 的最小用法

把示例改成一个能观察计算次数的版本，更容易确认缓存是否真的生效：

final class AccessorPlan {
    final String typeName;
    AccessorPlan(String typeName) {
        this.typeName = typeName;
    }
}

static final ClassValue PLAN = new ClassValue() {
    @Override
    protected AccessorPlan computeValue(Class> type) {
        System.out.println("compute: " + type.getName());
        return new AccessorPlan(type.getName());
    }
};

AccessorPlan first = PLAN.get(String.class);
AccessorPlan second = PLAN.get(String.class);

正常情况下，控制台只会为 String.class 打出一次 compute。这里的“一次”是针对某个 ClassValue 实例与某个 Class 的缓存关系，不应理解成进程生命周期内永远只计算一次；后面调用 remove 后，它还会再次计算。

remove 适合处理什么变化

如果元数据依赖了可热更新的外部规则，例如注解解析策略由配置文件决定，规则变更后可以让指定类型失效：

PLAN.remove(String.class);
AccessorPlan refreshed = PLAN.get(String.class);

remove 不会主动修改已经拿到的 first 对象，也不会让所有 Class 的值一起失效。它只影响指定的 String.class 关联项；下一次 ClassValue.get 才会重新走 computeValue。

错误处理和并发边界别混在缓存语义里

computeValue 抛出异常时，当前计算不会变成一个可复用的成功缓存值。调用方需要决定：解析失败是应该让调用直接失败，还是返回一个明确的“不支持”对象。不要把请求级异常、用户身份或临时数据库结果写进 ClassValue，否则缓存键的粒度就错了。

并发场景下也不要把 computeValue 当成一次性初始化锁来使用。代码应当能接受同一个类型的计算存在竞争，并保证返回对象本身安全；如果初始化必须产生唯一副作用，应把副作用移出计算函数，或使用独立的协调机制。

和 Map 缓存相比，什么时候不要选 ClassValue

• 需要按租户、版本或业务参数区分同一个 Class 时，ClassValue 的键粒度不够。
• 需要按容量、时间或权重淘汰时，专业缓存更容易表达策略。
• 需要列出所有缓存项做监控时，ClassValue 不是一个适合遍历的容器。
• 如果值本身反向持有自定义 ClassLoader 或其加载类，仍要检查引用链，不能把类卸载问题简单归因给缓存 API。

换句话说，ClassValue 解决的是“值跟着 Class 走”的生命周期关系，不是通用缓存的替代品。它适合元数据，不适合把所有业务对象都挂到类型上。

相关问题

ClassValue.get 会每次都执行 computeValue 吗？

不会。对同一个 ClassValue 和同一个 Class，值存在时直接返回；值被 remove 或尚未建立时才需要重新计算。

remove 后旧对象会立刻失效吗？

不会。remove 影响后续读取，已经保存到局部变量中的旧对象仍由普通 Java 引用规则管理。

ClassValue 能保证类一定被卸载吗？

不能。类卸载还要看对应 ClassLoader 是否可达，以及运行时是否满足卸载条件。

落地前的核对清单

1. 确认缓存值确实只由 Class 决定，并且不包含请求级数据。
2. 让 computeValue 只做可重复的元数据构建，失败时返回明确异常。
3. 规则变化时只 remove 受影响的 Class，避免无谓地重建全部类型。
4. 用自定义 ClassLoader 做一次加载、读取、释放引用的测试，观察实际卸载，而不是只看缓存代码。