翻到2月2日的java笔记时我正在给一个老项目做代码清理。那一页记得满满当当标题就四个字泛型是魔鬼。配着一堆示例代码和红笔标注基本能拼出当天的心流——在某个后台系统里改了一段用Object搬运数据的代码越看越别扭顺手把集合泛型补齐结果编译期直接拦下来好几处类型错误。这才决定把Java泛型从原理到实战完整过一遍。这篇笔记适合正在写Java的后端开发者、准备面试的应届生也适合那些“集合天天用、泛型却说不清”的半路开发者。看完你会明白泛型不是记住几个尖括号就完事的语法它决定了Java的类型安全到底靠什么来保障。1. 泛型到底解决了什么问题从“万能篮子”到“专用抽屉”很多人学泛型是从List开始的但真要理解它得先回到没有泛型的年代。JDK 1.4时期集合不写类型参数里面装的全是Object。这意味着什么就是一个篮子什么都能放你往里面丢苹果、螺丝刀、袜子的碎布条都不报错。等你哪天想做水果沙拉从篮子里往外掏的时候编译器只保证掏出来的是Object具体是苹果还是螺丝刀它不管只有运行到强转那行代码JVM才会炸一个ClassCastException给你看。这种错在大型项目里特别难排查。数据经过三层方法传递每一层都可能加进新元素等最终消费方强转失败报错日志里只能看到类型对不上却根本不知道是哪一层丢进去的“螺丝刀”。我印象很深的一个场景当时某系统的订单列表里混进了一个Long类型的值导致页面上的金额全部显示成0查了很久才发现是上游方法误把一个编号add进了金额集合。泛型就是给这个篮子贴上标签写着“只放苹果”。List 在编译期就明确告诉你这里只能装字符串你要是往里放Integer编译直接失败根本走不到运行期。这是泛型最核心的价值把类型错误从运行期提前到编译期暴露。1.1 从集合泛型到自定义容器尖括号里的类型占位符List 、MapString, Integer大家都会写但有多少人想过为什么尖括号里能写任意类型其实尖括号里的T、K、V这些字母本质就是类型占位符它在类定义时并不绑定具体类型而是在使用的时候由调用方指定。举个最简单的自定义容器例子public class BoxT { private T value; public void put(T value) { this.value value; } public T get() { return this.value; } public boolean isEmpty() { return this.value null; } }你写Box box new Box()时编译器会把整个类里所有出现T的位置替换成String相当于实例化出了一个“专用抽屉”。往里放Integer编译期就告诉你“不兼容的类型”。取出来的时候get()方法自动返回String不需要手动强转。这里有个新手很容易犯的错在类里面写静态字段或静态方法时直接使用T。比如public class BoxT { private static T sharedValue; // 编译报错 }原因后面讲类型擦除的时候会详细说这里先记住结论T是实例级别的东西静态上下文用不了。1.2 多类型参数与真实项目中的泛型基类泛型类不一定只有一个类型参数。很多项目的持久层基类就喜欢写成两个参数一个代表实体类型一个代表主键类型public class BaseRepositoryT, ID { private final MapID, T store new HashMap(); public void save(ID id, T entity) { store.put(id, entity); } public T findById(ID id) { return store.get(id); } public ListT findAll() { return new ArrayList(store.values()); } }这样设计的好处很明显某张表主键是Long另一张表主键是String实体类型也不同但底层增删改查逻辑完全一致写一个泛型基类就能覆盖所有场景。在某个后台管理系统的数据层我就见过类似写法当时这套抽象省掉了大量重复代码。使用的时候也直观BaseRepositoryUser, Long userRepo new BaseRepository(); BaseRepositoryConfig, String configRepo new BaseRepository();两个类型参数在尖括号里用逗号隔开顺序不能乱。这种“实体类型 主键类型”的组合在真实项目里非常常见理解了它你再看Spring Data JPA里的RepositoryT, ID, Long这类签名就不会觉得陌生了。2. 泛型方法与通配符绕晕多少人的上下界规则如果说泛型类还算好理解泛型方法和通配符就能过滤掉一批人。面试里常考的那道“List? extends T和List? super T有什么区别”其实就藏在这部分。2.1 泛型方法的签名到底怎么读先区一个概念泛型方法不是“泛型类里的方法”而是“方法自己声明了类型参数”的方法。最典型的就是数组交换元素public static T void swap(T[] array, int i, int j) { T temp array[i]; array[i] array[j]; array[j] temp; }注意static与void之间的那个 它不是返回类型而是告诉编译器“这是一个泛型方法”。有了这个声明方法体内才能用T作为类型。调用时可以显式指定也可以靠参数推断Integer[] nums {1, 2, 3}; swap(nums, 0, 2); // 编译器通过数组元素类型推断出 T Integer泛型方法最实用的场景是工具类。比如写一个“把任意类型的List转成Set并去重”的方法public static T SetT toSet(ListT list) { return new HashSet(list); }因为方法体不依赖某个具体类型而是对任何类型都成立所以必须声明成泛型方法。如果你把它写在一个普通类而非泛型类里那么 的位置就更加不能省略否则T根本无法解析。2.2 通配符与 extends/super 的读写规则Producer Extends, Consumer Super通配符?表示“不知道具体是什么类型但总归是某种类型”。它常见的三种形态是List?、List? extends Number、List? super Integer。很多人死记硬背“有extends只能读不能写有super只能写不能读”但不知道为什么。先看读的场景。public static void printNumbers(List? extends Number list) { for (Number n : list) { System.out.println(n); } }这个方法的参数可以是List 、List 、List 因为它们都是Number的子类型。方法内部只往外读元素编译器能安全地把每个元素当作Number来处理。但如果加一行list.add(42)编译就报错。为什么因为list的实际类型可能是List 你往里塞一个Integer语义上完全不对。编译器不知道list的精确类型只能拒绝一切add操作只允许add(null)这种任何类型都行的特例。再看写的场景。public static void addIntegers(List? super Integer list) { list.add(42); }这个方法的参数可以是List 、List 、List这套规则就是著名的PECS原则Producer ExtendsConsumer Super。如果你要从集合中读数据去生产/计算用extends如果你要往集合中写数据去消费/填充用super。最经典的组合就是集合之间的copy方法public static T void copy(List? extends T src, List? super T dest) { for (T item : src) { dest.add(item); } }这里src是生产者只负责提供T类型的数据所以用extendsdest是消费者只负责接收T类型的数据所以用super。这个写法在Java标准库的Collections.copy中也能看到变体。顺便说一个和数组对比的历史问题。Java数组是协变的Integer[]可以赋值给Number[]但集合泛型是不可变的List 不能赋值给List 。现在看这是刻意为之的安全设计数组协变在运行时靠ArrayStoreException兜底泛型则在编译期直接禁止显然更安全。3. 类型擦除泛型的“编译期骗局”与运行时真相泛型看起来是运行时的一种类型体系但Java的真实设计却是泛型几乎只存在于编译期。这就是类型擦除Type Erasure。3.1 擦除机制与桥方法你写List 和List 编译成字节码之后JVM看到的是同一个List类型尖括号里的类型信息被擦掉了。泛型类型参数要么被替换成Object要么被替换成它的上界比如 就被替换成Number。这就是为什么“同一个泛型类的不同实例”在运行时是同一个Class对象。打个比方泛型就像一张贴在箱子上的便签写“里面是String”“里面是Integer”。编译时编译器检查你按不按便签来放东西检查完毕进入运行时便签就被撕掉了箱子的物理结构还是同一个。但这里有个隐藏机制很多人不知道桥方法。看这段代码public class StringComparator implements ComparatorString { Override public int compare(String a, String b) { return a.compareTo(b); } }编译之后因为Comparator接口的类型参数被擦除接口方法变成了compare(Object, Object)。而StringComparator类里只写了compare(String, String)JVM调用时会找不到compare(Object, Object)的实现多态就挂了。编译器于是自动生成一个桥方法public int compare(Object a, Object b) { return compare((String) a, (String) b); }它把Object参数强转成String后转调我们写的方法。这个桥方法你在源码里看不见反编译class文件能看到。理解桥方法很多“为什么重载冲突”“为什么父类泛型方法变成Object参数”的问题都能迎刃而解。3.2 为什么不能 new T() 和创建泛型数组这是初学者最不理解的两个禁止。先看new T()一个类在运行时创建实例必须有具体的类元信息但T在编译后是Object你new Object()显然不是期望的语义所以Java直接禁止。常见解决办法是传入Class 类型用反射创建public class FactoryT { private final ClassT clazz; public Factory(ClassT clazz) { this.clazz clazz; } public T create() throws Exception { return clazz.getDeclaredConstructor().newInstance(); } }调用方需要传FactoryString.class这样的参数。这是反射拿到泛型类型的一种通用手段。再说泛型数组。很多人问既然List 不能用数组那List []为什么不行编译器会直接报“generic array creation”。原因很微妙假设Java允许你写ListString[] arr new ListString[2];那根据数组协变规则List []是可以赋值给Object[]的Object[] objArr arr; objArr[0] new ArrayListInteger();这一步编译和运行都不会报错因为ArrayList 本身就是一个Object。但问题来了arr声明的是List 的数组第一个元素实际却是List 。到时候你从arr[0]取元素编译器还当作String处理类型安全彻底被击穿。所以Java干脆禁止创建泛型数组。日常开发中想表达“一组List”直接用ArrayListList 即可既安全又够用。3.3 在运行时拿回泛型真实类型TypeToken的原理类型擦除虽然撕掉了便签但有一个例外通过继承子类可以把父类的泛型参数“固化”下来。很多JSON框架的反序列化都是靠这个原理实现的。看一个简化例子public abstract class TypeRefT { private final ClassT type; SuppressWarnings(unchecked) public TypeRef() { Type superclass getClass().getGenericSuperclass(); ParameterizedType parameterizedType (ParameterizedType) superclass; this.type (ClassT) parameterizedType.getActualTypeArguments()[0]; } public ClassT getType() { return type; } }当子类写成TypeRef anonymous new TypeRef () {}时getClass().getGenericSuperclass()返回的就不是普通Class而是包含泛型信息的ParameterizedType从中可以取出String这个真实类型。原理在于anonymous类直接显式继承了TypeRef 这个类型参数信息保留在了类签名里没有在实例化过程中丢失。这就是为什么Gson的TypeToken要写成new TypeTokenList () {}.getType()后面那个空的{}不能省略省略了就无法触发子类继承来保存类型参数。4. 实际开发中高频踩坑与排查思路泛型的坑往往不在写代码那一刻而在编译报错信息里。下面列几个我在实际项目里见过、也亲手踩过的点。4.1 静态上下文引用类型参数一写就编译失败泛型类的静态字段和静态方法不能使用类的类型参数T。原因是T在实例化时才确定而静态成员属于类本身类加载时还没有实例T到底是什么根本不知道。public class FooT { public static T instance; // 编译错误 public static void print(T t) { // 编译错误 } }解决办法通常有两种要么把方法自己声明成泛型方法public static T void print(T t) { System.out.println(t); }要么让静态方法只依赖具体类型不碰T。这一点在工具类设计中很多新人会反复踩写Utility类时容易把泛型类的设计思路带进去。4.2 重载冲突擦除后签名相同没法共存下面这段代码看着很正常但编译器会直接拒绝public void handle(ListString list) {} public void handle(ListInteger list) {}理由还是类型擦除。编译后两个方法都是handle(List)参数类型完全一样Java不允许同签名方法共存。这个规则很多人知道但真正遇到时会懵因为IDE有时会延迟报错Copy-Paste代码时更容易中招。解决思路也很直接改名是常态。比如handleStringList和handleIntegerList或者用一个方法统一处理public void handle(List? list) { // 内部判断元素类型再分别处理 }4.3 通配符捕获的add困境看这个例子public static void foo(List? list) { list.add(list.get(0)); // 编译报错 }明明get(0)返回的元素和list的原始类型一致凭什么不能add回去因为编译器只看到List?不知道list到底是List 还是List 所以除了null任何add操作都被拒绝。这里需要用“通配符捕获”技巧把一个临时方法暴露泛型参数public static void foo(List? list) { fooHelper(list); } private static T void fooHelper(ListT list) { list.add(list.get(0)); }foo内部把List?传给fooHelper编译器会捕获?表示的具体类型作为T这样add就能安全通过了。这个写法在刷LeetCode时会遇到在源码里也常见是个很有用的弯道超车技巧。4.4 运行时类型错误排查速查表现象原因解决方案或排查思路集合取元素强转报ClassCastException某处用了裸List/裸Map混入错误类型全量补齐泛型使用Collections.checkedList兜底泛型数组创建失败Java不支持泛型数组改用ArrayListList 或Object[] 类型检查静态字段引用T报编译错误静态上下文无法使用实例级类型参数改成泛型方法或放弃使用T两个方法因泛型擦除重载冲突擦除后方法签名相同改方法名或合并方法List?无法add非null元素编译器不确定具体类型使用通配符捕获的helper方法反射new T()失败擦除后T退化为Object传入Class 参数用反射创建实例排查原则就一条先想清楚这段代码编译后是什么样再动手。泛型报错十有八九是擦除机制在作怪。5. 一个值得抄作业的实践用泛型写重试模板理论讲再多不如写一个完整的工具类来得实在。下面是我在2月2日笔记里记录的一个通用重试模板后来在多个项目里都复用到了。5.1 需求场景与设计思路项目里调用外部接口是家常便饭偶发超时和临时性网络抖动免不了一拍脑袋就重试很容易把下游打挂不重试又得人工补数据。常规做法是写一个重试方法但每个接口返回类型不同如果为每个调用方写一套重试逻辑代码爆炸。泛型方法加函数式接口可以完美解决这个问题。我们用Callable 作为执行动作它既能执行任意逻辑又能返回任意类型的结果并通过泛型推断让调用方拿到正确类型。5.2 完整实现与使用示例public class RetryTemplate { public static T T retry(CallableT action, int maxAttempts, long retryIntervalMs) { if (maxAttempts 0) { throw new IllegalArgumentException(maxAttempts must be 0); } int attempt 0; while (true) { try { attempt; return action.call(); } catch (Exception e) { if (attempt maxAttempts) { throw new RuntimeException(重试 maxAttempts 次后仍然失败, e); } try { Thread.sleep(retryIntervalMs); } catch (InterruptedException ie) { Thread.currentThread().interrupt(); throw new RuntimeException(重试被中断, ie); } } } } }使用的时候lambda表达式返回什么类型T就被推断成什么类型String result RetryTemplate.retry(() - { return remoteApi.queryOrderStatus(orderId); // 返回String }, 3, 500L); Integer count RetryTemplate.retry(() - { return statisticsService.getUserCount(); // 返回Integer }, 2, 1000L);这里体现了一个很重要的设计不把重试逻辑塞进具体业务方法而是抽成泛型模板由调用方决定执行逻辑和返回类型。如果想进一步优化可以增加指数退避每次sleep的时间乘以一个衰减系数但基础版已经能覆盖大部分场景。5.3 注意事项重试模板的隐藏细节第一个细节是lambda表达式对类型推断的影响。如果调用方写成RetryTemplate.retry(() - getUser(), 3, 500L)编译器需要根据赋值语句左边的类型推断T。一旦上下文不确定比如直接把结果丢进一个Object变量推断就会失败。这时候需要显式指定类型参数String user RetryTemplate.Stringretry(() - getUser(), 3, 500L);第二个细节是捕获异常的边界。Callable.call()允许抛Exception所以retry方法里catch Exception是合理的。但如果业务方法抛的是Error比如StackOverflowError这里不会兜住重试也不会生效因为Error不属于Exception体系。真实项目中重试一般只针对可恢复的异常这一点要在注释里写清楚。第三个细节是最容易忽略的如果action本身需要对上一次的异常做判断来决定是否重试模板的签名就不够用了。比如下游返回特定错误码才值得重试其他错误直接抛出。这种场景建议给retry方法增加一个Predicate 参数public static T T retry(CallableT action, int maxAttempts, long retryIntervalMs, PredicateException shouldRetry) { // 每次catch后先判断 shouldRetry.test(e)false 则直接抛出 // 逻辑类似只是把 if (attempt maxAttempts) 放在判断之后 }翻到笔记最后一页日期还是2月2日。那天我在空白处画了一个小箭头从List 指向List? extends T旁边只写了一行字读用extends写用super记不住就用PECS。现在回头看花一整天把泛型理清楚是值当的。摸清这套规则之后再回看那些满屏Object和强转的老代码你会特别想把它们全部改掉。改的过程中你会发现泛型带来的不只是编译期的安全感还有读代码时的清爽——类型信息本身就在签名里根本不需要翻方法体。个人体会是与其被报错信息追着走不如花半天把这套机制彻底搞清楚后面每写一行泛型代码都会顺手很多。