1. 泛型上下边界到底在解决什么问题很多写了三五年Java的人看到List? extends Number和List? super Integer还是会愣一下。这两个东西在实际业务代码里出现的频率其实不低尤其是你去看JDK源码、框架源码或者自己封装一些通用工具类的时候绕不开它们。但大多数教程一上来就给你画继承树、讲型变规则看完更晕了。我先说结论泛型上下边界本质上是在“读取”和“写入”这两个动作之间做取舍。你不可能既要一个泛型容器能安全地读又要它能安全地写Java的类型系统不允许你这么贪心。extends偏向读super偏向写记住这一条后面所有的规则都是它的推论。1.1 从一个真实的翻车场景说起假设你在做一个数据统计模块需要写一个方法接收一组数字然后求和。你可能会这么写public static double sum(ListNumber list) { double total 0; for (Number n : list) { total n.doubleValue(); } return total; }看起来没问题对吧但当你尝试传入一个ListInteger的时候编译器直接报错ListInteger ints Arrays.asList(1, 2, 3); sum(ints); // 编译错误不兼容的类型为什么因为ListInteger并不是ListNumber的子类型。这是Java泛型的一个基本设计原则——泛型默认是不变的invariant。也就是说ListInteger和ListNumber之间没有任何继承关系哪怕Integer是Number的子类。这个设计不是Java故意为难你而是为了类型安全。想象一下如果ListInteger能赋值给ListNumber那会发生什么ListInteger ints new ArrayList(); ListNumber numbers ints; // 假设允许 numbers.add(3.14); // 往一个Integer列表里塞了个Double Integer i ints.get(0); // 炸了所以Java选择了不变性来保证安全。但这样一来像sum这种只读的方法就没法复用了。这时候extends就登场了。1.2 协变、逆变、不变——三个词说清楚在Java泛型的语境里这三个词描述的是类型参数在继承关系中的传递方向术语含义Java中的体现典型场景不变InvariantA是B的子类但ListA和ListB无关ListT默认行为既要读又要写的场景协变CovariantA是B的子类则ListA也是ListB的子类List? extends B只读场景逆变ContravariantA是B的子类则ListB是ListA的子类List? super A只写场景注意Java的泛型其实只支持使用点use-site的型变不支持声明点declaration-site的型变。什么意思就是你不能在定义类的时候说“我这个类对T是协变的”只能在用的时候通过通配符来指定。这是Java泛型设计上的一个历史包袱跟C#和Scala的做法不同但这不是我们今天要展开的话题。回到上面那个sum方法用extends改写public static double sum(List? extends Number list) { double total 0; for (Number n : list) { total n.doubleValue(); } return total; }现在ListInteger、ListDouble、ListLong都能传进来了。这就是协变带来的灵活性。1.3 为什么不能既extends又super有人可能会想那我写List? extends Number super Integer不就行了不行语法上就不允许。而且从逻辑上讲这也是矛盾的。extends Number意味着你把这个列表当作“Number的某个未知子类型的列表”你只能从中读取Number因为不管实际类型是什么它一定是Number的子类但你不能往里写因为你不知道实际类型到底是Integer还是Double。super Integer意味着你把这个列表当作“Integer的某个未知父类型的列表”你可以往里写Integer因为不管实际类型是什么它一定是Integer的父类能容纳Integer但你读出来的东西只能是Object。这两个语义是互斥的。一个容器要么偏向读要么偏向写不可能同时偏向两边。这就是著名的PECS原则Producer Extends, Consumer Super的由来后面我会详细展开。2. extends和super的读写规则拆解理解了“读”和“写”的取舍之后我们来看具体的规则。这部分是很多人容易记混的地方我尽量用最直白的方式讲清楚。2.1? extends T能读不能写先看一段代码List? extends Number list new ArrayListInteger(); Number n list.get(0); // 可以读读出来是Number list.add(1); // 编译错误不能写 list.add(null); // 唯一能写的值为什么不能写因为编译器不知道list的实际类型参数是什么。它可能是ListInteger也可能是ListDouble还可能是ListLong。如果你能往里写一个Integer那万一实际类型是ListDouble呢类型安全就被破坏了。所以编译器干脆一刀切只要用了extends除了null之外什么都不能往里加。null是所有引用类型的共同值所以它是唯一安全的。那读出来为什么是T因为不管实际类型是什么它一定是T的子类所以用T来接收是安全的。这就是协变的核心价值——保证读取的类型安全性。2.2? super T能写不能精确读再看superList? super Integer list new ArrayListNumber(); list.add(1); // 可以写Integer list.add(2); // 也可以写Integer的子类 Object obj list.get(0); // 只能读成Object Integer i list.get(0); // 编译错误为什么能写因为不管实际类型是ListNumber还是ListObject它们都能容纳Integer。所以往里写Integer是安全的。为什么读出来只能是Object因为编译器不知道实际类型是Integer的哪个父类。可能是Number可能是Object也可能是其他。为了安全起见只能退化成Object。这里有个细节值得注意list.add(1)之所以能编译通过是因为add方法的参数类型是? super Integer而Integer本身满足这个约束。但如果你尝试list.add(3.14)编译器会报错因为Double不是Integer的子类。2.3 PECS原则的完整推导PECS是Joshua Bloch在《Effective Java》里提出的全称是Producer Extends, Consumer Super。翻译过来就是如果这个容器是生产者你从里面读数据用extends如果它是消费者你往里面写数据用super。这个原则不是拍脑袋想出来的而是从上面的读写规则直接推导出来的你需要读数据 → 读出来的类型要尽量精确 → 用extends T读出来是T你需要写数据 → 写进去的类型要尽量宽泛 → 用super T能写T及其子类既读又写 → 老老实实用具体的类型参数别用通配符我见过很多代码明明只需要读却用了ListT导致方法签名不够通用也见过只需要写的地方用了extends结果发现add不进去。归根结底是没有想清楚这个容器在你的方法里扮演什么角色。2.4 一个容易踩的坑返回值类型看这个方法签名public static T ListT merge(List? extends T a, List? super T b) { // ... }这里a是生产者用extendsb是消费者用super。但如果你把返回值写成List? extends T调用方拿到之后就没法add了。所以返回值通常用具体的ListT把灵活性留给参数。这个模式在JDK的Collections.copy方法里有体现public static T void copy(List? super T dest, List? extends T src) { // ... }src是生产者用extendsdest是消费者用super。完美符合PECS。3. 通配符捕获与类型擦除的交互这部分稍微进阶一点但理解了之后你对泛型的很多疑惑会豁然开朗。3.1 通配符捕获是什么看这段代码public static void swap(List? list, int i, int j) { list.set(i, list.get(j)); // 编译错误 }list.get(j)返回的是?类型捕获变量list.set需要的是?类型按理说应该匹配。但编译器不认因为这两个?虽然看起来一样但编译器把它们当作不同的捕获变量。正确的写法是引入一个辅助方法public static void swap(List? list, int i, int j) { swapHelper(list, i, j); } private static T void swapHelper(ListT list, int i, int j) { T temp list.get(i); list.set(i, list.get(j)); list.set(j, temp); }这就是通配符捕获通过一个泛型方法把?捕获成具体的类型参数T然后就可以正常读写了。JDK里Collections.swap就是这么实现的。这个技巧在实际开发中很有用尤其是当你需要对一个List?做原地修改的时候。3.2 类型擦除带来的限制Java泛型是编译期的运行时会擦除。这意味着ListString a new ArrayList(); ListInteger b new ArrayList(); System.out.println(a.getClass() b.getClass()); // true两个不同类型的List运行时类是一样的。这带来几个实际限制不能new T()因为运行时不知道T是什么不能new T[]同样原因不能对泛型类型做instanceof判断list instanceof ListString编译错误静态方法不能使用类的类型参数这些限制在写通用工具类的时候经常遇到。比如你想写一个方法根据传入的Class对象创建实例public static T T create(ClassT clazz) throws Exception { return clazz.getDeclaredConstructor().newInstance(); }这里必须显式传入Class对象因为运行时拿不到T的信息。这就是所谓的类型令牌Type Token模式。3.3 桥接方法与协变返回类型类型擦除还会导致一个有趣的现象——桥接方法。看这个例子class Parent { Object get() { return null; } } class Child extends Parent { Override String get() { return hello; } }Child的get方法返回StringParent的返回Object。这是合法的协变返回类型。但擦除之后Child里实际上有两个get方法一个是返回String的一个是编译器自动生成的桥接方法返回Object内部调用返回String的那个。用javap -c反编译就能看到。这个知识点在理解泛型继承体系的时候很有用尤其是当你遇到一些奇怪的编译错误时。4. 实战中的典型应用与避坑指南理论讲完了来看几个实际开发中常见的场景以及我踩过的坑。4.1 通用集合工具方法的设计假设你要写一个方法把源列表的所有元素添加到目标列表public static T void addAll(List? super T dest, List? extends T src) { for (T item : src) { dest.add(item); } }这个签名非常灵活ListNumber numbers new ArrayList(); ListInteger ints Arrays.asList(1, 2, 3); addAll(numbers, ints); // 可以 ListObject objects new ArrayList(); addAll(objects, ints); // 也可以dest用super T能接受T的任意父类型的列表src用extends T能接受T的任意子类型的列表。这就是PECS的完美应用。4.2 比较器与排序Collections.sort的签名是public static T void sort(ListT list, Comparator? super T c)为什么Comparator用super T因为比较器是消费者——它消费T类型的对象来产生比较结果。如果你有一个ComparatorObject它当然能比较Integer因为Integer也是Object。所以用super T让比较器更通用。反过来如果写成Comparator? extends T那你就只能传入ComparatorInteger来比较IntegerComparatorNumber反而不能用了这显然不合理。4.3 常见编译错误速查错误信息原因解决方法ListInteger cannot be converted to ListNumber泛型不变性用List? extends Numberadd(capture#1 of ? extends Number) cannot be appliedextends不能写改用super或去掉通配符incompatible types: Object cannot be converted to Integersuper只能读成Object用extends或显式强转non-static type variable T cannot be referenced from a static context静态上下文引用类类型参数把T声明在方法上4.4 几个我踩过的坑坑一以为List?等于ListObject。List?可以接受任何类型的List但你只能读成Object不能写。ListObject只能接受ListObject但可以读写Object。两者用途完全不同。坑二在extends上强行add。我见过有人写List? extends Number list ...; list.add(1);然后困惑为什么编译不过。记住extends是只读的。坑三忘记通配符捕获。当你需要对List?做原地修改时不要硬刚编译器写个辅助泛型方法捕获一下就行。坑四过度使用通配符。不是所有地方都需要? extends或? super。如果一个方法内部既读又写或者类型关系很简单直接用具体的T更清晰。通配符是给API设计者用的不是给所有代码用的。5. 从字节码层面理解型变这一节给想深入的同学。我们用javap看看通配符在字节码层面到底是什么样子。5.1 extends的字节码表现public static double sum(List? extends Number list) { double total 0; for (Number n : list) { total n.doubleValue(); } return total; }编译后方法签名里的List? extends Number会被擦除成List但会在Signature属性里保留泛型信息。list.get(0)调用的是List.get(int)返回Object然后编译器自动插入checkcast Number指令。这就是为什么说泛型是编译期的语法糖——运行时该强转还是得强转只是编译器帮你做了。5.2 super的字节码表现public static void fill(List? super Integer list) { list.add(1); }list.add(1)调用的是List.add(Object)因为擦除后参数类型是Object。Integer自动装箱成Integer然后向上转型为Object。这里没有任何类型检查的开销因为写操作在编译期已经保证了安全。5.3 为什么这些细节值得了解了解字节码层面的实现能帮你理解一些“奇怪”的现象。比如为什么泛型方法的重载会有问题public static void foo(ListString list) {} public static void foo(ListInteger list) {} // 编译错误名称冲突因为擦除后两个方法的签名都是foo(List)不构成重载。这种错误在写工具类的时候偶尔会遇到知道原因就能快速定位。6. 设计API时的型变决策清单最后给一个实用的决策流程当你设计一个泛型API时可以按这个清单走一遍。6.1 五步决策法这个方法需要从容器里读数据吗需要 → 考虑extends这个方法需要往容器里写数据吗需要 → 考虑super既读又写→ 用具体的T别用通配符只读→? extends T读出来是T只写→? super T能写T及其子类6.2 一个完整的API设计示例假设你要设计一个Stream风格的管道public class PipelineT { // 生产者从上游读取数据 public PipelineT filter(Predicate? super T predicate) { ... } // 消费者把数据写到下游 public R PipelineR map(Function? super T, ? extends R mapper) { ... } // 终端操作消费数据 public void forEach(Consumer? super T action) { ... } }注意map方法的签名Function? super T, ? extends R。输入用super T消费者输出用extends R生产者。这是JDK里Stream.map的实际签名也是PECS原则的教科书级应用。6.3 什么时候不该用通配符类的类型参数class BoxT不要写成class Box? extends T语法上就不允许返回值类型返回值用具体的T让调用方有完整的操作能力简单场景如果方法只在内部使用不对外暴露没必要为了“通用”而加通配符性能敏感路径通配符会带来额外的类型检查虽然现代JVM优化得很好但在极端场景下仍有影响6.4 团队协作中的建议在团队里推广PECS原则时我建议从代码审查入手。看到ListObject作为参数的地方问一句“这里是不是可以用? super T”看到List? extends T上调用add的地方提醒一下“extends是只读的”。另外IDE的提示很有用。IntelliJ IDEA会提示你“Type parameter can be replaced with wildcard”跟着提示走通常不会错。但也要理解背后的原因不要盲目接受所有建议。我个人在实际操作中的体会是泛型型变这个东西看再多教程不如自己写几个方法签名试一遍。编译器报错是最好的老师每次报错都想想为什么几次下来就形成肌肉记忆了。最开始可以刻意练习拿到一个集合参数先问自己是读还是写然后决定用extends还是super。练上二三十个方法基本就不会再搞混了。