泛型是什么别急着背定义先看一段让你头皮发麻的代码List list new ArrayList(); list.add(hello); list.add(42); String s (String) list.get(0); // 勉强能跑 String t (String) list.get(1); // ClassCastException 炸了这种代码在Java 5之前是常态。你小心翼翼地从集合里取出对象再手动强转成自己想要的类型编译期永远笑眯眯运行期随时给你致命一击。泛型的本质就是把“类型”也变成一种可传递的参数让编译器在编译时就能帮你拦住类型错误而不是把雷留到深夜的线上事故里。记住一句话没有泛型的集合是装满Object的大杂烩有泛型的集合是贴着标签的收纳盒。标签一贴放错东西直接编译报错干净利落。从喝水说起为什么你需要类型参数想象你开了一家奶茶店。没有泛型时你只有一种杯子叫Object杯。顾客说要珍珠奶茶你往杯里倒咖啡也合法顾客要柠檬水你往杯里塞冰块也合法。反正杯子是万能的装什么都能装但喝的时候你自己都不知道杯子里是什么。泛型就是给杯子印上规格这是珍珠奶茶专用杯倒咖啡门都没有。以最简单的泛型类为例public class BoxT { private T content; public void set(T content) { this.content content; } public T get() { return content; } }T是类型参数你可以把它理解成杯子上的标签位。使用时指定具体类型BoxString stringBox new Box(); stringBox.set(hello); // stringBox.set(42); // 编译错误类型安全就此生效 String value stringBox.get(); // 不用强转泛型带来的第一个红利就是消除强制类型转换。没有泛型时get()返回Object你必须手写(String)。有泛型后编译器知道你的Box里装的是String直接返回String代码更干净也更不容易出错。泛型类、泛型接口、泛型方法三兄弟各有脾气泛型类像上面Box那样整个类都被类型参数化了。泛型接口最常见的就是ComparableT和ListT。你还得注意实现泛型接口时如果没指定类型默认会当作Object处理等于白受罪class StringComparator implements ComparatorString { // 正确 public int compare(String a, String b) { ... } }泛型方法则是方法自己的类型参数和类是否泛型无关。比如写一个通用的数组转List工具public static T ListT arrayToList(T[] arr) { return new ArrayList(Arrays.asList(arr)); }调用时你不需要写String编译器会根据参数的Integer数组推断出T是Integer。泛型方法的精髓在于类型参数只属于该方法不必污染整个类定义。如果一个方法想要接受“任意类型但类型必须一致”的参数泛型方法就是唯一解。还有一种情况你想在静态方法里使用泛型。静态方法不能访问类上的类型参数因为类级别T是实例相关的。解决办法就是在静态方法上定义自己的泛型这几乎是唯一出路public static T T getFirst(ListT list) { return list.get(0); }通配符不是代表万事大吉很多初学者一看到?就以为它是“随便什么类型”然后写出一堆编译错误。?是通配符但它有上界和下界之分用错了就是地狱。假设你要写一个方法打印任意List的所有元素public static void printList(List? list) { for (Object o : list) System.out.println(o); }List?表示“某种未知类型列表”你只能读不能往里add任何东西除了null。因为不知道具体类型往里面放String可能实际是Integer列表编译器当然拒绝。通配符的核心作用是“只读不写”或“受限写入”。上界通配符? extends T允许你从一个集合中安全地读取T或其子类型public static double sum(Collection? extends Number nums) { double total 0; for (Number n : nums) total n.doubleValue(); return total; }这里你可以传入ListInteger、ListDouble因为它们都满足“是Number的子类型”。上界通配符解决的是“协变”问题——ListInteger和ListNumber没有任何父子关系但? extends Number让它们可以被统一接受。下界通配符? super T则相反适合写入场景。比如你想向一个列表里放整数但这个列表可能是ListNumber或ListObjectpublic static void addInt(List? super Integer list) { list.add(42); }下界通配符解决的是“逆变”问题——你只关心能往里放不关心它能被当成什么读出来。写一个方法同时用上界和下界小心了PECS法则记住没Producer Extends Consumer Super。也就是如果你从这个集合里生产元素读取用extends如果你往集合里消费元素写入用super。这个法则能救命。泛型擦除编译器的障眼法泛型最让人迷惑的一点是Java的泛型不是运行时的它只存在于编译期。编译完成后泛型信息就被擦除了。也就是说ListString和ListInteger在运行时都是同一个List只不过元素被自动加了检查。看这段代码Class? c1 new ArrayListString().getClass(); Class? c2 new ArrayListInteger().getClass(); System.out.println(c1 c2); // true两个数组列表的类对象完全一样。泛型擦除意味着你不能用instanceof检查泛型类型比如if (list instanceof ArrayListString)直接编译错误因为ArrayListString在运行时不存在。擦除还带来一个经典问题你不能创建泛型数组。T[] array new T[10]会报错因为运行时不知道T是什么。解决方法通常是使用(T[]) new Object[10]但会收到未检查警告。泛型数组为什么被禁用因为数组是协变的而泛型是不变的两者在运行时擦除后根本无法保证类型安全。擦除对方法重载也有影响。你不能写void f(ListString l)和void f(ListInteger l)两个方法因为擦除后它们变成void f(List l)和void f(List l)签名完全一样编译直接冲突。这就是为什么桥方法、签名污染这些概念存在的原因——编译器为了让你感觉泛型“存在”偷偷在字节码里生成了辅助方法。实战踩坑这些错误你迟早要犯坑一不能直接new泛型类型。T obj new T()编译不过。因为类型擦除后T无法实例化。解决方法是传入一个ClassT对象用反射创建public static T T create(ClassT clazz) throws Exception { return clazz.getDeclaredConstructor().newInstance(); }坑二泛型方法中的类型推断陷阱。比如Collections.emptyList()如果你这样写ListString list Collections.emptyList(); // 能推断出来但如果你链式调用void f(ListString l) {} f(Collections.emptyList()); // 有时会推断成Object导致编译错误需要显式指定类型参数Collections.StringemptyList()。类型推断不是万能的复杂嵌套时它可能猜错你的心思。坑三通配符嵌套地狱。ListList?和List? extends List?有什么区别前者是“装了一堆未知元素列表的列表”后者是“某个未知类型列表的列表且这个列表的子类型列表也符合”。大多数时候你不需要这么复杂如果你发现自己写了三层以上通配符嵌套停下来想想是不是设计出了问题。坑四匿名内部类中的泛型捕获。new ArrayList()在匿名类里没问题但new Comparable?()就说不通了因为?不能用于创建实例。泛型只在声明一侧允许通配符在实例化一侧必须用具体类型或推断。泛型方法和类型边界让代码真正通用有时你不只想用T还想限定T必须具有某些能力。这就是类型边界public static T extends ComparableT T max(T a, T b) { return a.compareTo(b) 0 ? a : b; }T extends ComparableT告诉编译器T必须实现Comparable接口并且比较的是它自己。这样你在方法内可以直接调用compareTo因为编译器知道T有这个能力。类型边界让泛型从“什么都能装”升级为“装了就必须会某种技能”。这比Object强转要安全得多。你还可能见到T extends Number ComparableT这种多重边界注意类只能有一个接口可以有多个且类要写在最前面。边界泛型最常见的用法是编写排序、查找等通用算法。比如写一个通用的找最大元素的方法你不需要为Integer、Double写多个重载。一个泛型方法加一个边界搞定所有实现了Comparable的类型这就是抽象的力量。泛型的自限性一个看似奇怪实则巧妙的模式T extends ComparableT这种写法很常见但如果你见过class TypeT extends TypeT可能会一头雾水。这种“自限性泛型”常出现在构建器中。比如public abstract class BuilderT extends BuilderT { public T setName(String name) { // 设置操作 return self(); } protected abstract T self(); }子类继承后BuilderStudent的方法返回的是Student而不是原始的Builder这让链式调用能保持具体类型。自限性泛型的价值在于让父类中定义的方法返回子类自己的类型从而支持流畅的链式编程同时避免向下转型。不过对于初学者不必深究这种模式。只要明白泛型的边界越精确你能调用的方法就越多但同时能接受的类型范围就越窄。这种权衡贯穿泛型设计始终。生产代码里的七个实用建议第一优先使用泛型方法而不是将整个类泛型化除非这个类确实需要多种类型字段。泛型类增加了代码的阅读成本能局部就局部。第二总是使用类型参数不要使用原始类型。比如用ListInteger而不是裸List。裸类型失去了所有类型安全检查是初学者最常犯的错误之一。第三处理未检查警告时先不要用SuppressWarnings糊弄。警告意味着编译器检测到了潜在的类型风险你要么修正要么确保自己完全理解风险后再抑制。第四在将泛型类用于静态上下文时务必小心。静态变量不能引用类级别的T因为T没有实例关联。如果想在静态字段中持有泛型数据只能通过静态泛型方法间接操作。第五泛型友好的API设计。如果你开发的库供别人调用返回类型最好用有界通配符或具体类型避免让调用者做无谓的强转。例如返回ListString就好不必返回? extends ListString那只是给自己找麻烦。第六不要试图捕获泛型异常。你不能定义class MyExceptionT extends Exception因为异常在运行时会被擦除JVM用异常来做控制流时需要具体类信息。更别说泛型类型不能被抛出或捕获。第七用局部变量推断来简化代码。Java 10引入var后你可以写var list new ArrayListString()但记住var只能用于局部变量不能用于字段或方法参数。var不会改变泛型的运行行为它只是让你的代码不再重复写类型的“语法糖”。从理解到掌握泛型思维模式学习泛型最深的坎不是语法而是思维模式的转变。不要总是想着“这个类型参数到底是什么”而是问自己“这个类型参数有哪些约束我需要它具备什么能力”。泛型是一种抽象能力你可以把它想象成“类型层面的函数”——输入一个类型输出一个新的具体类型。当你写T extends ComparableT时你不是在写“T”你是在说“任何可以和自己比较的类型”。当你写? super Integer时你不是在写“未知类型”你是在说“能够接受Integer作为元素的任何父类型集合”。每个通配符和边界都是一个命题表达的是类型之间的关系而不仅仅是单一的某个类型。另一层思维是“泛型是一把双刃剑”。过度使用泛型会让代码变得像天书比如Function? super T, ? extends R这种签名虽然不是不能理解但对于初学者和后期维护者都是负担。最好的泛型使用是让意图清晰而不是卖弄技巧。如果你的团队里大多数人看不懂你的泛型签名那这行代码就是技术债。最后回到最开始那个摔碎的茶杯。泛型保证了“编译期正确”但并不能保证“逻辑正确”。你依然可能往泛型List里放一个null然后空指针依然可能把两个String拼接出错误结果。泛型不是银弹它只是把错误从运行期提前到了编译期。你能在写代码的时候而不是上线后发现问题这已经是极大的进步了。别害怕那些尖括号它们不过是约束的符号化表达。拿起你的T从今天开始认真对待每一个类型参数。你写的每一行泛型代码都是在和编译器签订一份契约我保证这个变量只装这些东西你保证在运行时刻不再让我强转。这份契约值得你付出注意力去写清楚。