理解Java泛型：让代码更安全、更简洁

一个没有泛型的Java世界是什么样的你从ArrayList里取出一只Dog编译器却只肯保证它是Object。你小心翼翼地强转运行到一半ClassCastException砸在你脸上。更糟糕的是这种错误发生在毫秒之间发生在千万行代码的深处让你无从查起。Java泛型的诞生正是为了把这种运行时痛苦提前到编译期变成一声轻响。编译期里的红线泛型最直接的好处是消灭了强制类型转换。没有泛型时集合里装的都是Object取出来必须手动转型转错了运行时报错。有了泛型你写List 编译器就在程序里埋下了看不见的检查哨。往里面塞一只Cat编译直接失败。泛型让错误在编译期现形而不是在运行期爆炸。这种“早失败”哲学是软件工程的黄金法则。越早发现缺陷修复成本越低。运行期的ClassCastException可能在你交付给用户三个月后才出现而编译期的错误在你敲下回车的那一毫秒就被钉死。更重要的是泛型带来的并不只是安全。它让程序读起来更干净。你看到List 立刻知道里面装有字符串而不是一堆需要心算的Object。代码的自文档化程度提升了协作时心智负担大幅降低。泛型不只是一种语法糖它是写给下一个开发者的情书。当你的同事打开这段代码不用翻遍所有调用点就能明白你的意图这比一百行注释更有效。擦除——一份被刻意遗忘的记忆不过泛型有一条要命的规定Java虚拟机里从来不存在泛型。编译器把List 、List 统统擦成原始类型List再偷偷帮你插入类型转换。类型擦除意味着JVM根本不知道泛型的存在。它对List的内容只关心它是不是Object。所以运行时你无法判断一个List到底属于什么类型getClass()返回的都是ArrayList.class泛型参数被抹得一干二净。擦除带来很多连锁反应。你无法创建一个泛型数组比如T[] array new T[10];因为运行时不知道该创建什么类型。你无法直接实例化泛型参数T t new T();也是非法的。这些限制让很多初学者一头雾水但背后逻辑是自洽的泛型是编译期的工具运行时必须知道自己是什么类型。泛型是编译器的纪律不是JVM的壁垒。理解了这层关系你才能接受Java泛型的种种别扭。有人会问为什么Java不采用C#那样的真泛型让类型在运行时保留答案是兼容性。Java泛型在JDK 5.0引入时已有海量代码运行在JVM上。如果改变运行时类型系统所有旧代码都会面临失效。擦除泛型是唯一能保持二进制兼容的选择。泛型是安全的加法不是激进的革命。这种选择在理论上并不完美却在工程上拯救了整个Java生态。通配符与PECS——泛型的灵魂真正让Java泛型变得难以驾驭的是通配符。List? extends Animal和List? super Dog看起来差不多用起来却一个像刀一个像盾。如果你只读不写用extends如果你只写不读用super。这句话被缩写为PECS即Producer ExtendsConsumer Super。PECS是一条用直觉无法猜到的规则它是泛型的灵魂。生产者负责产出口数据所以它的上界可以收窄消费者负责接收写入所以它的下界可以放宽。这么说依然抽象。想象一个方法void feedAll(List? extends Animal animals)它从列表中拿出Animal喂食。因为上界是Animal编译器允许读取但不允许添加任何元素——你只确定它是Animal的某种子类却不敢放入一个Dog因为它也可能是Cat。反过来void addCats(List? super Cat cats)你只知道这个列表可以容纳Cat或它的父类于是你可以往里放Cat但读取时只能得到Object。不加通配符的泛型是死板的加了通配符的泛型是危险的。危险在于它把“只读”和“只写”的边界划得极其鲜明而程序员最容易踩入越界陷阱。泛型与数组——两种信任体系数组和泛型在Java中像两个性格完全相反的双胞胎。数组是协变的String[]是Object[]的子类型所以你可以把一个String[]赋给Object[]的引用。泛型却是不协变的List 不是List的子类型试着用List引用List 编译失败。为什么因为数组有运行时检查放错类型当场炸错泛型依靠编译期检查运行时已经被擦除。数组靠运行时检查泛型靠编译期检查这是两种完全不同的信任体系。但正因为如此数组和泛型不能混合使用。你不能创建new List [10]否则等到运行时擦除后的元素类型和数组的运行时检查会互相冲突。这种冲突的根源在于Java设计者选择在维护数组协变传统的同时引入安全的泛型。于是泛型必须牺牲协变性必须禁止泛型数组。很多框架代码为了绕过这个限制使用ArrayList 来替代E[]或者通过反射和Array.newInstance来创建真实的数组。这些技巧不仅危险而且啰嗦。不要试图让泛型和数组和平共处写代码时优先使用集合而不是泛型数组。如果你非要创建泛型数组那就要想清楚你是否真的理解了擦除。泛型方法、桥方法与那些看不见的补丁前面讨论的多是泛型类其实泛型方法同样重要。在方法声明中类型参数放在返回类型之前比如static T identity(T t) { return t; }。这种方式允许方法自身声明一套独立的类型约束而不依赖于类的泛型参数。泛型方法把“类型”本身也变成了一种可以被推导的参数。调用时通常不必显式指定类型Java会通过参数和返回类型推断。这个方法虽然简单却可以用于构建类型安全的工具库比如Collections.emptyList()返回一个带类型推断的空集合。但泛型方法也有高级陷阱。最典型的是类型推断与链式调用的交互。Java 8以后List list Collections.emptyList();可以编译而String s Collections.emptyList().get(0);则需要显式类型提示。编译器无法从链式调用的中间结果推断出类型因为目标类型只作用于整体表达式。为了解决这个问题你需要使用Collections. emptyList()显式指定。别把类型推断当作理所当然它只是编译器的善意不是必须履行的义务。类型擦除还会带来一个诡异的现象桥方法。如果你有一个父类声明T pick()子类用String覆盖它编译器会为子类生成一个额外的方法Object pick()它转身调用String pick()。这个额外的方法起到了“桥”的作用确保在多态调用时JVM能找到正确的方法。桥方法是编译器偷偷打上去的补丁牺牲可读性换来多态的正确性。如果你用反射去查看子类的方法你会惊讶地发现两个pick方法一个返回String一个返回Object。它们有相同的签名却参数相同这在Java源码里不合法但在字节码里是允许的。桥方法解释了为什么泛型与重载的结合如此微妙。你不能写void same(List list)和void same(List list)两个重载因为擦除后签名相同Java编译器直接报错。桥方法也解释了为什么泛型子类和泛型接口的实现容易混淆。你需要明白编译器为了保证泛型擦除后的多态会生成一些你根本看不到的方法。与其抱怨语言设计不如接受这种复杂性然后在自己的代码中尽量避免需要桥方法的情况。反射、异常与泛型的边界反射和泛型是另一对冤家。反射操作的对象都是原始的Class它看到的都是擦除后的类型。因此你无法通过反射取得一个泛型类的真实参数除非你使用ParameterizedType的扩展接口。Java的Type体系可以描述泛型类型但那是另一个复杂的系统而且大多数开发者一辈子也用不到。你无法用泛型模拟出“类型安全”的反射因为反射天生是类型盲。所以当你需要在运行时知道List 中的String是什么时必须额外保存类型信息比如传入String.class。异常领域同样有限制。你不能catch一个泛型异常因为catch语句需要具体可用的类而泛型的擦除让它变得模糊。你也不能抛出泛型参数异常比如throws T除非T被限定为Throwable的子类而即便如此编译器也会警告你。这些限制的根源都是擦除。擦除意味着类型信息在运行时丢失而反射和异常都是强运行时特性。泛型与反射、异常的交界处是Java设计中最保守的防线。这道防线保护了兼容性却牺牲了灵活性。泛型与Lambda、Stream——重生与僵局Java 8让泛型与Lambda碰撞出新的火花。Stream 和CollectorT, A, R充分利用泛型实现类型安全流水线。map()函数从一个类型映射到另一个类型collect()方法将结果收集到指定容器这些类型参数让链式调用变得优雅。泛型让流变得可读流让泛型变得灵动。然而随着类型复杂度的提升泛型推断经常会“卡壳”。如果你在collect(toMap())中使用复杂键值对实际类型可能长到一屏都放不下。这时候显式类型提示反而比依赖推断更清晰。更要提防的是通配符与stream的纠缠。例如Collectors.maxBy(Comparator? super T)中的下界以及Function? super T, ? extends R的组合都是PECS原则的延伸。如果你理解了PECS这些东西一目了然如果不理解你会觉得Java的类型系统就是一团乱麻。真正高明的程序员不是背下所有API的泛型签名而是看得出它们背后的模式。让复杂变得可控的最佳实践阅读到这里你应该明白泛型并非几条规则能概括。它像是Java语言里的一个缩影为了兼容性和安全性必须处处妥协。在这样的语言里最安全的做法是干净而保守地使用泛型。优先使用泛型类型不要使用原始类型。List 永远优于List。不要为了消灭一个警告而使用原始类型那是在用安全换清静。只要上下文允许尽量使用类型推断但一旦推断不明确就要显式写全类型不要指望编译器读懂你的心思。设计自己的泛型类或方法时花时间想清楚边界条件谁是生产者谁是消费者该用extends还是super。此外泛型也可以用来表达一些高级设计模式比如类型安全的异构建容器。你可以用Class 作为key存储任意类型的对象在取出时自动获得正确的类型。这种模式巧妙至极但也要注意别把代码复杂到难以维护。泛型的终点不是让代码变得复杂而是让复杂变得可控。当你发现一个泛型设计搞得团队里每一个人都在挠头那一定是设计本身出了问题。站在两个时代的分界线上回看那个没有泛型的世界。我们曾经习惯了到处强转的日子习惯了运行时的爆炸声。泛型没有解决所有问题它甚至带来了新的复杂。但它把最危险的类型错误从运行时搬到了编译时。Java泛型不是万能钥匙而是一把用纪律换安全的手术刀。你要学会的是握稳它而不是任由它割伤自己。所谓安全、简洁、可维护从来不是某个语言特性的功劳而是程序员在每一次设计和编码中对正确性的坚持。