Java泛型深度解析：类型擦除、通配符与PECS规则

很多初学Java的人第一次接触泛型，是在看集合类源码或者写List<String>的时候。用起来挺爽，一旦想自己定义泛型类、泛型方法，或者看到方法签名里飘着? extends T、? super T这种怪东西，就一头雾水。我当年也是这么过来的：不知道泛型到底干了什么，只知道用了好像能少写强转。后来被几个运行时异常教育过，才回过头来系统补这块。

这篇文章我打算把Java SE泛型从头到尾讲透。不光是语法，更重要的是解释“为什么Java的泛型长这样”——为什么不能new T()，为什么要用通配符，为什么返回类型里会带?，以及它和C#泛型的本质区别在哪里。适合刚学完Java基础、准备进阶的读者，也适合那种“用泛型写过工具类但心里没底”的同学。

1. 没有泛型的世界：一次强制类型转换就能击穿你的防线

1.1 集合在Java 5之前的真实生活

Java 5之前的集合类，统统不关心你往里面放了什么。ArrayList内部就是一个Object[]，add方法接收Object，get方法返回Object。这意味着你取出元素之后，必须自己手动强转成想要的类型。强转本身不是问题，问题在于编译器根本不会帮你检查强转是否会成功。

看一个我早期项目里真实出现过的代码片段：

java复制List list = new ArrayList();
list.add("2023-12-01");
list.add(42);
String first = (String) list.get(0);   // 没问题，取出来确实是String
String second = (String) list.get(1);  // 运行期抛ClassCastException

这段代码编译期一片安静，没有任何警告。运行到第二行强转时，JVM发现Integer没法转成String，直接抛出ClassCastException。

这个异常的风险藏在整个调用链里：数据可能是从配置中心加载的，可能是从数据库查出来的，还可能是另一个同事在代码里随手放进来的。你只有在运行时才能发现放错了类型，而且报错的位置往往离出错的位置很远，排查成本很高。

1.2 泛型改变的不是语法，而是“错误出现的位置”

泛型引入后，同样的代码变成了这样：

java复制List<String> list = new ArrayList<>();
list.add("2023-12-01");
list.add(42); // 编译期直接报错：类型不匹配

add(42)在编译阶段就被拦截了。泛型把错误从运行期提前到了编译期，这是它最大的价值：不是帮你少写几句强转，而是让类型错误在项目交付之前就暴露出来。

我经常拿一个比喻解释这件事：没有泛型的集合就像一个没有安检的快递站，你往箱子里放什么都行，收件人打开箱子才知道里面是什么。泛型等于在箱子上贴了明确清单——里面的东西只允许是某个类型，往里乱塞东西的包裹压根进不了流程。

这也解释了为什么说泛型是“编译期特性”：类型检查发生在javac编译阶段，编译完之后，泛型信息基本被抹掉了。这个“抹掉”的动作，术语叫类型擦除，后面第3章我会详细说。

2. 泛型的基础设施：泛型类、泛型接口与泛型方法

2.1 泛型类的最简模型：一个Result包装器

工作中最常见的泛型类，不是那些花哨的框架类，而是类似“统一返回结果”的包装器。比如一个RPC接口的返回值，我们希望它既能包装字符串，又能包装一个订单对象，还能包装报错信息。用泛型写最自然：

java复制public class Result<T> {
    private int code;
    private String message;
    private T data;

    public Result(int code, String message, T data) {
        this.code = code;
        this.message = message;
        this.data = data;
    }

    public T getData() {
        return data;
    }
}

使用的时候，Result<String>和Result<Order>是两个不同的静态类型，编译器会对它们做严格区分。你调用getData()拿回来的对象，不需要强转，类型已经确定好了。

注意一个细节：泛型类在实例化时可以省略后面的泛型参数，写成new Result<>("ok")，这是Java 7引入的菱形语法。<>表示“这里由编译器根据上下文推断类型”，绝大多数情况下不需要手工指定，但有个前提——你前面的类型推断得出来。如果写成new Result<>()然后直接返回，编译器也能根据目标类型推断。

2.2 泛型接口与泛型方法：调用时才定型的类型

