泛型信息不以运行时类型形式存储，而是作为字节码的一部分在类加载时解析为结构化元数据存入Metaspace；JVM运行时执行类型擦除，List<String>与List<Integer>共享同一Klass结构，但前者不占Signature空间，后者多存签名字符串和类型变量节点。
泛型信息在Metaspace中**不以运行时类型形式存储**，而是作为类字节码的一部分，在加载阶段被解析并转化为结构化元数据，存入Metaspace；但JVM在运行时会擦除泛型类型参数（Type Erasure），因此不会为List<String>和List<Integer>分别分配独立的类元数据空间。
泛型元数据实际存哪些内容
尽管泛型被擦除，其**声明层面的类型信息仍保留在Metaspace中**，主要用于编译期校验、反射和调试。具体包括：
-
泛型签名（Generic Signature）：每个泛型类、方法、字段都会在常量池中记录一个
SIGNATURE属性，例如Ljava/util/List<Ljava/lang/String;>;，该字符串本身存于Metaspace的常量池区 -
TypeVariable与Bounds信息：如
<T extends Comparable<T>>中的变量名T、上界类型Comparable<T>等，作为Method或Field元数据的一部分，写入Metaspace的方法描述结构或字段描述结构中 -
桥接方法（Bridge Methods）的元数据：编译器生成的桥接方法（如
Object get()）也会在Metaspace中完整存储其签名、字节码、异常表等——这是泛型擦除后维持多态语义的关键补充
类加载器对泛型元数据的管理方式
类加载器并不“识别”或“处理”泛型逻辑，它只是按字节码规范将.class文件中的泛型相关属性（如Signature、RuntimeVisibleTypeAnnotations）原样解析，并交由JVM在Metaspace中构造对应的数据结构。关键点在于：
- 泛型签名字符串和类型变量描述都绑定到具体的Class、Method或Field对象上，属于该类加载器所加载类的元数据子集
- 只要类加载器未被回收，哪怕该泛型类从未被反射访问过，其签名字符串和类型变量定义仍驻留Metaspace中
- 同一个类加载器重复加载同一泛型类（如通过自定义ClassLoader多次defineClass），会触发全新元数据分配，导致Metaspace占用翻倍——即使字节码完全相同
对Metaspace的实际影响
泛型本身不是Metaspace压力的主要来源，但不当使用会放大内存开销：
-
大量泛型嵌套声明（如
Map<List<Set<Optional<String>>>, Future<? extends Callable<? super Number>>>）会使Signature字符串显著变长，增加常量池负担 -
泛型+注解组合（尤其是
@Target(TYPE_USE)类型注解）会在Metaspace中额外存储TypeAnnotation结构，每处使用都新增几十到上百字节 - 动态生成泛型类（如Lombok @Data + @Builder、MyBatis Plus的泛型Mapper代理、CGLIB泛型增强）会频繁创建新类加载器或新类，导致Metaspace持续增长且难以卸载
真正决定Metaspace是否能释放的，始终是类加载器的可达性，而不是泛型用了多少层。擦除后的ArrayList和带完整签名的ArrayList<String>共享同一份Klass结构，但前者不占Signature空间，后者多存一个字符串引用和类型变量节点。
