Java泛型与集合框架：类型擦除、选型与实战陷阱

今天这篇是泛型和集合系列的第二篇。上一讲我们敲开了泛型Generic的大门也把集合Collection框架的主干梳理了一遍。这一篇不打算再按教材顺序罗列API而是直接从一个线上事故开始讲代码里明明写的是ListString运行起来元素取出来时却炸了个ClassCastException查了半天才发现是泛型擦除在背后“偷梁换柱”。如果你也有过这种被泛型坑到怀疑人生的经历或者对集合框架的选型、排序、去重、求交集差集这些高频操作还停留在“能跑就行”的阶段这篇就是给你准备的。我会从类型擦除的原理开始把通配符、比较器、HashMap的底层设计、常见的集合陷阱串起来最后用几个真实场景收尾。内容适合刚学完Java基础、正想写点正经项目的同学也适合马上要面试、想恶补集合底层细节的读者。每一节我都会讲清楚“为什么”不只是给结论。1. 从一次ClassCastException聊起泛型的类型擦除与编译器的“善意欺骗”1.1 泛型不是运行时类型而是编译期约束先说那个事故的现场还原。业务代码大概是这样的ListString names new ArrayList(); names.add(张三); // 某一处反射或者旧代码绕过了泛型检查 Method addMethod names.getClass().getMethod(add, Object.class); addMethod.invoke(names, 123); // ... String name names.get(0); // 这里安然无恙 String other names.get(1); // ClassCastException: Integer cannot be cast to String为什么会这样因为Java的泛型走的是类型擦除Type Erasure路线。ListString在编译成字节码之后JVM里看到的还是裸的ArrayList里面存的都是Object。编译器在编译阶段用泛型信息做了两件事一是检查你的add调用参数类型是否匹配二是在get()返回时自动插入一个强制类型转换指令。所以String other names.get(1)这行代码实际执行的是String other (String) names.get(1)。泛型类型参数在运行时是不存在的。这和C的模板完全不一样。C模板是编译期展开每个类型参数都会生成一份独立代码而Java泛型是编译期检查运行期擦除好处是JVM不需要为每个泛型类型创建新的类老代码也能平滑兼容代价就是你没法在运行时拿到T的真实类型。理解这一点之后很多奇奇怪怪的问题就有了解释。比如为什么ListString.class这种写法是非法的因为擦除后所有List都是同一个ArrayList.class。再比如为什么instanceof不能用在泛型类型上因为运行时根本没有ArrayListString和ArrayListInteger的区别。1.2 擦除带来的三个经典坑位擦除这件事至少给我带来过三次难忘的“惊喜”估计你也迟早会碰上。第一个坑new T()和new T[]不能写。原因很简单编译器不知道T到底是什么类型自然没法生成对应的构造和数组创建指令。常见绕法要么是传入ClassT参数然后用反射去newInstance()要么就干脆用Object[]然后在外面强转。public class GenericFactoryT { private final ClassT clazz; public GenericFactory(ClassT clazz) { this.clazz clazz; } public T create() throws Exception { return clazz.getDeclaredConstructor().newInstance(); } }第二个坑静态上下文不能引用类型参数T。静态成员属于类本身而类的泛型参数是实例化时由调用方指定的。类被加载的时候JVM根本不知道调用方传的是什么类型所以static T instance;这种写法直接编译不过。这其实是设计上的必然不是Java偷懒。第三个坑instanceof无法对泛型类型做判断。你没法写if (obj instanceof ListString)只能写if (obj instanceof List)。要判断元素类型怎么办要么遍历检查每个元素要么在构造时保存Class对象用clazz.isInstance(element)来做判断。做泛型工具库的时候这个很常见。1.3 破解擦除的常用姿势显式传递ClassT擦除虽然烦但Java给你开了一扇窗通过显式传递ClassT对象你可以在运行时拿到类型信息。最典型的就是各种JSON序列化库和ORM框架。public class JsonUtil { public static T T parse(String json, ClassT clazz) { // 内部需要clazz来指导反序列化器创建目标对象 } }Jackson的TypeReference也是干这个用的。因为readValue在擦除后只拿到个Class没法还原ListUser这种带泛型参数的类型所以通过new TypeReferenceListUser() {}这种匿名子类写法把泛型类型信息通过带泛型的父类保存下来。JDK在Type接口体系里预留了这个口子Class.getGenericSuperclass()能拿到父类的泛型参数这也是很多框架能“绕过”擦除的根本原理。实际写代码我不建议一上来就反射。反射调用比直接new慢一个数量级而且绕过了编译期检查容易埋雷。最推荐的路子是能传Class就传Class能用匿名子类保存泛型就当用但一定要在注释里说明为什么这样写否则同事看到这段代码大概率是一头雾水。2. 泛型集合的边界管理通配符、PECS与比较器选型2.1 为什么需要通配符协变与不变泛型还有一个让新手普遍挠头的问题ListObject不是ListString的父类。虽然String是Object的子类但ListString和ListObject之间没有任何继承关系。这跟数组不一样数组是协变的String[]可以安全地赋值给Object[]泛型是不变的两个不同的泛型参数之间不认父子。这就带来一个实际困难。你写了一个工具方法入参是ListObject想把ListString传进去直接编译报错。为了解决这个问题Java引入了通配符?List? extends Number可以读不能写除了null。因为编译器只知道里面是Number的某个子类具体是哪个不知道安全起见不允许往里塞元素。List? super Integer可以写Integer读出来只能是Object。因为编译器可以确定Integer是其下界的合法元素但读取时无法确定具体类型。那什么场景用哪个记住PECS原则Producer Extends, Consumer Super。如果集合是“生产者”是你从里面取数据往外用就用extends如果集合是“消费者”是你往里写数据给别人处理就用super。public static double sum(List? extends Number numbers) { double total 0; for (Number n : numbers) { total n.doubleValue(); } return total; } public static void fillWithOnes(List? super Integer list) { list.add(1); list.add(2); }2.2 泛型方法类型推断藏在方法签名里类上的泛型参数作用于整个类但很多时候你只需要在一个方法内部保持类型安全。这时候应该用泛型方法方法自己的类型参数放在修饰符后面、返回类型前面。public static T ListT reverse(ListT source) { ListT result new ArrayList(source.size()); for (int i source.size() - 1; i 0; i--) { result.add(source.get(i)); } return result; }泛型方法的类型参数是编译器根据实参推断出来的所以调用时通常不用显式指定reverse(stringList)编译器自然就知道T是String。这在写工具类的时候特别爽一个方法通吃所有类型的List还不用强转。顺带说一个泛型集合的高频痛点是基本类型不能直接作为泛型参数。Listint是编译不过的得用ListInteger。自动装箱从Java 5开始就有看起来无感但真正写高性能代码时ArrayListInteger里大量的小整数对象会带来显著的装箱开销和GC压力。有些基础库会专门用IntArrayList之类的专用集合来规避这个问题这算是泛型在Java里的一个历史遗憾吧。2.3 比较器实战泛型集合“比较大小”的正确姿势热词里有个“java泛型 比较大小”这点在集合里太常用了。排序和去重都依赖元素之间能比较大小。Java提供了两个机制Comparable和Comparator。Comparable是“我能跟自己比”类实现它表示具备自然顺序。比如Integer实现了ComparableInteger所以ListInteger直接Collections.sort()就能排。Comparator是“我找个裁判来帮你们比”排序策略和业务类解耦好处是可以随时换排序规则不用改实体类。// 实体类 public class User { private int id; private String name; // getter/setter 省略 } // 按id升序再按name字典序 ListUser users ...; users.sort(Comparator.comparing(User::getId) .thenComparing(User::getName));这个Comparator.comparing就是利用泛型方法的类型推断把FunctionT, Comparable和ComparatorT串起来。链式写法可读性很好比写一大堆匿名内部类干净太多。有两个坑提醒一下。一个是TreeSet依赖Comparator或Comparable来判断元素是否重复如果两个对象通过compareTo返回0即使它们的equals不相等TreeSet也会认为是同一个元素。另一个是直接写Comparator.comparingInt(a - a - b)这种减法式比较在a是Integer.MAX_VALUE、b是-1时会溢出成负数排序结果完全错乱。正确写法是用Integer.compare(a, b)或者Comparator.comparingInt(a - a)。3. 集合框架选型从数据结构看懂ArrayList、HashSet、HashMap怎么选3.1 List体系ArrayList还是LinkedList很多人问我网上都说得看场景 ArrayList适合随机访问LinkedList适合频繁插入删除。道理没错但实际开发我几乎只用ArrayList不是LinkedList不好而是绝大多数业务场景根本用不上它的优势。ArrayList底层是数组get(index)是O(1)add在末尾平均也是O(1)就是扩容时偶尔要整体拷贝。LinkedList底层是双向链表头尾插入删除O(1)但get(index)要挨个遍历O(n)。而且链表节点自带前后指针内存占用比数组大不少还容易打散CPU缓存。想快速判断如果业务里需要频繁在列表中间插入或删除且列表规模很大可以考虑LinkedList否则一律ArrayList。别为了“可能有的性能需求”提前优化大多数时候ArrayList的性能已经足够好而且局部性好、内存紧凑在真实机器上跑起来通常更快。一个小技巧如果能估算出大概容量创建ArrayList时先指定初始大小比如new ArrayList(1000)可以省掉好几次扩容数组的拷贝开销。这在数据量大、并发高的场景里收益很明显。3.2 Set体系HashSet/LinkedHashSet/TreeSet取舍Set的核心语义是不允许重复。Java里三个主要实现各有偏重实现类底层结构有序性时间复杂度适用场景HashSetHashMap无序O(1)默认选择去重、判断存在LinkedHashSetHashMap 双向链表按插入顺序O(1)需要去重且保留插入顺序TreeSet红黑树按排序规则O(log n)需要自动排序的唯一集合HashSet之所以是默认选择是因为它的contains、add、remove都是常数时间海量数据下去重性能极好。但它要求元素正确重写equals和hashCode否则去重就是摆设。很多人在这里踩坑两个对象字段一模一样放进HashSet后居然两个都留下了。原因就是没重写hashCode导致它们散落在不同的桶里equals根本没机会被调。要用TreeSet元素要么实现Comparable要么在构造时传Comparator。它能维持一个始终有序的集合适合需要“随时拿最小/最大元素”的场景。但请记住排序需要比较而比较的代价比哈希高得多数据量大的时候TreeSet明显比HashSet慢。3.3 Map体系HashMap核心机制与并发选择HashMap是面试高频也是日常开发最常用的Map实现。JDK 8之后底层是数组链表红黑树。put一个键值对时先算key的hashCode再经过一次扰动函数降低碰撞概率然后用(n - 1) hash定位到数组桶位。如果桶里已经有元素了就挂在链表后面链表长度超过8且数组长度超过64时链表会转成红黑树把最坏情况下的查询从O(n)降到O(log n)。HashMap的默认初始容量是16负载因子0.75意思是元素个数达到16 * 0.75 12时触发扩容变成32然后重新分配所有元素的位置。这个rehash过程性能开销很大。所以如果你知道大概要存多少数据最好在初始化时就指定足够大的容量比如预估存1000个元素直接new HashMap(2048)避免扩容。为什么容量必须是2的幂因为(n - 1) hash这种位运算只有在n是2的幂时才能正确散落到[0, n-1]范围。如果你在构造时传入的不是2的幂HashMap会往上取最近的2的幂作为实际容量。并发场景下就一条原则不要用HashMap。JDK 7的HashMap并发put可能形成循环链表导致下次get时CPU飙到100%JDK 8修复了死循环但并发下的数据覆盖、size不准确等问题依然存在。正确做法是用ConcurrentHashMap它通过CASSynchronized锁住单个桶位实现细粒度并发锁竞争比Hashtable这种整个方法加锁的方式小得多。Hashtable这个老类已经基本没有使用场景了。Map的有序需求也有对应实现LinkedHashMap按插入顺序或访问顺序可以用来做LRU缓存TreeMap按键排序。选型之前在脑子里过一遍这三者能少走很多弯路。3.4 延伸Java集合和Python集合的视角对照说到集合很多人刚接触Python时会发现它的list、dict、tuple、set是语法级内置的直接用字面量写[1,2,3]就是一个列表不需要import什么包。而Java的Collection是一个庞大的接口继承体系List、Set是接口ArrayList、HashSet是实现类用之前必须明确自己拿的是接口还是实现。这两种设计方向各有利弊。Java集合框架提供了丰富的算法工具Collections、Stream和稳定的接口抽象适合大型工程里做依赖倒置Python的集合更直白写脚本时效率极高。这里想说的是不同语言里的“集合”这个词含义有微妙差异Java里叫CollectionPython里叫list/set/dict向量数据库里的Collection又是另一套概念。写代码时先确认自己当下说的是哪一种别拿Java的Set逻辑去套Python的frozenset两者的可变性和性能特征完全不同。4. 泛型集合的实战组合拳通用工具方法、链式排序与传统集合运算4.1 用泛型方法封装通用List工具写业务代码久了你会发现同一段“从List里取出对象的某个字段、去重、排序”的逻辑到处都是。与其复制粘贴不如封装成泛型工具方法。举几个我项目里一直在用的public static T ListT dedup(ListT list) { if (list null || list.isEmpty()) { return list; } return new ArrayList(new LinkedHashSet(list)); } public static T boolean isNullOrEmpty(CollectionT coll) { return coll null || coll.isEmpty(); } public static T, R ListR mapFields(ListT list, FunctionT, R mapper) { if (list null || list.isEmpty()) { return Collections.emptyList(); } ListR result new ArrayList(list.size()); for (T item : list) { result.add(mapper.apply(item)); } return result; }dedup用LinkedHashSet去重既去掉了重复项又保留了原始顺序比直接用HashSet更符合业务直觉。mapFields用FunctionT, R做字段映射调的时候可以写成mapFields(users, User::getName)类型完全由编译器推断既安全又清晰。这些工具方法因为带泛型所以能通用于任何List而不是给每个实体类都写一份。4.2 “传统集合运算”在Java中的表达数学里的交集、并集、差集在Java集合里都有对应的API交集list1.retainAll(list2)并集list1.addAll(list2)差集list1.removeAll(list2)子集判断list1.containsAll(list2)这里有个性能坑。如果直接在ArrayList上调用removeAll底层是逐个元素去contains另一个集合总时间复杂度是O(n*m)。两个集合都是十万级时这个操作能卡死你的程序。正确做法是先把被查的集合转成HashSet把contains降到O(1)再遍历删除。public static T ListT difference(ListT left, ListT right) { HashSetT rightSet new HashSet(right); return left.stream() .filter(e - !rightSet.contains(e)) .collect(Collectors.toList()); }这个版本的差集不管left和right各多大整体复杂度都是O(nm)实测比裸的removeAll快一个数量级不止。我每次在项目里做黑白名单过滤或者数据对账时都用这一套。4.3 Stream改造集合操作惰性求值与不可变性Java 8引入Stream之后集合操作可以用函数式风格写得更简洁。比如要筛出所有姓张的用户并按id排序传统写法要三五行Stream一行就够ListUser result users.stream() .filter(u - u.getName().startsWith(张)) .sorted(Comparator.comparingInt(User::getId)) .collect(Collectors.toList());Stream的一个关键特性是惰性求值。链上的filter和sorted不会立刻执行直到你调用collect这类终端操作才真正开始算。好处是对于无限数据流和大量元素可以优化执行过程比如limit(10)在找到10个满足条件的元素后就会短路不用遍历整个集合。用Stream时特别容易踩的一个坑Collectors.toMap遇到重复key会抛IllegalStateException。比如按用户id转Map但列表里有两个同id的人直接就炸了。解决方式是给toMap传第三个参数指定冲突时保留哪个MapInteger, User userMap users.stream() .collect(Collectors.toMap(User::getId, u - u, (oldVal, newVal) - oldVal));另外Stream本身不会修改源集合filter只会产生一个新的流源List保持不变。如果你期望原集合被修改比如删除某些元素Stream不是合适的工具直接用removeIf更合理。5. 实战中的泛型集合陷阱从Arrays.asList到subList的排查记录5.1 Arrays.asList返回的不是ArrayList写过Arrays.asList(a, b)之后想再add(c)运行时报UnsupportedOperationException。原因很简单Arrays.asList返回的是内部类Arrays$ArrayList不是java.util.ArrayList。它固定了数组长度只实现了set方法没实现add和remove。用Arrays.asList转完还想增删就再包一层ListString list new ArrayList(Arrays.asList(a, b)); list.add(c);还有一个更隐蔽的坑Arrays.asList接收的是可变参数如果你传一个int[]数组编译器会把整个数组当成一个Object得到一个Listint[]而不是ListInteger。想要正确变成元素列表得遍历数组手动装箱或者依赖Stream的boxed()。5.2 subList是视图不是副本List.subList(from, to)返回的是原List的一个视图。意思是修改subList里的元素原List跟着变反过来如果原List发生了结构性修改增删元素你手里已有的subList再操作时就会抛ConcurrentModificationException。ListString list new ArrayList(Arrays.asList(a, b, c, d)); ListString sub list.subList(1, 3); list.add(e); // 结构性修改 String x sub.get(0); // ConcurrentModificationException想要独立的子列表老老实实复制一份new ArrayList(list.subList(1, 3))。做分页、截取操作时务必记住这一点。5.3 增强for循环里删除元素经典并发修改下面这段代码看起来很自然运行必炸for (String s : list) { if (b.equals(s)) { list.remove(s); } }原因在于增强for循环底层是迭代器但这里用的是List自己的remove迭代器的快速失败机制检测到列表被外部修改立刻抛ConcurrentModificationException。正确做法有三选一// 方式一显式使用迭代器的remove IteratorString it list.iterator(); while (it.hasNext()) { if (b.equals(it.next())) { it.remove(); } } // 方式二JDK 8的removeIf list.removeIf(s - b.equals(s)); // 方式三收集要删的元素最后统一removeAll ListString toRemove list.stream() .filter(s - b.equals(s)) .collect(Collectors.toList()); list.removeAll(toRemove);removeIf实测比迭代器写法更简洁JDK 8之后我基本只用它。第三种方式适合删除条件复杂、或者需要先计算再删除的场景。5.4 声明类型用接口而不是实现类一个代码规范问题也顺手说一下声明变量时尽量用接口类型比如ListString list new ArrayList()而不是ArrayListString list new ArrayList()。原因很简单接口类型让你后续可以无缝替换实现类比如换成LinkedList、换成本地缓存列表或者换成Collections.unmodifiableList()包装后的只读列表。而如果声明成ArrayList换实现时就要改动所有引用的地方。这个习惯在写公共方法参数时尤其重要入参尽量用List、Set、Map这些接口实现细节留给调用方灵活决定。看重泛型和集合本质上是在看重类型安全、性能和数据结构的匹配度。我自己的体会是泛型不是纯理论它和集合框架嵌套在一起才发挥出最大价值泛型保证你在编译期就能发现类型错误集合框架在你确定数据结构之后决定运行期的性能和语义。下一讲可以深入聊聊Stream的Collectors底层原理以及ConcurrentHashMap在JDK 8之后的分段锁实现细节。这一篇把基础打牢下一篇就能稳稳接住。