泛型接口最典型的例子就是Comparable<T>。实现了Comparable<T>的类，必须实现compareTo(T o)，而这个T就是类自身。比如String实现了Comparable<String>，所以字符串排序时可以直接比较。

接口和类的写法差不多，但泛型方法有个容易被忽略的点：泛型方法的类型参数放在修饰符之后、返回类型之前。比如：

java复制public static <T> T getOrDefault(T value, T defaultValue) {
    return value == null ? defaultValue : value;
}

调用时可以显式指定类型参数：

java复制String s = GenericsDemo.<String>getOrDefault(null, "默认值");

不过大多数情况下编译器会自动推断类型，所以显式指定的写法很少见。我自己一般在编写像Collections.sort这类工具方法时才会用泛型方法，让调用方传入的集合类型和比较器类型保持一致。

2.3 有界类型参数：给类型参数设一个“最低要求”

如果类型参数没有任何限制，那它在方法体里只能当成Object用，能调用的方法只有Object那套。很多时候这不是我们想要的。比如我想写一个求最大值的方法，它需要调用compareTo，这就得要求传入的类型实现了Comparable。

有界类型参数的语法是<T extends 类型>：

java复制public static <T extends Comparable<T>> T max(List<T> list) {
    T max = list.get(0);
    for (T item : list) {
        if (item.compareTo(max) > 0) {
            max = item;
        }
    }
    return max;
}

这里T extends Comparable<T>就是给泛型加了个“门槛”：必须实现了Comparable<T>才能用这个方法。在这个约束下，方法体里就可以直接调用compareTo，编译器知道T一定具备这个能力。

多个边界用&连接，比如<T extends Comparable<T> & Serializable>。注意一个坑：类边界只能有一个，接口边界可以多个，而且类边界必须写在最前面。写成<T extends Serializable & Comparable<T>>可以，写成<T extends Number & Serializable>也行，但<T extends Serializable & Number>就会编译报错，因为Serializable是接口，Number是类，类边界必须放在第一个。

3. 类型擦除机制：为什么Java的泛型在运行时会“消失”

3.1 编译后的字节码里到底剩下什么

Java泛型和C++模板或C#泛型有一个本质区别：Java的泛型信息只在编译期存在。javac在完成类型检查后，会把泛型参数替换成它的上界类型，如果没写边界，就替换成Object。这个过程叫类型擦除。

拿之前的Result<T>举例，编译后字节码里的getData()返回类型，实际是Object，而不是T。List<String>在字节码层面就是ArrayList，里面的元素类型是Object，你看到的类型安全实际上是编译器在add和get时插入的隐式强转保护。

想知道自己写的类擦除后长什么样，用javap -c反编译class文件就能看到。我建议你花两分钟做个实验：

bash复制javap -c Result.class

你会在字节码里看到Object类型的方法签名，以及checkcast指令。这个checkcast就是编译器帮你插入的类型检查，它替代了你在Java 5之前自己手写的强转。

3.2 类型擦除带来的边界限制与桥方法

擦除带来了一连串限制，这些限制是很多“为什么不能这样写”的根本原因：

• 不能new T()，因为运行期JVM不知道T是什么
• 不能new T[10]，数组的运行时类型检查无法确定元素类型
• 不能用instanceof检查泛型类型
• 不能在静态变量里引用T

这些限制不是设计者故意找茬，而是擦除机制的自然后果。

还有桥方法，这是擦除后为了保证多态而自动生成的。假设父类泛型类是这样：

java复制class Parent<T> {
    T getValue() { return null; }
}

class Child extends Parent<String> {
    @Override
    String getValue() { return "hello"; }
}

擦除后，Parent的getValue返回Object，子类需要同时存在两个方法：一个返回String的版本，一个返回Object的版本。后者用于覆盖父类方法，前者是业务逻辑，两者之间通过桥方法做委托。你用javap看Child.class就能看到编译器自动生成的Object getValue()方法。理解桥方法能帮你解释一些奇怪的报错，比如在调试时看到方法签名和源码不一致，别慌，这就是编译器生成的魔法。

4. 通配符与PECS规则：泛型里最绕也是最值钱的部分

4.1 协变与不变：为什么List不是List