1. 没有泛型的日子那些年我们被迫强转的类型如果你用过 JDK 5 之前的老代码或者看过早期 Java 教材一定见过这种写法List list new ArrayList(); list.add(hello); list.add(123); list.add(new Date()); String s (String) list.get(0);这段代码在 JDK 5 以前是合法的。集合类内部都装的是Object你往里面塞什么类型都行取出来的时候自己记住当初放的是什么然后手动强转。听起来好像也还行但实际维护过这种代码的人都明白这里藏着大雷。最典型的翻车现场是这样一个团队维护的订单系统里有人往List里塞了ListString也有人塞了ListInteger等项目跑到第三个迭代某个get(0)强转成String的时候直接给你抛一个ClassCastException。生产环境日志打出来你还要通过堆栈倒推是哪个模块、哪一行、哪个集合出的问题。真相往往是——存的时候和取的时候代码的作者根本不是同一个人。泛型就是来解决这个问题的。所谓参数化类型本质上是把类型也变成可以传给类或者方法的一个参数。ListString的意思是这个集合约定的元素类型就是String你往里放别的东西编译期就报错根本走不到运行时。从入门的角度来说泛型带给你三样东西编译期类型检查——放错类型直接编译失败错误提前暴露。消除强转代码——String s list.get(0)不再需要手写(String)。更清晰的自文档化表达——MapString, ListInteger光看类型签名就知道里面存的是什么。这三件事会贯穿你整个 Java 开发生涯。小到写工具类、封装通用返回结果大到设计框架接口、写 ORM 映射泛型无处不在。这篇文章我按自己理解的顺序来讲先搞清楚泛型的底层机制再逐条过语法接着处理通配符这个难点最后把擦除带来的坑和面试高频题一起解决掉。耐心看完参数化类型这件事基本就通透了。2. 泛型的本质类型擦除如何塑造了Java的泛型很多人学泛型卡在第一步就是因为不理解擦除这两个字。我直接说结论Java 泛型是编译期机制它在运行时是不存在的。也就是说ArrayListString和ArrayListInteger在字节码层面是同一个类当你写new ArrayListString()时JVM 根本不知道String这回事。2.1 擦除到底擦掉了什么先看一段普通代码public class EraseDemo { public static void main(String[] args) { ListString list new ArrayList(); list.add(hello); String s list.get(0); System.out.println(s); } }编译之后相当于什么用javap -c反编译一下你会发现字节码里丝毫找不到String类型参数的身影它变成了这样List list new ArrayList(); list.add(hello); String s (String) list.get(0);注意这行(String) list.get(0)。这就是擦除的完整含义——编译器在编译阶段做了两件事把String这种类型参数替换成它的上界没有声明上界就是Object。在需要返回值的地方自动插入强制类型转换。所以你可以理解为泛型语法是编译器提供的一种安全检查包装编译完成后代码本质上还是 JDK 5 之前的强转代码。只不过编译器帮你确认了强转不会失败并且替你写好了那个(String)。那运行时真的就完全没留下任何信息吗也不完全是。类型参数虽然被擦掉了但有的地方会留下 Signature 属性包括类签名、方法签名、字段签名。这给反射拿泛型信息留了后门我在第 6 节会专门讲这一节先把擦除的核心机制记牢。2.2 设计取舍为什么Java不学C#保留运行时类型有对比才有鉴别。C# 的泛型是运行时保留的Listint和Liststring在 .NET 运行时是两个不同的类型泛型类型参数在 JIT 编译时被真实实例化。Java 选择了完全不同的路线——擦除。为什么不学 C#核心原因是向后兼容。Java 泛型是在 JDK 5 引入的那时候 JDK 1.4 的项目铺天盖地。如果 JVM 要原生支持泛型类型那么所有已有的集合类比如ArrayList、HashMap要做破坏性改动所有老项目的字节码全部得跟着调整。Sun 的工程师选择了最保守的方案编译器做校验校验完就擦掉JVM 层完全不动。这个决策有几个直接后果list instanceof ArrayListString这种写法不合法因为运行时没有ArrayListString这个类型。泛型类不能直接new T()因为你不知道 T 是什么。泛型类型不能用作异常类型catch (T e)编译不过。你看很多泛型限制的根因都是擦除而不是语法设计者拍脑袋定的规矩。搞懂了它后面第 5 节那些为什么不能这么做就有了解释。2.3 类型参数、参数化类型、原始类型要分清顺便把基础术语捋一遍很多人在讨论时会混这几个概念术语含义示例类型参数声明时用的占位符T里的 T参数化类型把类型参数传入后的具体类型ListString原始类型不传类型参数的裸类型List、ArrayList泛型类型声明了类型参数的类/接口/方法ArrayListE一个非常容易踩的坑是原始类型可以和参数化类型混用。比如ListString strings new ArrayList(); List rawList strings; // 竟然编译通过 rawList.add(123); // 也编译通过但运行时可能炸这种混用是 Java 为了兼容老代码保留的缝隙。你自己写代码别说这么写维护旧代码时看到这种写法也要警醒。我见过太多线上问题往源头一查都是某个老接口用了List调用方传了带泛型的ListString新同事往里塞了个别的类型运行时在某个角落强转炸掉。3. 泛型语法逐个击破类、接口、方法与多重边界擦除的原理清楚之后再看语法就不慌了。泛型可以出现在三个地方类、接口、方法此外还有一个边界的概念。3.1 泛型类最常见的写法与命名规范泛型类的定义很简单类名后面加Tpublic class BoxT { private T item; public void setItem(T item) { this.item item; } public T getItem() { return item; } }使用的时候BoxString stringBox new Box(); stringBox.setItem(hello); String value stringBox.getItem();这里的是 JDK 7 引入的菱形操作符让编译器根据左边变量声明推断右边的类型参数省得写两遍BoxString。这个推断机制叫目标类型推断本质是编译器根据上下文寻找最合适的类型参数。关于类型参数的命名虽然 JLS 没有强制但整个生态已经形成了约定俗成的规范TType任意类型EElement集合元素类型K/VMap 的键和值RReturn返回值类型U、S辅助类型参数多个类型参数用逗号隔开比如public class PairK, V。我自己写代码的时候习惯最多两个类型参数超过三个就感觉阅读成本飙升通常意味着类设计该拆了。3.2 泛型方法静态方法为什么必须自己声明类型参数泛型方法是在方法的返回值前面加一个独立的T。这里有个新手高频困惑静态方法为什么不能用类的类型参数public class MyClassT { // 编译报错Cannot make a static reference to the non-static type T public static T getStaticValue() { return null; } }原因很简单泛型类的类型参数是在创建实例时确定的。MyClassString和MyClassInteger虽然是同一个类但实例维度的 T 不同。静态方法是属于类的不依赖任何实例所以它根本不知道当前这个 T 是什么。解决办法就是让静态方法自己声明类型参数public class MyClassT { public static U U getStaticValue(U value) { return value; } }泛型方法的一个经典应用是类型安全的工具方法比如自己实现一个集合转数组public static T T[] toArray(ListT list, T[] a) { if (a.length list.size()) { a Arrays.copyOf(a, list.size()); } for (int i 0; i list.size(); i) { a[i] list.get(i); } return a; }调用的时候编译器通常能通过参数推断出 T 的类型不需要显式写出来。3.3 泛型接口与实现类的三种姿势接口声明泛型和类一模一样public interface RepositoryT { T findById(long id); void save(T entity); }实现类有三种选择实现时确定类型public class UserRepository implements RepositoryUser最常用。保持泛型public class BaseRepositoryT implements RepositoryT适合做模板模式。继续扩展类型参数public class ExtendRepositoryT, R implements RepositoryT增加自己的新参数。第三种主要用在框架设计里。比如一个带日志功能的仓储接口log(T entity)的时候你可能还要一个操作类型参数R。3.4 类型边界用extends而不是implements如果你希望限制类型参数只能是某个类或其子类用extends关键字public class NumberBoxT extends Number { private T value; public NumberBox(T value) { this.value value; } public double doubleValue() { return value.doubleValue(); // 这里可以放心调用 Number 的方法 } }注意这里用的是extends不管是限定类还是接口一律写extends。原因是泛型的边界设计沿用了子类型关系的语义extends表达的是T 是 Number 的子类型。多个边界用连接public class MultiBoundT extends Number ComparableT { // T 必须既是 Number 子类又实现了 ComparableT }顺序上有限制类边界只能有一个且必须写在最前面。如果写成T extends ComparableT Number编译直接报错。原因很直接Java 类单继承一个类型最多有一个父类但可以实现多个接口。把边界想成编译期给 T 的能力担保就通了。声明了T extends Number编译器就知道 T 一定有 Number 的方法在泛型类内部可以直接调用不用强转。4. 通配符? extends与? super背后的PECS法则通配符是泛型学习曲线里最陡的一个坎它和类型参数解决的问题完全不同。类型参数T用来定义类型变量通配符?用来使用泛型类型时表达不确定性。两者可以类比为变量声明与方法传参。ListT是声明一个带类型变量的集合类型List?是告诉编译器我不关心具体元素是什么类型。4.1 为什么需要通配符泛型的不变性先看一个会编译报错的例子ListString strings new ArrayList(); ListObject objects strings; // 编译报错直觉上好像没问题——String是Object的子类型那ListString是不是应该也能当成ListObject用答案是否定的。原因在于List是可写的容器。如果允许这种赋值那下面的代码就能通过编译ListString strings new ArrayList(); ListObject objects strings; objects.add(new Integer(123)); // 编译期拦不住字符串列表里混进了整数Java 泛型是不变的invariant。ListString和ListObject之间没有任何父子关系。一谈到父子关系就有一个常识性的问题编译器为什么不能让ListString当成ListObject读因为List是读写都有的容器允许读方向是安全的只读允许写方向就不行了。这就是协变和逆变问题的来源。通配符就是为了在保留类型安全的前提下允许某种程度的视作父类型。4.2 上界通配符? extends T只读的入口List? extends Number表示元素是 Number 某个子类型构成的 List。例如它能同时接收ListInteger、ListDoublepublic static double sum(List? extends Number list) { double total 0; for (Number n : list) { total n.doubleValue(); } return total; }但你不能往里加元素List? extends Number list ...; list.add(Integer.valueOf(1)); // 编译报错为什么不能加因为? extends Number的具体类型可能是Integer、Double、BigDecimal编译器只知道它是 Number 的一个未知子类无法确认你加进去的Integer一定和真实的元素类型匹配。如果实际是ListDouble你加一个Integer进去就破坏了类型安全。但读是安全的从List? extends Number里取出的每个元素至少可以当成Number用。这就是上界通配符适合读场景的原因。4.3 下界通配符? super T只写的入口List? super Integer表示元素是 Integer 的某个父类构成的 List。它能接收ListInteger、ListNumber、ListObjectpublic static void addIntegers(List? super Integer list) { list.add(Integer.valueOf(1)); }往里加Integer是安全的因为无论真实元素类型是Integer、Number还是Object都一定能容纳Integer。但读出来的东西就不确定了可能是Number、也许是Object编译器只能按Object处理。所以下界通配符适合写场景。4.4 无界通配符List? 到底有什么用List?是元素类型完全未知的 List。它和ListObject有本质区别ListObject明确只能装Object及其子类List?则什么类型的 List 都能接收但你不能往里面写任何东西除了 null读出来的也只能按Object处理。它的主要用途是只关心容器本身不关心元素类型。比如一个打印任意列表大小的方法public static void printSize(List? list) { System.out.println(list.size()); }如果直接写ListObject就没法接收ListString了。无界通配符在这里发挥的作用是我只要 size() 这种不依赖元素类型的操作。4.5 PECS法则速记这节内容容易混我给你一个可以背下来的口诀PECSProducer Extends, Consumer Super。当你读取泛型数据生产者角色时用? extends T。当你写入泛型数据消费者角色时用? super T。又读又写那就明确写出具体类型别用通配符。经典例子是Collections.copy的方法签名public static T void copy(List? super T dest, List? extends T src)src只要往外读所以是? extends Tdest要被写入所以是? super T。你按 PECS 法则去读这种签名一眼就能明白设计意图不用死记硬背。关于 PECS 还有一句补充它说的是什么时候可以用而不是什么时候必须用。能用具体类型的地方尽量用具体类型。通配符的本质是放弃部分类型信息来换取灵活性信息损失必然伴随能力受限滥用通配符代码会变得很难读懂。5. 擦除带来的那些坑从桥方法到异常与重载冲突泛型的大多数反直觉限制根源都是擦除。这一节我挑了实际项目中最常遇到的几类坑一个一个拆开讲。5.1 桥方法编译器偷偷生成的连接件先看代码public interface PrinterT { void print(T value); } public class StringPrinter implements PrinterString { Override public void print(String value) { System.out.println(value); } }这段代码能编译通过但你有没有想过一个问题接口PrinterT擦除后变成void print(Object value)而你实现的void print(String value)参数类型不一样这两个方法签名在字节码层面是不匹配的。按道理说Override应该报错才对但实际编译过了为什么因为编译器偷偷生成一个桥方法public void print(Object value) { this.print((String) value); }这个方法位于字节码里源码中看不到。它的职责就是让 JVM 在调用接口方法时能正确路由到你实现的print(String)版本同时完成强制类型转换。桥方法在学习阶段没多大意义但在两个场景会跳出水面反射StringPrinter.class.getDeclaredMethods()你会发现两个print方法一个参数是String一个是Object后者就是桥方法。AOP 切面拦截如果你用 Spring AOP 拦截这个方法不小心按参数类型为 String去匹配可能拦截不到因为实际调用经过的是桥方法。遇到这种情况不要慌认准它是编译器生成的即可。JDK 的反射 API 还提供了Method.isBridge()专门用来过滤桥方法。5.2 泛型里绝对不能做的四件事擦除机制直接决定了以下操作非法我把原理一并写上1. 不能new T()public class MyClassT { public T create() { return new T(); // 编译报错 } }运行时 T 不存在编译器没法确定要调用哪个构造函数。变通方案是传ClassTpublic class MyClassT { private ClassT clazz; public MyClass(ClassT clazz) { this.clazz clazz; } public T create() throws Exception { return clazz.getDeclaredConstructor().newInstance(); } }这种写法在反射工具类、ORM 映射里很常见。2. 不能创建泛型数组T[] arr new T[10]; // 编译报错数组在运行时知道自己存的元素类型而泛型类型在运行时被擦除两者存在根本冲突。变通方案是创建一个Object[]然后强转或者用ArrayListT替代。3. 不能 catch 泛型异常try { ... } catch (T e) { // 编译报错 }异常的类型是运行时匹配的擦除后的 T 无法确定具体异常类型。4. 不能声明static T字段public class MyClassT { public static T instance; // 编译报错 }理由和第 3 节静态方法一样T 是实例维度确定的静态字段属于类维度。另外还有一个容易忽略的泛型类不能instanceof带类型参数。if (obj instanceof ListString)编译不通过。正确做法是if (obj instanceof List?)因为你只需要确认它是 List类型参数运行时查不到。5.3 同签名的重载冲突擦除引发的两个方法一样考虑这段代码public class OverloadDemo { public void process(ListString list) {} public void process(ListInteger list) {} // 编译报错 }直觉上这是合法的重载参数类型不同嘛。但擦除之后两个方法的参数都变成List签名完全一样JVM 分不清哪个是哪个编译直接失败。解决方案是把两个方法改成不同名比如processStrings(ListString)和processIntegers(ListInteger)或者从根本上调整设计。5.4 泛型方法与可变参数的堆污染SafeVarargs这个注解很多新手没见过它和前面提到的坑性质不同我顺带提一下。当你写public T void foo(T... args)时编译器会创建一个T[]数组来接收可变参数但前面刚讲过不能创建泛型数组于是编译器实际创建的是Object[]再强转成T[]。这个强转在运行期可能把错误类型放进数组造成堆污染heap pollution。于是就有了SafeVarargs。它是在确认这个方法内部没有不安全的数组操作的前提下压制编译器的警告。如果方法内部会把数组元素存入集合或者做数组元素的类型强转就别加这个注解加了等于隐瞒风险。6. 反射穿透擦除运行时如何还原泛型真容前面说泛型运行时被擦除那为什么很多框架能拿到泛型信息比如 Jackson 反序列化时你传个TypeReferenceListUser进去它居然知道要反序列化成ListUser而不是ListLinkedHashMap。这就涉及Signature 属性了。6.1 泛型信息的载体Type接口体系Java 的java.lang.reflect.Type是所有泛型类型信息的父接口它有四个常见子类型类型含义ParameterizedType参数化类型比如ListStringTypeVariable类型变量比如TGenericArrayType泛型数组比如T[]WildcardType通配符比如? extends NumberClass普通类也是Type的实现关键在于类、方法、字段的元信息里都有两个 APIgetType()和getGenericType()。前者返回运行时的 Class已擦除后者返回包含泛型信息的Type对象。6.2 从方法参数和返回值里抠出泛型拿一个具体例子演示。假设有这样一个接口public interface UserService { ListString getNames(); }通过反射拿方法的返回值类型Method method UserService.class.getMethod(getNames); Type returnType method.getGenericReturnType(); System.out.println(returnType); // 输出java.util.Listjava.lang.String if (returnType instanceof ParameterizedType) { ParameterizedType pt (ParameterizedType) returnType; Type rawType pt.getRawType(); // java.util.List Type[] argTypes pt.getActualTypeArguments(); // [java.lang.String] }字段和参数也是同理。利用这套 API就能在运行时恢复泛型信息——只限于类签名、方法签名、字段签名里写过的具体泛型。注意类型变量的T本身是无法还原的能还原的是ListString这种写死了的参数化类型。至于T最终被实例化成什么只有实例字段的Class才能提供线索这也是框架要用ClassT传入的原因。6.3 实战中的典型用法TypeReference原理Gson 的TypeToken、fastjson 的TypeReference、Jackson 的TypeReference底层都是同一套思路。它们做的事情是让用户写一个匿名内部类把目标泛型信息保留在匿名类的父类签名里。以 fastjson 为例ListUser users JSON.parseObject(json, new TypeReferenceListUser() {});这里的技巧是匿名内部类new TypeReferenceListUser() {}继承了一个带泛型参数的父类。Java 的反射 API 有个特点通过getGenericSuperclass()可以得到父类的完整参数化类型。public class TypeReferenceT { protected Type type; protected TypeReference() { Type superClass getClass().getGenericSuperclass(); ParameterizedType pt (ParameterizedType) superClass; type pt.getActualTypeArguments()[0]; } }这段代码的精妙之处在于getClass()拿到的是匿名内部类的 Class它的父类是带泛型参数的TypeReferenceListUser所以getGenericSuperclass()返回的就是ParameterizedType取第一个实际类型参数ListUser搞定。这个模式值得学习。它不仅在 JSON 解析中通用在事件总线、消息框架、依赖注入工具里也会遇到核心就一句话通过继承关系在字节码的类签名里藏住泛型信息运行时再用反射取出来。6.4 什么时候才需要碰反射泛型必须承认90% 的 CRUD 业务代码终身都不需要直接写反射。需要这套技能的是框架开发者、通用工具库作者、ORM 封装者。举个例子写一个通用的Bean 转 Map工具你想在转换时自动把ListString类型的字段转成 JSON 字符串而不是把对象强塞进去这时候就必须读字段的getGenericType()判断是不是ParameterizedType再判断实际类型参数。我的建议是普通项目遇到泛型信息拿不到的问题时先检查是不是设计问题——绝大多数情况下你需要的是传ClassT而不是靠反射猜。反射是锤子别把任何钉子都当锤子的目标。7. 从面试与实战视角看泛型高频考点与避坑清单泛型不只是写代码要用面试中也是 Java 基础的高频区。热搜词里有Java八股文java面试题我就按面试的视角把高频考点梳理一遍再补充几条我在项目里沉淀下来的实战经验。7.1 面试官最爱问的六个泛型问题1. 什么是类型擦除答题要点Java 泛型是编译期机制编译器在编译阶段将类型参数替换为边界类型无边界就是 Object并在必要处插入强转。运行时泛型信息大部分消失。2. 为什么 ListString 不是 ListObject 的子类型答题要点泛型是不变的。若允许则可通过ListObject的引用向实际为ListString的集合写入其他类型破坏类型安全。3. 解释 ? extends T 和 ? super T 的区别PECS 怎么用。答题要点? extends T适用于读取场景? super T适用于写入场景。扩展说一个Collections.copy的例子更出彩。4. 泛型方法和泛型类的类型参数有什么区别答题要点泛型方法的类型参数在调用时确定由参数推导或显式指定泛型类的类型参数在实例化时确定。静态方法不能引用类级类型参数需要自己声明。5. 什么是桥方法答题要点编译器为了在类型擦除后保持多态在实现泛型接口/父类的子类中自动生成的桥接方法实现强转和路由。可用Method.isBridge()判断。6. 为什么不能 new T()答题要点运行时 T 不存在无法确定构造函数。替代方案是传入ClassT。我见过不少面试者前面概念背得滚瓜烂熟一写代码暴露问题——最常见的是把泛型方法和普通方法搞混另一个高发错是把List?当ListObject用往里加元素编译报错后一脸懵。7.2 我踩过的泛型设计坑这几个教训不是我拿文档看来的是项目里真实摔过的坑一无脑使用无界通配符早期我写工具方法时喜欢偷懒参数一律写List?。后来调用方要往里传元素发现写不进去只能回头改成ListT或者List? super T。现在我的原则是能写具体类型就写具体类型实在不确定再用通配符。通配符是用于跨类型受限操作的不是为了省打字。坑二把泛型当成类型安全的万能护盾泛型只能防住编译期可见的错误类型。如果你从一个不受控的源头拿到数据比如MapString, Object、JSON 反序列化结果然后硬塞给泛型集合编译器不会救你。典型的就是TypeReference没写对反序列化出来的是ListLinkedHashMap后续强转User直接 ClassCastException。泛型的保护边界是编译器不是运行时。坑三过度使用多重边界导致设计臃肿T extends ComparableT Serializable Cloneable这种写法偶尔能见。但表达能力越强约束越紧复用性越低。如果发现一个类型上要堆一堆边界先想想是不是接口设计该拆了而不是硬往一个泛型参数上堆。坑四和 Lambda 混用的时候把类型推断想当然ListString list new ArrayList(); list.stream().map(s - s.length()); // StreamInteger这个还好。真正坑的是 Java 8 之前的Collections.emptyList()结合目标类型推断的场景有时 IDE 会跟你玩推断不出来的戏码。遇到编译报错 cannot infer type arguments最直接的办法是显式写类型Collections.StringemptyList()。7.3 入门到精通的核心路线图最后给一条学习路线这是我带团队时给新人设计的顺序先会用——泛型类、泛型方法、接口实现三种姿势。再看字节码——用javap -c看擦除后的代码理解编译器替你做了什么。然后啃通配符——用 PECS 法则做题直到看到? extends/super能条件反射。接下来研究边界场景——桥方法、反射泛型、TypeReference这时你已经能读懂框架源码里那些看不懂的签名了。最后形成自己的设计原则哪些场景该用、哪些场景坚决不用。我在实际项目里对泛型的态度是它是一种表达类型约束关系的语言工具核心价值不是写出多花哨的签名而是让代码在编译期就表达出正确的类型契约。刚学的时候觉得它只是集合类型安全的补丁用久了才发现真正的高手都在用泛型来抽象通用的算法和设计模式——比如模板方法、策略模式配合泛型约束能写出用的时候天然安全、检错提前到 IDE 里的代码。理解了擦除你就不会在运行时纠结泛型去哪了学会了 PECS你在设计通用方法时就知道该把通配符放在哪一侧。剩下的就是在真实代码里反复打磨手感了。