源码读得越多越觉得java.lang.Class是那种天天见、却极少有人读完的特殊存在。你每天都在用反射、写注解处理器、调getResourceAsStream但很少有人注意过getDeclaredMethods()第一次调用为什么会明显变慢注解为什么能继承泛型信息为什么和普通字段元数据分开存这些问题的答案其实全都写在Class.java那几行字段声明里——准确地说是写在reflectionData、annotationData、genericInfo、classValueMap这几张内部缓存表上。这篇文章是 Class 源代码解析系列的第七篇。前面几篇把Class的基础API、类加载入口、反射入口梳理得差不多了所以这一篇我想集中聊一个很容易被忽略、却贯穿整个Class内部实现的主题Class 对象本体持有的那些缓存状态。换句话说JVM 在背后到底帮你记住了哪些东西又是怎么记住的。理解了这一点很多反射为什么慢枚举反射为什么快泛型为什么会内存泄漏之类的疑惑都能串起来。1. 从类声明与私有构造器看 JVM 对 Class 对象的强控制先说一个很多读者容易忽略的事实Class是所有反射API的入口但它本身不保存类的真实元数据。真正的类结构、方法表、字段表、常量池都在 JVM 内部的InstanceKlass或Klass对象里Java 层的Class只是一扇窗外面的人通过这扇窗向 JVM 要信息JVM 再把 native 层的数据转译成 Java 对象返回给你。这句话怎么理解直接看Class.java的类声明和构造器就明白了。public final class ClassT implements java.io.Serializable, GenericDeclaration, Type, AnnotatedElement { ... private Class(ClassLoader loader, Class? arrayComponentType) { // 交给 native 层初始化 ... } }看到没有构造器是private的。这意味着你永远不可能在业务代码里new Class()出来一个类对象。所有Class实例只能由 JVM 自己创建要么是类加载阶段由ClassLoader::defineClass的 native 逻辑生成要么是 JVM 启动时从bootstrap class loader直接加载核心类库时生成要么是数组类、基本数据类型对应的Class由 JVM 内部初始化时创建。final修饰也同样关键。Class被声明为 final说明它不允许被继承不允许出现自定义的子类 Class。为什么因为反射是 JVM 最底层的信任边界如果Class可以被子类篡改那isAssignableFrom、cast、getMethod这些方法的语义就会被破坏整个类型系统的可信根基就不存在了。Java 里有一部分类虽然重要但还是开放了继承比如ClassLoader就是故意开放给你做自定义加载策略的而Class是绝对不许动的。还有那个泛型参数T也值得多说一句。ClassT的 T 表示这个类对象所代表的那个类型。比如String.class的类型是ClassStringInteger.class的类型是ClassInteger。这是设计上用来辅助编译器做类型判断的——你写ClassT的时候反射拿到的T可以安全地直接转换而不用强转。实际上 JVM 内部运行时不区分ClassString和ClassInteger它们都是同一个Class类泛型只是编译期给程序员看的约束。从实现角度看Class的很多关键方法都是 native 的。比如isAssignableFrom、isInstance、getModifiers、getName、getClassLoader0等这些方法在 Java 层只有声明真正的逻辑在 hotspot 源码里实现。Java 层保留了reflectionData、annotationData、genericInfo这类字段有一部分原因就是为了给反射调用做缓存避免每次调用都穿透到 native 层去重新解析类数据。这里想给所有读源码的读者一个经验读Class.java先别急着看那些 API 方法先把这个类从构造器到字段列表整体浏览一遍。因为你很快会发现除了static常量这个类的状态完全靠少数几个volatile transient字段和普通transient字段撑起来。那些字段就是整个 Class 对象内部状态的骨架。2. reflectionData被 SoftReference 包着的那张反射缓存表Class对象内部最重要的缓存无疑是reflectionData。它是Class为了支撑反射 API 而专门建的一张缓存表。先看字段定义以 OpenJDK 8 到 17 的通用结构为例不同小版本略有差异但主体一致private static class ReflectionDataT { volatile Field[] declaredFields; volatile Field[] publicFields; volatile Method[] declaredMethods; volatile Method[] publicMethods; volatile Constructor?[] declaredConstructors; volatile Constructor?[] publicConstructors; volatile int declaredPublicFieldsCount; volatile int declaredPublicMethodsCount; volatile int declaredPublicConstructorsCount; // 按接口索引记录 public methodsJDK 18 用于 record 组件相关能力 Method[] recordComponents; ... } private volatile transient SoftReferenceReflectionDataT reflectionData; private volatile transient int classRedefinedCount 0;为什么需要这张缓存表因为getDeclaredMethods()、getMethods()、getConstructors()这类方法每次调用都要面对类层级中可能存在的多个接口、多个父类、多个重载方法这种复杂结构。如果不缓存第一次调用时扫描完整继承结构后面每次调用都再扫描一遍反射性能会难看十倍不止。看一下getReflectionData()的核心逻辑伪代码简化private ReflectionDataT getReflectionData() { SoftReferenceReflectionDataT reflectionData this.reflectionData; int classRedefinedCount this.classRedefinedCount; ReflectionDataT rd; if (reflectionData ! null (rd reflectionData.get()) ! null rd.redefinedCount classRedefinedCount) { return rd; } return newReflectionData(reflectionData, classRedefinedCount); }有几个细节值得单独拆开讲。2.1 为什么偏偏用 SoftReference而不是强引用或 WeakReference这是一个非常经典的取舍。Class对象本身是有生命周期的——它随着类加载器卸载而结束。放在Class内部的反射缓存如果使用强引用只要Class活着缓存就永远占着内存不管这个类是不是已经被框架扫描完不再需要反射了。这会导致大量Field[]、Method[]长期驻留形成隐性内存压力。但用WeakReference又太激进。弱引用只要发生一次 GC 就会被回收而你每次 GC 之后再次反射都得重新构建整张表性能损失太大。SoftReference是个折中平时内存充足的时候它一直存活遇到内存紧张垃圾回收器才会考虑回收它而且在回收顺序上SoftReference 通常会在 OutOfMemoryError 之前才被清理。动态代理、Spring 容器这类框架启动时扫描大量类元信息用 SoftReference 可以保证绝大多数情况下缓存命中同时给 JVM 留了在内存告急时丢弃缓存换取存活空间的退路。这里有个工程上的启发如果你的业务代码里也有计算成本很高、但可以随时重建的缓存SoftReference往往比强引用更合适。但要注意它不适合那些重建成本同样极高的数据因为一旦被回收重建的代价可能让你吃更大的亏。2.2 volatile transient 组合的含义transient表示这个字段不参与 Java 序列化。Class对象确实有可能被序列化吗正常情况下你不会直接序列化Class但反射框架里偶尔会有Class[]被序列化传递的场景比如 RMI。如果不加 transient序列化框架会尝试把整棵类元数据树都打包那是灾难。加上 transient 后反序列化回来的Class对象会丢掉缓存状态代价只是下次反射时重新构建缓存。volatile则是为了保证多线程并发读写时线程不能拿到一个只构建了一半的ReflectionData。ReflectionData内部的字段大多是volatile Field[]、volatile Method[]这样的数组引用配合外层的 volatile 引用可以实现一种非常粗粒度的安全发布要么看到的整个对象是旧的但完整的要么是新的构建完成的不存在中间状态。2.3 这个缓存在实际反射中是怎么被命中的getDeclaredFields()的内部逻辑大致是public Field[] getDeclaredFields() throws SecurityException { SecurityManager sm System.getSecurityManager(); if (sm ! null) { checkMemberAccess(sm, Member.DECLARED, Reflection.getCallerClass()); } return copyFields(privateGetDeclaredFields(false)); }privateGetDeclaredFields就是查缓存的入口private Field[] privateGetDeclaredFields(boolean publicOnly) { ... ReflectionDataT rd getReflectionData(); Field[] res publicOnly ? rd.publicFields : rd.declaredFields; if (res ! null) return res; // 没有缓存时调用 native 方法 getDeclaredFields0 去 JVM 里拿 res Reflection.filterFields(this, getDeclaredFields0(publicOnly)); if (publicOnly) { rd.publicFields res; } else { rd.declaredFields res; } return res; }这也解释了大家常说的反射第一次调用慢。第一次调用getDeclaredFields()时reflectionData里没有对应的数组必须走 native 方法getDeclaredFields0把整个类的字段解析出来再经过Reflection.filterFields过滤掉隐藏字段然后填充缓存。之后再次调用就直接返回数组的拷贝速度快得多。注意方法名里的copyFields、copyMethods这类工具方法。JDK 源码里返回给调用者的数组基本都是拷贝出来的副本而不是缓存里的原数组。这个设计的理由是如果直接把缓存数组交给调用者调用者可以修改数组里的元素虽然元素是Field对象但数组本身可以被替换导致下次其他线程拿到的Field[]出现元素被篡改的情况。虽然Field对象本身是不可变的但防小人这一步做得还是很细的。2.4 类重定义之后缓存怎么处理classRedefinedCount这个字段可能很多人都没注意过。它配合Instrumentation.redefineClasses()工作。如果 JVM 在运行期重新定义了一个类之前的ReflectionData缓存就全部失效了因为方法表、字段表结构可能已经变化。getReflectionData()里会检查缓存记录的重定义计数是否和classRedefinedCount一致不一致就得重建。这个机制在普通业务代码里几乎用不到但 Java Agent、APM 工具、热更新框架会频繁触发。如果你开发过类似工具应该见过retransformClasses之后某些反射结果不对的坑根因往往就在这里不是 JDK 的 bug而是老缓存没有及时按重定义计数失效或者你在代码里强缓存了老的Method/Field对象而 JVM 认为重定义之后老对象已经不该再被调用了。3. annotationData注解快照为什么必须加锁构建反射缓存里第二块容易被忽视的区域是注解相关的缓存。很多人在业务代码里频繁调用getAnnotations()、getDeclaredAnnotations()却不知道这背后也有一张精巧的缓存表。字段定义和内部类大致是这样的private volatile transient AnnotationData annotationData; private static class AnnotationData { final MapClass? extends Annotation, Annotation declaredAnnotations; final MapClass? extends Annotation, Annotation annotations; final int redefinedCount; ... }declaredAnnotations存的是这个类上直接声明的注解annotations存的是包含继承语义的完整注解集合考虑Inherited标记的父类注解。两者是分离的因为getDeclaredAnnotations()和getAnnotations()语义不同内部缓存也必须分开否则查询过程就要做很多重复计算。看getAnnotationData()的获取逻辑简化private AnnotationData getAnnotationData() { ... AnnotationData annotationData this.annotationData; if (annotationData ! null annotationData.redefinedCount classRedefinedCount) { return annotationData; } // 没有缓存或类被重新定义过 synchronized (this) { // 双检锁 annotationData this.annotationData; if (annotationData null || annotationData.redefinedCount ! classRedefinedCount) { MapClass? extends Annotation, Annotation declaredAnnotations getDeclaredAnnotations0(); MapClass? extends Annotation, Annotation annotations declaredAnnotations; // 如果允许继承向上递归查找父类 if (searchSuperClasses) { Class? superClass getSuperclass(); ... } annotationData new AnnotationData(declaredAnnotations, annotations, classRedefinedCount); this.annotationData annotationData; } } return annotationData; }这里有几个非常值得学习的点。3.1 为什么必须用 synchronized而 reflectionData 却不需要ReflectionData里的每个字段都是独立填充的declaredFields缓存失败不影响declaredMethods的其他线程继续工作甚至同一个字段两个线程同时构建也只是重复计算一次最后后写入的覆盖先写入的不会产生数据不一致的严重问题。但AnnotationData是一个不可变快照。它同时包含了declaredAnnotations和annotations两个 Map这两个 Map 必须来自同一次扫描结果不能一个来自旧快照一个来自新快照否则就会出现父类注解找到了但子类注解没找到这种自相矛盾的结果。所以 JDK 用 synchronized 把整个构建过程锁住再用类上的双检锁把并发构建的浪费降到最低。这种设计在业务代码里也很常见当你要构建一份多字段之间必须逻辑一致的缓存对象时简单用 volatile 不够必须用锁保证构建过程的原子性如果缓存里的每个字段彼此独立、允许部分命中那分开缓存反而是更好的方案。3.2 Inherited 的查找链路是缓存的另一半价值注解继承是一个特别容易踩坑的点。Inherited注解只能作用于类上而且它表示子类可以继承父类中被 Inherited 标记的注解。它的查找逻辑就在getAnnotationData()里先取当前类直接声明的注解。如果searchSuperClasses为 true默认类场景为 true接口场景为 false就沿着getSuperclass()向上递归。每一层只取那些被Inherited标记的注解。把父类的继承注解合并到当前类的结果里。这个查找结果的缓存价值非常大因为一个深层继承结构比如A - B - C - D如果每次都从 D 一直扫到 A代价很高。缓存以后第二次查询 D 的注解直接从annotationData.annotations这个 Map 里取O(1) 复杂度。很多框架在处理类注解时会主动调用一次getAnnotations()来预热缓存让后续反射调用更快。Spring 的AnnotatedElementUtils、MyBatis 的注解扫描器都有类似的思路这也从侧面说明注解缓存对框架启动性能的重要性。3.3 你拿到的注解数组其实是一个拷贝细心看过源码的人会发现getDeclaredAnnotations()最终返回的是Annotation[]而这个数组来自annotationData.declaredAnnotations.values().toArray(...)是一个新创建的数组。Map 里的对象本身会被框架持有很久但返回给调用方的数组每次都是新的。这对开发者有一个实际影响不要试图通过修改返回的数组来影响注解解析结果那是徒劳的甚至可能让你在并发场景下得到诡异的行为。如果确实需要动态修改注解正确姿势是使用AtomicReferenceAnnotation[]自己维护而不是依赖反射缓存返回的结果。4. genericInfo泛型信息是现算现用的重量级数据第三个缓存相关字段是genericInfo。它和前面两个不一样前面两个缓存的是反射 API 常用的 Field/Method/Annotation 快照而这个缓存的是泛型类型信息。字段定义private transient volatile ClassRepository genericInfo;ClassRepository是 JDK 用来承载一个类整体泛型签名结构的对象里面包含superclass的泛型类型、接口的泛型类型列表、类型参数TypeVariable列表等。这些信息的解析不像普通元数据那样直接从 native 层拿二进制结构而是要经过一套完整的泛型签名解析器把字符串形式的泛型签名解析成Type对象图代价相当高。看getGenericInfo()的实现思路private ClassRepository getGenericInfo() { ClassRepository genericInfo this.genericInfo; if (genericInfo null) { String signature getGenericSignature0(); if (signature null) { genericInfo ClassRepository.NONE; } else { // 这里新建了一个解析器传入当前类对象和工厂 genericInfo ClassRepository.makeParser(signature, getGenericSignatureParser()); } this.genericInfo genericInfo; } return genericInfo; }注意到ClassRepository.NONE这个设计了吗当类没有泛型签名时缓存的不是 null而是一个空实现对象这样后续getGenericSuperclass()之类的调用不会再走一遍getGenericSignature0()的 native 查询也不至于为每个无泛型类都创建复杂的解析器。这个用空对象标记无数据的思路在业务代码里也适用——比每次都用 null 判断更优雅。4.1 泛型信息的内存成本到底高在哪一个ParameterizedType、一个TypeVariable、一个WildcardType每一个都是完整的 Java 对象内部又引用着其他的 Type 对象。一个复杂泛型类比如class FooT extends Comparable? super T Serializable, R解析出来可能就是一棵包含十几个节点甚至几十个节点的对象树。这也是 JDK 把泛型信息设计成懒加载的根本原因如果一个类代码里声明了复杂泛型但运行时没人碰泛型就完全没有必要去解析它。实际开发中有个典型问题如果你写了一个ConcurrentHashMapClass?, Type的缓存工具把getGenericSuperclass()的结果长期缓存下来那么当这个工具被用在大量动态生成的类上时内存占用会很惊人。因为每个 Type 对象树都不是轻量级对象这些树上的引用又会反向持有对应的Class形成一条链。轻则 GC 压力变大重则让 Metaspace 相关的类加载器无法卸载。更好的做法是用WeakHashMapClass?, Type或者在并发场景下用WeakReference作为ConcurrentHashMap的 key 包装再配合清理逻辑。不要只看到泛型 API 好用看不到它背后的构建成本。4.2 getTypeName 与 getName为什么感观上不一样很多人用过getTypeName()却说不清它和getName()的差异。源码里其实说得很明白public String getTypeName() { if (isArray()) { try { Class? cl this; int dimensions 0; while (cl.isArray()) { dimensions; cl cl.getComponentType(); } StringBuilder sb new StringBuilder(); sb.append(cl.getName()); for (int i 0; i dimensions; i) { sb.append([]); } return sb.toString(); } catch (Throwable e) { // fallback } } return getName(); }getName()返回的是 JVM 内部类的规范名称比如java.lang.String、[Ljava.lang.String;。而getTypeName()会友好地把多维数组转换成java.lang.String[]、java.lang.String[][]这种人类可读的形式。这个方法和泛型信息本身没有直接关系但它和getGenericInfo()在实现上有一个共同点都刻意避免去解析泛型签名只从类对象自身上推导。换句话说Java 设计者们很清楚哪些信息必须走重解析哪些信息可以轻量获取。5. classValueMap除了反射Class 还自带一个通用存储位前三个缓存是给 JDK 自己用的而接下来这个字段是留给框架和开发者的。字段定义private transient volatile ClassValueMap classValueMap;这里需要引入一个在业务代码里很少直接用、但影响深远的类ClassValueT。ClassValue是 JDK 7 就引入的机制。它允许你为任何一个Class关联一个动态计算的值。它的用法和ThreadLocal非常像只是维度不同ThreadLocal是每个线程一份独立值ClassValue是每个类一份独立值。而且这种关联是松散的——当类被回收时对应的值也随之被清理不会造成类都卸载了值还挂在某个 map 上这种经典泄漏。ClassValueMap就是ClassValue在Class内部使用的存储介质。源码层面ClassValueMap本质是一个优化过的LongMapkey 是ClassValue的身份 ID不是普通的HashMap。这个选择的原因很实际ClassValue的存取操作可能在很多线程上高频发生普通HashMap在并发下性能不够而LongMap基于基本类型 long 做 key避免了装箱访问更紧凑。static final class ClassValueMap extends LongMapObject { private final Class? type; ClassValueMap(Class? type) { this.type type; } ... }那到底怎么用呢官方推荐的写法是通过继承ClassValue并重写computeValueClassValueString CONSTANT new ClassValueString() { Override protected String computeValue(Class? type) { return type.getSimpleName() -computed; } }; // 使用时 String s CONSTANT.get(Foo.class);这里computeValue在第一次get时被调用之后结果被缓存在Foo.class对应的ClassValueMap里。调用方不需要自己管理任何 map也不需要处理并发因为ClassValue.get内部已经做了原子化的计算和缓存。很多 JVM 内部机制都利用了它。比如 Lambda 表达式生成的LambdaMetafactory相关缓存、动态代理的某些缓存、java.util.logging里的 log manager 关联等。与其自己写一堆ConcurrentHashMapClass?, T原生ClassValue在生命周期管理上更安全因为它的清理逻辑与 Class 的 GC 状态绑定。工程上它有个隐藏的好处当Class对象被类加载器卸载时ClassValueMap里的条目会跟着一起被回收不存在缓存里的 key 是一个已经被卸载的 Class导致类加载器无法 GC这种问题。这一点比很多自研缓存工具要稳健得多。如果你正在设计一个给任意类附加元信息的框架比如注解的二次加工、DTO 类型注册表、常见对象转换器映射完全可以考虑用ClassValue代替手写 map。唯一的限制是ClassValue的 value 是在首次 get 时一次性构建的不支持动态替换除非你把 value 设计成AtomicReference包一层所以它更适合一次计算、长期使用的场景。6. 枚举常量缓存与类型判断基础能力背后的本地方法边界前面几节都在讲缓存但Class有些能力是故意不缓存的或者缓存点藏在特别出人意料的地方。枚举常量就是其中一个。JDK 的Class里有一个enumConstantDirectory字段专门用于缓存枚举类名称与枚举常量的映射private volatile transient MapString, T enumConstantDirectory null;getEnumConstantsShared()的实现大致是T[] getEnumConstantsShared() { if (enumConstantDirectory null) { T[] constants getEnumConstants0(); if (constants ! null) { // 构建 name - 枚举对象 的目录 LinkedHashMapString, T map new LinkedHashMap(constants.length * 2); for (T c : constants) { map.put(((Enum?) c).name(), c); } enumConstantDirectory map; } } return ... }这个缓存的用途是什么主要是为了支持Enum.valueOf(ClassT, String)的高效查找。如果每次valueOf都去遍历枚举类的values()数组时间复杂度是 O(n)。但枚举类型通常常量数量很少n 一般是个位数理论上遍历也不差。JDK 还是特意建了一个Map缓存说明它对枚举查询这类模式定了调子宁可花小内存建表也不愿在热点路径上线性扫描。注意getEnumConstantsShared()和getEnumConstants()的区别。前者返回内部数组本身不拷贝后者是公开 API必须拷贝一份出来防止调用方直接改内部缓存数组。又是同一个套路内部共享外部防御。在这方面实际开发中有个值得记下的经验不要动不动就去反射枚举常量列表。如果确实需要Enum.valueOf是首选它的性能和缓存设计都经过了优化如果需要在枚举上做扩展属性映射用ClassValue比每次反射getEnumConstants要高效得多。类型判断相关的isInstance、isAssignableFrom、cast则是另一类逻辑它们全部是 native 方法实现public native boolean isInstance(Object obj); public native boolean isAssignableFrom(Class? cls); public native boolean isInterface(); public native boolean isArray(); public native boolean isPrimitive();这些方法没有做 Java 层缓存因为基础类型判断在 JVM 内部的成本已经很低了无非是几个标志位和指针的比对。isInstance最终会走到oop-is_instance()/klass-is_subclass_of()这类 C 代码走的是快速类型检查路径。反而是cast这个方法Java 层做了一点额外工作SuppressWarnings(unchecked) public T cast(Object obj) { if (obj ! null !isInstance(obj)) { throw new ClassCastException(cannotCastMsg(obj)); } return (T) obj; }它和直接(T) obj强转的区别在于cast是运行时检查抛出的异常信息更友好而且可以用于泛型代码中不能进行类型强转的场景比如Class.cast可以用来为任意类型做转换。很多人觉得cast只是语法糖其实在框架代码里它是一个很有用的工具比如BeanUtils里经常用type.cast(obj)来代替乱糟糟的强转链。7. 资源加载链路Class.getResourceAsStream 是怎么把活交给 ClassLoader 的最后一个想深入讲的部分是Class上的资源加载方法。它虽然不是缓存逻辑但在读Class.java源码时如果不理解类加载器的参与很容易搞混路径问题。看这两个方法public InputStream getResourceAsStream(String name) { name resolveName(name); ClassLoader cl getClassLoader0(); if (cl null) { return ClassLoader.getSystemResourceAsStream(name); } return cl.getResourceAsStream(name); } private String resolveName(String name) { if (name.startsWith(/)) { name name.substring(1); } else { Class? c this; while (c.isArray()) { c c.getComponentType(); } String baseName c.getName(); int index baseName.lastIndexOf(.); if (index ! -1) { name baseName.substring(0, index 1).replace(., /) name; } } return name; }这里有一个非常经典的坑点Class.getResourceAsStream(name)不以/开头时路径是相对于当前类所在包的而以/开头时才会从 classpath 根目录开始找。举个例子假设你的类在com.example.util.ClassA里// 会去找 com/example/util/config.properties ClassA.class.getResourceAsStream(config.properties); // 会去找 classpath 根目录下的 config.properties ClassA.class.getResourceAsStream(/config.properties); // ClassLoader 版本始终从 classpath 根目录开始找 ClassA.class.getClassLoader().getResourceAsStream(config.properties);这个差异每周都会坑到不少人尤其是在 maven 多模块项目里资源文件被打到了不同的 jar 包路径拼接一不小心就变成了NullPointerException。再看getClassLoader0() null时的处理。如果一个类由启动类加载器bootstrap class loader加载在 Java 层拿到的getClassLoader()是 null。此时getResourceAsStream不能直接调用 null 的getResourceAsStream所以 JDK 选择用ClassLoader.getSystemResourceAsStream(name)兜底。这同样适用于核心库如java.lang.String上的资源读取场景。还有个细节值得说为什么不直接调用线程上下文类加载器因为线程上下文类加载器是给框架实现 SPI 用的它和当前类所在加载器的定位不同。Class.getResourceAsStream的语义是和当前类同源的资源如果随便用线程上下文类加载器可能拿到其他应用模块里的同名资源产生非常隐蔽的问题。从源码实现角度getClassLoader0是 native 方法而getClassLoader()是包装方法public ClassLoader getClassLoader() { ClassLoader cl getClassLoader0(); if (cl null) return null; SecurityManager sm System.getSecurityManager(); if (sm ! null) { ClassLoader.checkClassLoaderPermission(cl, Reflection.getCallerClass()); } return cl; }有安全管理器时需要做权限检查没有时就直接返回 native 层给出的结果。这套逻辑在 JDK 17 及以后的高版本里因为有模块系统参与还增加了一些getModule相关的限制但核心委托链路没有变。读Class.java读到这里其实会发现一个很有趣的现象Class这个类本身的 Java 代码逻辑并不多绝大多数 API 都是把请求转交给 native 层、转交给ClassLoader、或者从几个缓存字段里取数据。它的精妙之处不在于某个具体算法有多复杂而在于把哪些数据放 Java 层缓存、哪些数据必须穿透 native、哪些数据委托给其他类划分得极其清楚。我自己在实际写反射相关工具时有个很实在的体会读源码不能光盯着方法实现一定要先看字段。Class里那几个带transient的字段基本上就是整个反射体系性能设计的核心纲要。顺着reflectionData、annotationData、genericInfo、enumConstantDirectory、classValueMap这条线读一遍你对反射为什么有快慢之分注解缓存什么时候会失效泛型信息的内存成本藏在哪这些问题的理解会比翻十篇性能优化文章都来得透彻。