泛型拾遗

导读与全景图

Java 泛型在源码层提供编译期类型安全，在字节码层通过类型擦除（type erasure）向后兼容 Java 1.4 及更早的字节码，在 API 设计层用通配符（wildcard）补全协变体系。理解"擦除"和"协变"两点，所有零散规则都能被推导出来——本文围绕这两条主线展开。

知识地图

下图概括了全文的结构与各部分之间的依赖关系。类型擦除是理解后续所有限制（不能 new T()、不能 instanceof T、不能创建泛型数组）的钥匙；通配符则是理解所有 API 设计模式（PECS、捕获、递归边界）的钥匙。

历史背景：擦除是多方诉求塑形的妥协

日常说"Java 选擦除是为了向后兼容"是一句过于简化的概括。Brian Goetz 在 OpenJDK Valhalla 设计笔记 In Defense of Erasure 里反复强调：擦除在 2004 年是"the sensible and pragmatic choice"，但这个选择背后牵涉的约束远比"兼容老代码"一句话复杂。本节拆解这个妥协的真实形状。

"向后兼容"的四个独立维度

Java 平台规范里"向后兼容"不是一个概念，而是四个互不蕴含的独立维度。满足任意三个不等于满足第四个。

维度	含义	GJ 论文里的实现机制
源码兼容（source compatibility）	老的合法 Java 源码在新编译器下仍然合法且语义不变	每个合法 Java 程序仍是合法 GJ 程序
二进制兼容（binary compatibility）	老 .class 文件在新的 JVM/类库下能继续链接运行，不需要重编译	JLS §13 的核心约束
向后兼容（backward compatibility，旧→新）	legacy 代码能调用 generified 后的类库	通过 raw types 实现
向前兼容（forward compatibility，新→旧）	新的 generic 代码能调用还没 generify 的 legacy 类库	通过 retrofitting 实现

GJ 原始论文（Bracha, Odersky, Stoutamire, Wadler, Making the future safe for the past, OOPSLA 1998）里有一句关键论断：“Roughly speaking, GJ achieves backward compatibility through raw types, and forward compatibility through retrofitting.” 同时满足这四个维度是 GJ 击败其他方案的核心竞争力。

Java 平台的两块基石：为什么 flag day 不可能

为什么 Java 对兼容性如此执着？答案在 Java 的两个底层设计里：

分离编译（Separate Compilation）——每个 .java 文件独立编译成 .class，而不是把一组源码编译成一个整体产物。C 编译时依赖的 D，运行时可以被替换成不同版本的 D，只要 D 没做"二进制不兼容"的修改。

动态链接（Dynamic Linkage）——C 调用 D.m(int) 时，class 文件里只记录方法名和描述符 (I)V。运行时 JVM 在 D 里按这个符号查找，找到就链接。这就是"扔一个新 JAR 进 classpath 就升级"的底层依据。

这两条叠加的后果是：Java 生态里数以亿计的 class 文件以二进制形态存在，源码不一定拿得到，更不可能全部重编译。Brian Goetz 原话：

At the time generics were introduced into Java, there was already a lot of Java code in the world, and their classfiles were full of references to APIs like java.util.ArrayList. If we couldn’t generify these APIs compatibly, then we would have to have written new APIs to replace them, and worse, all of the client code of the old APIs would be stuck with an untenable choice — either stay on 1.4 forever, or rewrite them to use the new APIs, simultaneously.

引入泛型如果要求"flag day"——全世界的 Java 代码同一天升级——基本等同于让 Java 生态自杀。

当时牵涉的多方诉求

2001 年 JSR 14 专家组名单本身就是各方利益的缩影：

专家	机构	代表的利益方
Gilad Bracha, David Stoutamire	Sun Microsystems	平台提供方、JVM 规范方
Norman Cohen	IBM	第二大 JVM 厂商（IBM J9）
Christian Kemper	Inprise（Borland）	IDE/工具厂商（JBuilder）
Steve Marx	WebGain	IDE 厂商（VisualCafé）
Martin Odersky	EPFL（后创 Scala）	学术界、Pizza/GJ 编译器作者
Sven-Eric Panitz	Software AG	企业软件厂商
Kresten Thorup	Aarhus University	学术界（前 Sun JIT 团队）
Philip Wadler	Lucent	函数式编程学派、Haskell 设计者之一

这只是规范层。实际诉求来自更广泛的 7 个利益方，每一方都有否决权：

1. 平台提供方（Sun）：不能让 Java 5 变成"第二个 Java"——必须看起来是一次平滑升级
2. 其他 JVM 厂商（IBM、BEA、Apple、Oracle）：不能要求他们重写 JVM 规范和实现
3. 核心类库（java.util、java.lang.reflect）：必须能 generify，但 class 文件层面的方法描述符不能变
4. 第三方类库（Apache Commons、Log4j、Spring、Hibernate 前身）：用户不会一夜升级
5. 企业应用代码：90 年代末积累的数千万行 Java 代码，源码可能已经丢失或无法重编译
6. JVM 上的其他语言（Scala、Groovy、JRuby、Clojure 前身）：编译器输出要能和 Java 互操作
7. 工具链（IDE、字节码操作库 ASM、构建工具 Ant）：读 class 文件格式，class 文件格式不能破坏性变化

备选方案的代价对比

学术界和工业界当时提出了至少 5 条路径。GJ 原始论文逐一对比：

方案	核心机制	代价	结论
异质翻译（C++ 模板式）	为每个类型参数实例化独立代码	代码膨胀、跨编译单元 ABI 共享困难、与 JVM 安全模型冲突	淘汰
具化泛型（C# 2.0 式）	更新 CLR/JVM 规范，运行时保留类型信息	需要重写所有 JVM 实现、破坏二进制兼容	C# 当时代码量小可以走，Java 不能
NextGen（Cartwright & Steele 1998）	GJ 的超集，保留运行时类型参数	只有向后兼容，没有向前兼容——新代码不能直接调 legacy 库	被 GJ 击败
运行时类型检查（数组协变式）	每次 add/赋值做运行时检查	JVM 每次字段写入都做子类型检查；可判定性存疑	性能/正确性风险太大
GJ（擦除 + raw types + retrofitting）	编译期检查、运行时擦除、四向兼容	运行时拿不到类型参数，派生所有限制	被采纳

C# 的对比最能说明问题。Brian Goetz 在 In Defense of Erasure 里直接点出：

C# made the opposite choice — to update their VM, and invalidate all the user code that … They could do this at the time because there was comparatively little C# code in the world; Java didn’t have this option at the time.

C# 2.0 (2005) 引入泛型时，微软选择"更新 CLR + 推出新的 System.Collections.Generic 命名空间"——旧的 System.Collections 保留，新的并行存在。C# 当时代码量小可以接受这种"双轨制"，Java 不行。

擦除作为最大公约数

把所有约束叠加，擦除不是"偷懒"或"次优的妥协"——它是多个硬约束的交集：

Neal Gafter（Java 5 泛型共同设计者）在 2006 年的博客 Reified Generics for Java 里承认这个选择带来的限制：

Generics are implemented using erasure as a response to the design requirement that they support migration compatibility: it should be possible to add generic type parameters to existing classes without breaking source or binary compatibility with existing clients.

Brian Goetz 的总结更直接：

The common misconception that erasure is “a dirty hack” generally stems from a lack of awareness of what the true costs of the alternative would have been, both in engineering effort, time to market, delivery risk, performance, ecosystem impact, and programmer convenience given the large volume of Java code already written and the diverse ecosystem of both JVM implementations and languages running on the JVM.

三种泛型实现的横向对比

下图概括了 C++、C#、Java 三种实现路径的取舍差异：

Project Valhalla 的回响

擦除的代价是真实的，OpenJDK 的 Valhalla 项目（JEP 401：value classes，JEP 390：Warnings for Value-Based Classes 等）正在重新审视这个问题。Brian Goetz 在设计笔记里反复强调：2004 年选擦除是对的，但当时的约束现在有一部分仍然存在。Valhalla 不能简单"切换到具化"——它要在保持现有兼容性的前提下，增量引入 value type 和更彻底的泛型改革（specialized generics / primitive generics）。这个项目的艰难恰恰反证了 2004 年的妥协有多深的多方根基。本文所有结论以 Java 8-21 当前规范为准。

基本概念与语法

三个核心术语

Java 泛型文献里术语使用并不完全统一，先做一次对齐。JLS §4.4 把类型参数定义为 TypeVariable，本文按以下三个术语划分：

• Type Parameter（类型形参）：泛型类、接口或方法声明时引入的标识符。class Box<T> 中的 T、<E> void addAll(Collection<E> items) 中的 E 都是 Type Parameter。
• Type Variable（类型变量）：Type Parameter 在类/方法体内的引用。class Box<T> { T value; } 中字段 value 的类型 T 是一个 Type Variable。日常写作中"类型参数"和"类型变量"经常互换使用，但严格来说前者是声明、后者是引用。Class.getTypeParameters() 返回的就是 TypeVariable<?> 数组（java.lang.reflect.TypeVariable，见 JLS §4.4）。
• Type Argument（类型实参）：在使用泛型类型时传入的具体类型。Box<Integer> 中的 Integer、List<String> 中的 String 都是 Type Argument。List<String> 里的 String 不是 Type Parameter——这是一个常见的误称，《Java 核心技术》的中译本偶尔也会犯这个错。

import java.util.ArrayList;
import java.util.Collection;
import java.util.List;
import java.util.function.Function;

// Type Parameter T 在类声明中引入
public class Box<T> {
    // T 作为 Type Variable 出现在字段声明里
    private T value;

    // T 作为 Type Variable 出现在方法签名里
    public T getValue() {
        return value;
    }

    // E 是新的 Type Parameter，作用于这个方法
    // T 在返回类型 Function<E, T> 中作为 Type Variable 出现
    public <E> void addAll(Collection<E> items, Function<E, T> converter) {
        for (E item : items) {
            // 这里 value 是 T 的引用，item 是 E 的引用
        }
    }
}

class TypeArgumentDemo {
    void use() {
        // String 是 Type Argument
        Box<String> stringBox = new Box<>();
        // Integer 是 Type Argument
        List<Integer> numbers = new ArrayList<>();
    }
}

声明位置

泛型类型参数的声明位置由语法严格规定：

• 泛型类/接口：类型参数跟在类名后，如 class Pair<T, U>、interface Comparable<T>。
• 泛型方法：类型参数放在修饰符（public static final）和返回类型之间，如 public static <T> List<T> emptyList()。

Java 把泛型方法的类型参数前置（而不是像 C++ 那样允许 g<a, b>(c)），是为了避免解析歧义。在 C++ 里 f(g<a, b>(c)) 有两种读法：把 g<a, b>(c) 的返回值传给 f；或者把 g<a 和 b>(c) 作为两个实参传给 f。Java 把类型见证前置就规避了这个问题。

Generic Type / Parameterized Type / Raw Type

这三个概念描述同一个泛型类型在不同阶段的形态：

概念	形态	例子
Generic Type	声明态，带 Type Parameter	List<T>、Map<K, V>
Parameterized Type	实例化态，传入 Type Argument	List<String>、Map<String, Integer>
Raw Type	擦除态/legacy 态，不带 Type Argument	List、Map

JLS §4.5 定义 Parameterized Type，JLS §4.8 定义 Raw Type。Raw Type 的存在纯粹是为了向后兼容，使用时会跳过泛型类型检查，编译器会发 unchecked warning。

类型擦除——理解一切的钥匙

类型擦除是 Java 泛型实现的核心机制。本章聚焦擦除的技术机制——规则、字节码证据、桥接方法的生成；擦除作为多方诉求最大公约数的历史与设计动机已在 Part 0 详述。

擦除的规则

JLS §4.6 定义了擦除规则。擦除的本质是：编译器在编译期完成所有类型检查，编译后把 Type Variable 替换为它的第一个边界（无边界时为 Object），并在必要位置插入类型转换指令保证运行时语义正确。

源码中的类型	擦除后的类型	说明
T（无边界）	Object	最常见的情况
T extends Number	Number	替换为第一个边界
T extends Comparable<T> & Serializable	Comparable<T>	多边界取第一个
List<String>	List	参数化类型擦除为 raw type
List<String>[]	List[]	泛型数组擦除

多边界的擦除有个细节：擦除到第一个边界，但字节码的 Signature 属性（JLS §13.1、JVM §4.7.9.1）会保留完整的泛型签名，反射 API 可以读取这个 Signature 拿回部分类型信息——这是后文"泛型与反射"的基础。

擦除后的代码长什么样

用一个经典的 Pair 类演示。源码：

public class Pair<T> {
    private T first;
    private T second;

    public Pair() {
        first = null;
        second = null;
    }

    public Pair(T first, T second) {
        this.first = first;
        this.second = second;
    }

    public T getFirst() {
        return first;
    }

    public T getSecond() {
        return second;
    }

    public void setFirst(T newValue) {
        first = newValue;
    }

    public void setSecond(T newValue) {
        second = newValue;
    }
}

擦除后等价于：

public class Pair {
    private Object first;
    private Object second;

    public Pair() {
        first = null;
        second = null;
    }

    public Pair(Object first, Object second) {
        this.first = first;
        this.second = second;
    }

    public Object getFirst() {
        return first;
    }

    public Object getSecond() {
        return second;
    }

    public void setFirst(Object newValue) {
        first = newValue;
    }

    public void setSecond(Object newValue) {
        second = newValue;
    }
}

所有 T 都被替换成 Object。这意味 Pair<String>、Pair<Integer>、Pair<Employee> 在运行时共享同一个 Pair.class，无法通过反射区分。

桥接方法的生成

擦除会带来一个看起来矛盾的问题：子类覆写父类泛型方法时，源码层面签名一致，但擦除后签名不同——多态怎么维持？

考虑一个派生子类：

import java.time.LocalDate;

class DateInterval extends Pair<LocalDate> {
    @Override
    public void setSecond(LocalDate second) {
        if (second.compareTo(getFirst()) > 0) {
            super.setSecond(second);
        }
    }
}

源码层面，DateInterval.setSecond(LocalDate) 看起来覆写了 Pair.setSecond(T)。但擦除后 Pair.setSecond 的签名是 setSecond(Object)，而 DateInterval.setSecond 的签名是 setSecond(LocalDate)——签名不一致，按字节码规则这不算 override，而是 overload。如果调用方持有 Pair<LocalDate> 引用（运行时擦除为 Pair），调 setSecond 会按 setSecond(Object) 分派，并不会命中 DateInterval.setSecond(LocalDate)，多态失效。

编译器为了修补这个漏洞，自动合成一个 bridge method（桥接方法）：

// 编译器合成，源码里看不到
public void setSecond(Object second) {
    setSecond((LocalDate) second);
}

桥接方法的签名与父类擦除后的签名一致，方法体把参数强制转型为子类实际类型后转发。javap -c -p DateInterval.class 可以看到这两个方法并存：

public void setSecond(java.time.LocalDate);
    Code:
       0: aload_0
       1: invokevirtual #16  // Method getFirst:()Ljava/lang/Object;
       4: checkcast     #17  // class java/time/chrono/ChronoLocalDate
       7: aload_1
       8: invokevirtual #18  // Method java/time/LocalDate.compareTo:(Ljava/time/chrono/ChronoLocalDate;)I
      11: ifle          19
      14: aload_0
      15: aload_1
      16: invokespecial #19  // Method Pair.setSecond:(Ljava/lang/Object;)V
      19: return

public void setSecond(java.lang.Object);
    Code:
       0: aload_0
       1: aload_1
       2: checkcast     #20  // class java/time/LocalDate
       5: invokevirtual #21  // Method setSecond:(Ljava/time/LocalDate;)V
       8: return

第二个方法 setSecond(java.lang.Object) 就是合成的桥接方法，它的字节码里有一个 checkcast 指令把 Object 转成 LocalDate，再转发给真正的方法。

桥接方法的特征

根据 JLS §13.1 和 JVM §4.6，桥接方法具有以下特征：

1. 生成时机：当子类覆写父类泛型方法，且类型擦除导致方法签名不一致时，编译器自动插入。
2. 字节码标志：方法修饰符带 ACC_BRIDGE（0x0040）和 ACC_SYNTHETIC（0x1000）。
3. 方法体：仅包含 checkcast 和对实际方法的转发调用，不含业务逻辑。

三种典型场景

场景一：泛型父类 + 具体子类

上面的 Pair<LocalDate> 和 DateInterval 就是这一类。子类持有具体类型实参，覆写时需要桥接。

场景二：泛型接口 + 实现类

import java.util.Comparator;

public class StringComparator implements Comparator<String> {
    @Override
    public int compare(String first, String second) {
        return first.compareTo(second);
    }

    // 编译器合成的桥接方法（反编译可见）：
    // public int compare(Object first, Object second) {
    //     return compare((String) first, (String) second);
    // }
}

Comparator<T> 的 compare(T, T) 擦除后是 compare(Object, Object)，所以 StringComparator 需要桥接方法保持多态。

场景三：协变返回类型

class Employee implements Cloneable {
    @Override
    public Employee clone() {
        // 实际方法，返回协变类型 Employee
        // ...克隆逻辑...
        return new Employee();
    }

    // 编译器合成的桥接方法：
    // public Object clone() {
    //     return clone();  // 转发到返回 Employee 的版本
    // }
}

Java 5 引入协变返回类型（covariant return type）后，子类方法的返回类型可以是父类方法返回类型的子类型。擦除机制下编译器同样用桥接方法处理。

验证桥接方法

import java.lang.reflect.Method;

public class BridgeMethodDetection {
    public static void main(String[] args) throws NoSuchMethodException {
        // isBridge() 判定
        Method bridge = DateInterval.class.getMethod("setSecond", Object.class);
        System.out.println(bridge.isBridge());  // true

        Method real = DateInterval.class.getMethod("setSecond", LocalDate.class);
        System.out.println(real.isBridge());    // false
    }
}

也可以直接 javap -c -p DateInterval.class 看字节码，桥接方法的修饰符里包含 ACC_BRIDGE（在某些 javap 版本里显示为 bridge 关键字）。

下图展示桥接方法的生成与调用流程：

擦除的能力与代价

擦除带来的能力：

1. 向后兼容：泛型代码与 Java 1.4 字节码互操作。
2. 运行时无泛型开销：所有 Pair<T> 共享同一个 Pair.class，没有 C++ 模板那样的代码膨胀。
3. 多态仍生效：通过桥接方法维持子类覆写语义。

擦除的代价：

1. 运行时拿不到泛型参数：不能 new T()、不能 instanceof T、不能 T.class、不能创建 T[]。
2. 方法签名冲突：process(List<String>) 和 process(List<Integer>) 擦除后都是 process(List)，不能共存。
3. 基本类型不能作 Type Argument：List<int> 非法，因为擦除到 Object，而 int 不是 Object。

🔑 模式提炼：擦除即退化

擦除的本质是编译期类型信息在运行时退化为边界类型。所有泛型限制——不能 new T()、不能 instanceof T、不能创建泛型数组、不能 catch(T)——都来自同一个根因：这些操作都需要运行时的具体类型信息，而擦除恰恰移除了这些信息。理解了这一点，就能从"记忆一堆零散规则"升级到"从一个根因推导所有规则"。

边界——让类型参数"能用上方法"

类型参数默认可以被替换成任意类型（擦除到 Object）。但很多场景需要约束：希望 T 至少是某个类型，这样才能在 T 上调用那个类型的方法。这就是边界（bound）。

JLS §4.4 定义边界语法 T extends Type，这里的 extends 是 subtype 的近似，统一了类继承和接口实现，并不是"扩展"的意思。

单一边界

最常见的形态：

public class Interval<T extends Comparable<T>> {
    private T lower;
    private T upper;

    public boolean contains(T value) {
        return lower.compareTo(value) <= 0 && value.compareTo(upper) <= 0;
    }
}

如果不写 extends Comparable<T>，T 擦除到 Object，编译器不允许在 T 上调用 compareTo——因为 Object 没有这个方法。加上边界后 T 擦除到 Comparable<T>，编译器就能在 T 上调用 Comparable 接口的方法。

交叉类型（Intersection Types）

Type Parameter 可以同时指定多个边界，语法为 T extends A & B & C，用 ampersand（&）分隔。这就是交叉类型。规则（JLS §4.4、§4.9）：

• 最多一个类边界，且必须放在第一位。
• 接口边界可以有多个。
• 擦除后的类型为第一个边界。

import java.io.Serializable;

// T 必须同时实现 Comparable<T> 和 Serializable
// 擦除到 Comparable<T>（第一个边界）
public class SerializablePair<T extends Comparable<T> & Serializable> {
    private T first;
    private T second;

    public SerializablePair(T first, T second) {
        this.first = first;
        this.second = second;
    }

    public T max() {
        return first.compareTo(second) >= 0 ? first : second;
    }
}

当 T 在某些位置需要作为 Serializable 使用时，编译器会自动插入 checkcast 指令——擦除只保留第一个边界，但类型检查仍在编译期完成。

Lambda 与交叉类型

交叉类型在 Lambda 表达式中有特殊用途——Lambda 可以同时被转换为多个接口类型：

import java.io.Serializable;
import java.util.function.Predicate;

// Lambda 同时满足 Predicate<String> 和 Serializable
// 序列化框架可以把这个 Lambda 写入磁盘后恢复
Predicate<String> predicate = (Predicate<String> & Serializable) s -> s.length() > 0;

Serializable 是 marker 接口（无方法），但编译器需要显式的交叉类型 cast 才能为 Lambda 生成可序列化的代理类。这个技巧在需要把 Lambda 状态持久化或跨网络传输时有用。

递归类型边界

递归类型边界（Recursive Type Bound）是指类型参数以自身为边界的模式，最典型的形式是 <T extends Comparable<T>>：

import java.util.List;

public class MaxFinder {
    // T 必须能与自身类型的对象比较
    public static <T extends Comparable<T>> T findMax(List<T> list) {
        T max = list.get(0);
        for (T element : list) {
            if (element.compareTo(max) > 0) {
                max = element;
            }
        }
        return max;
    }
}

Comparable<T> 的 compareTo(T other) 方法接受 T 类型参数。T extends Comparable<T> 保证 T 的实例可以与其他 T 实例互相比较。这种约束让 findMax 的类型签名表达力非常精确——它只接受"自比较类型"的列表。

自限定类型与 Enum 的经典案例

自限定类型（Self-bounded Types）是递归边界的一种特殊形式，常见于基类定义中：基类的 Type Parameter 被要求是基类自身的某个子类型。

JDK 最经典的例子是 java.lang.Enum：

// JDK 源码（简化）
public abstract class Enum<E extends Enum<E>>
        implements Comparable<E>, Serializable {

    public final int compareTo(E other) {
        // ...
    }
}

这个声明看起来很绕：E extends Enum<E>。拆开读：

• E 是一个 Type Parameter。
• E 必须是 Enum<E> 的子类型。
• Enum<E> 自身的 Type Parameter 又是 E。

定义一个具体枚举：

public enum Color {
    RED, GREEN, BLUE;
}

编译器合成的等价代码大致是：

public final class Color extends Enum<Color> {
    public static final Color RED = new Color("RED", 0);
    public static final Color GREEN = new Color("GREEN", 1);
    public static final Color BLUE = new Color("BLUE", 2);

    private Color(String name, int ordinal) {
        super(name, ordinal);
    }
}

Color extends Enum<Color> 把 E 替换为 Color。这意味着：

• Enum.compareTo 接受 Color 类型参数，不会出现"拿 Color 和其他枚举比较"这种错误调用。
• 枚举类型之间是强类型隔离的——Color.compareTo(Weekday) 直接编译错误。

自限定让父类方法返回子类型

Enum 之外，自限定模式还广泛用于 fluent API 和 Builder 模式，目的是让父类方法返回子类型。Spring HATEOAS 的 RepresentationModel 就是典型：

// 不使用自限定：父类方法返回父类型，fluent 链断在子类
public class NaiveResourceModel {
    public NaiveResourceModel addLink(String rel, String href) {
        // ...
        return this;
    }
}

public class NaiveUserModel extends NaiveResourceModel {
    public String getUsername() { return "alice"; }
}

class NaiveClient {
    void use() {
        NaiveUserModel user = new NaiveUserModel();
        // 返回类型是 NaiveResourceModel，fluent 链断了
        NaiveResourceModel chained = user.addLink("self", "/users/123");
        // 编译错误：NaiveResourceModel 没有 getUsername()
        // String name = chained.getUsername();
    }
}

addLink 是父类方法，返回父类型，调用后子类型信息丢失。用自限定解决：

public class RepresentationModel<T extends RepresentationModel<? extends T>> {

    @SuppressWarnings("unchecked")
    private T self() {
        return (T) this;
    }

    public T addLink(String rel, String href) {
        // ...添加链接的逻辑...
        return self();
    }
}

public class UserModel extends RepresentationModel<UserModel> {
    public String getUsername() {
        return "alice";
    }
}

class SelfTypedClient {
    void use() {
        UserModel user = new UserModel();
        // 返回类型仍是 UserModel，fluent 链保持
        UserModel chained = user.addLink("self", "/users/123");
        String name = chained.getUsername();
    }
}

UserModel extends RepresentationModel<UserModel> 把 T 替换为 UserModel，addLink 返回 T 即 UserModel。self() 方法做了一次"父转子"的 unchecked cast——这是自限定模式的固定成本。

Comparable 的三种形式对比

Java 标准库里 Comparable 与泛型的组合有三种典型形态，区分它们能消除大量 API 设计时的困惑。

形态一：<T extends Comparable<T>>——只能与同类型比较

// T 必须能与同类型 T 比较
public static <T extends Comparable<T>> T findMax(List<T> list) {
    // ...
}

适合 String、Integer 这类"实现 Comparable<T>，参数就是自己"的类型。

形态二：<T extends Comparable<? super T>>——能与父类型比较

// T 可以与 T 的任意父类型比较
public static <T extends Comparable<? super T>> T findMax(List<? extends T> list) {
    // ...
}

适合 LocalDate 这种场景：LocalDate implements Comparable<ChronoLocalDate>，参数是 ChronoLocalDate（LocalDate 的父类型）。如果用形态一 Comparable<T>，findMax(List<LocalDate>) 会编译错误，因为 LocalDate 并没有 implements Comparable<LocalDate>。改用 Comparable<? super T> 即可。

这是 Effective Java Item 31 的经典案例，PECS 原则在边界声明上的应用——“T 的比较器消费 T 的实例”。

形态三：RepresentationModel<T extends RepresentationModel<? extends T>>——方法返回子类型

public class RepresentationModel<T extends RepresentationModel<? extends T>> {
    public T addLink(String rel, String href) { /* ... */ }
}

不是为了让 T 能"比较"，而是为了让父类方法能返回子类类型。形态一、形态二约束的是 T 上可调用的方法；形态三约束的是父类方法的返回值类型。

🔑 模式提炼：类型自约束

递归边界和自限定类型的核心思想是"类型参数约束自身"。当需要在基类中定义返回子类型的方法（Builder 链式调用、compareTo 比较、fluent API）时，使用 <T extends Base<T>> 模式。Enum<E extends Enum<E>> 是 JDK 中最著名的应用，Spring HATEOAS 的 RepresentationModel 是另一个标杆。这一模式需要一处 @SuppressWarnings("unchecked") 做父到子的强转——这是自引用结构不可避免的成本。

通配符与协变体系

类型擦除解决了向后兼容问题，但带来了一个新问题：泛型默认是不变的（invariant），而现实中很多 API 需要协变（读取）或逆变（写入）的能力。通配符就是 Java 给出的补全方案。

为什么泛型是不变的

List<String> 不是 List<Object> 的子类型——尽管 String 是 Object 的子类型。这看起来反直觉，但只有这样才能保证类型安全：

import java.util.ArrayList;
import java.util.List;

class InvarianceBreak {
    void unsafe() {
        // 假设这行合法（实际编译错误：incompatible types）
        // List<Object> objects = new ArrayList<String>();
        // objects.add(42);              // 往 String 列表里塞了 Integer
        // String s = ((List<String>) objects).get(0);  // ClassCastException
    }
}

如果允许 List<Object> = ArrayList<String>，下一步 add(42) 就会把 Integer 塞进 String 列表——类型系统形同虚设。Java 把这种错误从运行时提前到编译时：List<String> 和 List<Object> 之间没有继承关系。

但有些场景确实需要受限的协变或逆变——只读场景下让 List<String> 能被当作 List<? extends Object> 读；只写场景下让 List<Object> 能被当作 List<? super String> 写。通配符就是干这个的。

三种通配符

形式	名称	含义	方向
?	无界通配符	某个未知类型	中性
? extends T	上界通配符	T 或 T 的子类型	协变（covariant）
? super T	下界通配符	T 或 T 的父类型	逆变（contravariant）

? 本质上是 ? extends Object 的简写。

关键认知：? 不是 Type Parameter，也不是 Type Argument 的占位变量名——它是 wildcard。不能用 ? 作为变量类型：

class WildcardIsNotType {
    void invalid() {
        // ? a = ...;  // 编译错误：? 不能作为变量类型
    }
}

协变、逆变、不变对比

三种变型对应三种使用场景：

• 需要同时读和写 → 用精确类型 T（不变）
• 只读（生产者） → 用 ? extends T（协变）
• 只写（消费者） → 用 ? super T（逆变）

PECS 原则

“Producer Extends, Consumer Super”——这是 Joshua Bloch 在 Effective Java Item 31 提出的助记符。

• 如果一个集合是生产者（数据源，被读取），用 <? extends T>
• 如果一个集合是消费者（数据汇，被写入），用 <? super T>

import java.util.ArrayList;
import java.util.Collection;
import java.util.List;

public class PecsExample {
    // source 是生产者：只读取数据，用 ? extends T
    // destination 是消费者：只写入数据，用 ? super T
    public static <T> void copy(List<? extends T> source,
                                List<? super T> destination) {
        for (T item : source) {
            destination.add(item);
        }
    }

    public static void main(String[] args) {
        List<Integer> source = new ArrayList<>(List.of(1, 2, 3));
        List<Number> destination = new ArrayList<>();
        copy(source, destination);
    }
}

为什么 extends 只能读不能写

import java.util.Collection;

class ExtendsReadOnly {
    void unsafe(Collection<? extends Number> nums) {
        // 编译错误：nums 可能是 Collection<Integer>，也可能是 Collection<Double>
        // nums.add(1);
        // nums.add(2.0);

        // 但读取是安全的：nums 里至少是 Number
        Number first = ((List<? extends Number>) nums).iterator().next();
    }
}

Collection<? extends Number> 表示"Number 某个子类型的集合"，编译器无法确定具体是哪个子类型，所以禁止 add（万一塞错类型）。但读出来一定是 Number——这是类型安全的。

为什么 super 只能写不能读（精确类型）

import java.util.Collection;
import java.util.List;

class SuperWriteOnly {
    void safeWrite(List<? super Integer> nums) {
        // 合法：Integer 一定能被 List<Integer>、List<Number>、List<Object> 接受
        nums.add(1);
        nums.add(2);

        // 读出来只能当 Object——List 可能是 List<Object>
        Object first = nums.get(0);

        // 编译错误：无法保证元素是 Integer
        // Integer i = nums.get(0);
    }
}

List<? super Integer> 表示"Integer 某个父类型的 List"，可能是 List<Integer>、List<Number> 或 List<Object>。写入 Integer 一定安全；但读出来不知道具体是什么——只能当 Object。

🔑 模式提炼：读写分离边界

PECS 的本质是泛型的读写分离。不变性保证了类型安全但灵活性差；通配符通过限制读写能力换取协变/逆变能力：? extends T 牺牲写入换取协变（安全读取），? super T 牺牲精确读取换取逆变（安全写入）。设计 API 时，参数如果只读就用 extends，只写就用 super，既读又写就用精确类型 T。

通配符的继承关系

通配符类型本身也构成一棵继承树。理解这棵树能帮助判断哪些赋值是合法的：

List<?> (根节点)
├── List<? extends Number>     // 子类型范围：Number 或其子类
│   ├── List<Number>
│   ├── List<Integer>
│   └── List<Double>
└── List<? super Integer>      // 子类型范围：Integer 或其父类
    ├── List<Integer>
    ├── List<Number>
    └── List<Object>

反直觉的两点：

1. Pair<? extends Employee> 的子类型（不是父类型）可以是 Pair<Employee> 和 Pair<Manager>。
2. Pair<? super Employee> 的子类型（不是父类型）可以是 Pair<Employee> 和 Pair<Object>。

通配符允许泛型类的继承树在泛型层面出现，而普通泛型则只允许泛型类的继承树在外部类的层面出现——这是通配符独有的灵活性。

通配符捕获

通配符 ? 不能作为变量类型，所以不能直接对 <?> 类型的集合做写操作。但实际开发中确实需要：拿到一个 List<?>，想交换它的两个元素。直接写 swap 会编译失败：

import java.util.List;

class NaiveSwap {
    // 编译错误：? 不能作为变量类型
    // void swap(List<?> list, int i, int j) {
    //     ? temp = list.get(i);   // 错误
    //     list.set(i, list.get(j));
    //     list.set(j, temp);
    // }
}

通配符捕获的解法：写一个私有的泛型辅助方法，让 Type Parameter T 捕获通配符 ?。

import java.util.List;

public class WildcardCapture {

    // 对外暴露的通配符方法
    public static void swap(List<?> list, int i, int j) {
        swapHelper(list, i, j);
    }

    // 私有泛型辅助方法：T 捕获了 ?
    private static <T> void swapHelper(List<T> list, int i, int j) {
        T temp = list.get(i);
        list.set(i, list.get(j));
        list.set(j, temp);
    }
}

调用 swap(list, i, j) 时，编译器推断 T 绑定到 list 的具体通配符类型——这就是"通配符捕获"。T 不知道 ? 的具体类型，但知道它是某个确定类型，于是可以在辅助方法内部自由读写。

嵌套通配符无法捕获

通配符捕获只在单层 <?> 上生效。多层嵌套时，编译器拒绝捕获——因为内层 ? 可能代表不同的具体类型：

import java.util.List;

public class NestedWildcardNotCapturable {

    void outer(List<List<?>> nested) {
        // 编译错误：无法把 List<List<?>> 捕获成 List<List<T>>
        // helper(nested);
    }

    private <T> void helper(List<List<T>> nested) {
        nested.set(0, nested.get(0));
    }
}

报错信息形如：mismatched types: required List<List<T>> found List<List<?>>; incompatible equality constraint: T and ?。

原因：List<List<?>> 表示"元素是 List<?> 的 List"，里面每个内层 List 可能持有不同类型——比如第一个是 List<String>、第二个是 List<Integer>。编译器无法把它们绑定到同一个 T。

PECS 实战：Comparable 的下界通配符

回到 Part 3 的 Comparable 例子。LocalDate implements Comparable<ChronoLocalDate>，注意参数是 ChronoLocalDate（LocalDate 的父接口），不是 LocalDate 自己。

如果要让 findMax 接受 List<LocalDate>，签名必须写成：

import java.util.List;

public class MaxFinder {
    // T extends Comparable<? super T>——让 T 能与父类型比较
    public static <T extends Comparable<? super T>> T findMax(List<T> list) {
        T max = list.get(0);
        for (T element : list) {
            if (element.compareTo(max) > 0) {
                max = element;
            }
        }
        return max;
    }
}

如果写成 <T extends Comparable<T>>，findMax(List<LocalDate>) 会编译错误——因为 LocalDate 没有 implements Comparable<LocalDate>。改用 Comparable<? super T> 接受"参数是 T 或 T 父类型的 Comparable"，就能匹配 Comparable<ChronoLocalDate>。

这个签名是标准库和工具库的通用写法。java.util.Collections.sort 签名就是：

public static <T extends Comparable<? super T>> void sort(List<T> list)

ArrayList 的 removeIf 同理：

// java.util.ArrayList#removeIf
default boolean removeIf(Predicate<? super E> filter)

Predicate 消费 E 的实例，所以用 ? super E——这样传入 Predicate<Object> 也能用，给调用方更大的灵活性。

泛型不能做什么

把所有"不能"按根因分类，可以避免死记硬背。Java 泛型的限制都来自五个根因：

1. 因为擦除：运行时拿不到类型参数信息
2. 因为数组具化：数组在运行时知道元素类型，泛型不知道
3. 因为异常机制：异常类的继承关系和 try-catch 语法要求编译期就知道具体类型
4. 因为静态上下文：静态成员属于类级别，类还没被参数化时静态成员无法引用类型参数
5. 因为签名冲突：擦除后方法签名可能撞车

因为擦除：运行时拿不到类型参数

不能 new T()

class CannotNewT<T> {
    // 编译错误：T 在运行时擦除到 Object，无法调用 T 的构造器
    // T value = new T();

    // 但 T value; 是合法的——声明不需要类型信息
    private T value;
}

变通一（Java 8+）：传 Supplier<T>，构造器的方法引用就是 Supplier<T>。

import java.util.function.Supplier;
import java.util.HashMap;
import java.util.Map;
import java.util.function.Function;

class GenericFactory {
    // 用 Supplier<T> 替代 new T()
    public static <T> Map<String, T> createMap(Supplier<T> factory) {
        Map<String, T> map = new HashMap<>();
        map.put("default", factory.get());
        return map;
    }

    public static void main(String[] args) {
        // StringBuilder::new 是 Supplier<StringBuilder>
        Map<String, StringBuilder> map = createMap(StringBuilder::new);
    }
}

变通二（Java 5+）：传 Class<T>，用反射创建实例。

import java.lang.reflect.InvocationTargetException;

class ReflectiveFactory {
    public static <T> T createInstance(Class<T> clazz) {
        try {
            return clazz.getDeclaredConstructor().newInstance();
        } catch (InstantiationException | IllegalAccessException
                 | InvocationTargetException | NoSuchMethodException e) {
            throw new RuntimeException(e);
        }
    }

    public static void main(String[] args) {
        StringBuilder sb = createInstance(StringBuilder.class);
    }
}

不能 instanceof Pair<String>

class CannotInstanceOfParameterized {
    void check(Object obj) {
        // 编译错误：Illegal generic type for instanceof
        // if (obj instanceof Pair<String>) { }

        // 合法，但 Pair<?> 等价于 raw type 检查
        if (obj instanceof Pair<?>) {
            // 只能确认 obj 是某个 Pair，不能确认 Type Argument
        }
    }
}

擦除后 Pair<String> 和 Pair<Integer> 共享同一个 Pair.class，运行时无法区分——所以 instanceof Pair<String> 没有意义。

不能 T.class

class CannotGetClassLiteral<T> {
    // 编译错误：Illegal class literal for the type parameter T
    // Class<T> clazz = T.class;

    // 合法：从外部传入 Class<T>
    void use(Class<T> clazz) {
        T instance = createInstance(clazz);
    }

    private T createInstance(Class<T> clazz) {
        try {
            return clazz.getDeclaredConstructor().newInstance();
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    }
}

基本类型不能作 Type Argument

class CannotUsePrimitive {
    // 编译错误：Type argument cannot be of primitive type
    // List<int> numbers = new ArrayList<int>();

    // 必须用包装类型
    // List<Integer> numbers = new ArrayList<>();
}

原因：擦除后 Type Variable 替换为 Object 或边界类型，而 int 不是 Object。基本类型在 JVM 层不参与对象类型系统，Valhalla 项目正在尝试解决这个根本矛盾（specialized generics）。

getClass() 和 == 看到的都是 raw type

import java.util.ArrayList;
import java.util.List;

class GetClassSeesRaw {
    void inspect() {
        List<String> stringList = new ArrayList<>();
        List<Integer> intList = new ArrayList<>();

        // true：运行时都是同一个 ArrayList.class
        System.out.println(stringList.getClass() == intList.getClass());
        // 输出：class java.util.ArrayList（看不到 String/Integer）
        System.out.println(stringList.getClass());
    }
}

因为数组具化：不能创建泛型数组

数组与泛型有一对根本矛盾：

• 数组是协变的（covariant）：B extends A 则 B[] 是 A[] 的子类型。
• 数组是具化的（reified）：数组在运行时知道自己的元素类型，每次赋值都会检查（违反时抛 ArrayStoreException）。
• 泛型是不变的（invariant）：List<String> 和 List<Object> 无继承关系。
• 泛型是擦除的（erased）：运行时拿不到 Type Argument 信息。

这两套机制在数组上叠加时打架——如果允许创建泛型数组，数组的运行时类型检查就没有依据，类型安全被打破：

class WhyNoGenericArray {
    void unsafe() {
        // 假设以下合法（实际编译错误：generic array creation）
        // List<String>[] stringLists = new List<String>[1];
        // Object[] objects = stringLists;       // 数组协变，合法
        // objects[0] = List.of(42);              // 运行时无法检查——元素类型被擦除
        // String value = stringLists[0].get(0);  // ClassCastException
    }
}

如果允许 new List<String>[1]，下一步通过 Object[] 协变赋值后塞入 List<Integer>，运行时检查不出来——最后从 List<String> 取值时崩。Java 直接禁止创建泛型数组。

数组协变的代价

数组的协变性本身也是个设计争议——它把类型错误推到运行时：

class ArrayCovarianceCost {
    void demonstrate() {
        Object[] objects = new String[10];  // 编译通过：数组协变
        // 运行时抛 ArrayStoreException：数组知道自己是 String[]
        // objects[0] = 42;
    }
}

数组的协变设计在 Java 1.0 时代为多态数组操作提供了便利（比如 Arrays.sort(Object[])），但代价是引入了 ArrayStoreException 这一类运行时错误。

泛型数组的合法写法

不能直接 new，但可以声明和强转：

import java.util.List;

class GenericArrayTricks<T> {
    // 声明合法
    private List<String>[] declared;

    // 不能 new T[10]
    // T[] arr = new T[10];

    @SuppressWarnings("unchecked")
    void tricks() {
        // 可以 new 通配符数组后强转
        List<?>[] wildcardArray = new List<?>[10];
        List<String>[] casted = (List<String>[]) wildcardArray;

        // 可以 new 原始类型数组后强转（unchecked warning）
        Object[] rawArray = new List[10];
    }
}

varargs 与 @SafeVarargs

可变参数方法本质上传入的是数组，所以泛型 varargs 也涉及泛型数组问题。Java 7 引入 @SafeVarargs（只能用于 final、static 或构造方法）让开发者显式承诺方法不会污染堆：

import java.util.List;
import java.util.ArrayList;

public class VarargsExample {
    // 不加 @SafeVarargs：调用方会看到 unchecked warning
    // 加 @SafeVarargs：开发者承诺方法内部不会污染堆
    @SafeVarargs
    public static <T> List<T> makeList(T... items) {
        List<T> result = new ArrayList<>();
        for (T item : items) {
            result.add(item);
        }
        return result;
    }

    public static void main(String[] args) {
        // 实际上这里就创建了泛型数组 T[]
        List<String> list = makeList("a", "b", "c");
    }
}

变通：用 Array.newInstance 或 List<T>

import java.lang.reflect.Array;
import java.util.ArrayList;
import java.util.List;

class GenericArrayFactory {
    // 方案一：通过反射创建数组
    @SuppressWarnings("unchecked")
    public static <T> T[] createArray(Class<T> componentType, int length) {
        return (T[]) Array.newInstance(componentType, length);
    }

    // 方案二：用 List<T> 完全替代 T[]
    public static <T> List<T> createList() {
        return new ArrayList<>();
    }

    // 方案三：从现有集合 toArray
    public static <T> T[] toArray(List<T> list, T[] pattern) {
        return list.toArray(pattern);
    }
}

🔑 模式提炼：具化与擦除的冲突

数组的协变 + 具化设计与泛型的不变 + 擦除设计存在根本矛盾。当需要"泛型容器"时优先用 List<T> 而非 T[]；确实需要泛型数组时通过 Array.newInstance(Class<T>, int) 配合 Class<T> 令牌在运行时创建，或用 @SafeVarargs 标注可变参数方法。

因为异常机制：不能 catch(T) 或 GenericException

Java 异常机制在编译期就要求 catch 子句的类型是具体的 Throwable 子类，加上运行时异常对象的 getClass() 也只能拿到擦除后的类型——这两点和泛型擦除不兼容。规则：

• T extends Throwable 合法（声明）
• method throws T 合法（编译器在调用点按 Throwable 处理）
• throw (T) t 合法（unchecked cast）
• catch (T t) 非法（无法在运行时按 T 分派）
• Problem<T> extends Exception 非法（JLS §8.1.2 禁止泛型类直接继承 Throwable）

class GenericExceptionRules<T extends Throwable> {
    // 合法：方法签名
    void riskyAction() throws T {
        // throw (T) new RuntimeException();  // 合法但 unchecked
    }

    void handle(Throwable t) {
        // 编译错误：Cannot use type parameter in catch
        // try { ... } catch (T e) { ... }
    }
}

// 编译错误：a subclass of Throwable cannot be generic
// class Problem<T> extends Exception { }

彩蛋：用泛型绕过 checked exception 检查

Neal Gafter（Java 5 泛型的共同设计者之一）在博客给出过一个利用擦除的 trick——把受检异常伪装成非受检异常抛出，调用方不需要写 try-catch，也不需要 wrap 成 RuntimeException：

public interface Task {
    void run() throws Exception;

    @SuppressWarnings("unchecked")
    static <T extends Throwable> void throwAs(Throwable t) throws T {
        // T 的擦除是 Throwable，所以这个 cast 在运行时无效
        // 编译器认为这里抛的是 T，调用方按 T 处理
        throw (T) t;
    }

    static Runnable asRunnable(Task task) {
        return () -> {
            try {
                task.run();
            } catch (Exception e) {
                // 骗过编译器：让它认为这里抛的是 RuntimeException（非受检）
                // 但运行时实际抛出的是原始的受检异常 e
                Task.<RuntimeException>throwAs(e);
            }
        };
    }
}

class DefeatCheckedException {
    public static void main(String[] args) {
        // 调用方不需要 try-catch InterruptedException
        Thread thread = new Thread(Task.asRunnable(() -> {
            Thread.sleep(1000);
            System.out.println("Hello, World!");
            throw new Exception("Sneaky!");
        }));
        thread.start();
    }
}

原理：<T extends Throwable> 擦除到 Throwable，运行时 (T) t 这个 cast 是 no-op。但编译器看到 throwAs 声明 throws T，在调用点 Task.<RuntimeException>throwAs(e) 时认为 T=RuntimeException——非受检异常，调用方不需要 catch。运行时实际抛出的是原始的 Exception e，沿调用栈往上传播，效果等同于"在 lambda 内部 throw 一个 checked exception 但不需要声明"。

这种 trick 在某些通用工具库（如 Lombok 的 @SneakyThrows、JUnit 的某些 throw 工具）里有实际应用。代价是绕过了编译期的受检异常检查，调用方如果没预料到这种异常，可能在运行时直接挂掉。

因为静态上下文：static 方法不能用类级 T

class Singleton<T> {
    private T instance;

    // 编译错误：Cannot make a static reference to the non-static type T
    // public static T getInstance() {
    //     return instance;
    // }

    // 合法：静态方法自己声明新的 Type Parameter
    public static <U> U factory(Class<U> clazz) {
        try {
            return clazz.getDeclaredConstructor().newInstance();
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    }
}

原因：类的 Type Parameter T 在实例化时才绑定（如 Singleton<String>）。但 static 方法属于类级别，不需要实例就能调用——此时 T 的具体类型根本没确定。所以 static 方法只能用自己的 Type Parameter（如这里的 <U>），不能引用类级 T。

因为签名冲突：擦除后的方法重载

不能用不同 Type Argument 重载

import java.util.List;

class CannotOverloadByTypeArgument {
    // 编译错误：name clash: process(List<Integer>) and process(List<String>) have the same erasure
    // public void process(List<String> strings) { }
    // public void process(List<Integer> integers) { }
}

擦除后两个方法签名都是 process(List)，无法共存。

泛型方法与 raw type 方法冲突

class GenericVsRawClash {
    // 编译错误：name clash: method(T) and method(Object) have the same erasure
    // public static <T> String method(T t) {
    //     return "generic";
    // }
    // public static String method(Object o) {
    //     return "raw";
    // }
}

<T> 无边界时擦除到 Object，与 method(Object) 签名冲突。

永远不要写 boolean equals(T)

这是上面规则的特例，但足够常见到值得单独提：

class Pair<T> {
    private T first;
    private T second;

    // 错误写法：擦除后是 equals(Object)，与 Object.equals 冲突
    // public boolean equals(T other) { ... }
    // 实际效果：不是 override 也不是 overload，而是 name clash

    // 正确写法：显式 override Object.equals
    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof Pair<?>)) return false;
        Pair<?> other = (Pair<?>) o;
        return java.util.Objects.equals(first, other.first)
                && java.util.Objects.equals(second, other.second);
    }

    @Override
    public int hashCode() {
        return java.util.Objects.hash(first, second);
    }
}

写 equals(T) 时编译器报错：name clash: equals(T) in Pair and equals(Object) in Object have the same erasure, yet neither overrides the other。这是因为 Pair<T> 的 T 无边界擦除到 Object，equals(T) 擦除后变成 equals(Object)——签名与 Object.equals 相同但不是合法覆写（缺少 @Override 注解时编译器不认，加了反而更明确报错）。规则是泛型类的 equals 永远写 equals(Object)，不要用 Type Parameter。

与遗留代码的冲突：堆污染

把 generic class 的实例赋给 raw type 会遇到 unchecked warning；反过来把 raw type 赋给 generic class 也会遇到 warning——后者更危险，因为它把已经污染的类型重新引入类型安全的代码：

import java.util.ArrayList;
import java.util.List;

class HeapPollution {
    @SuppressWarnings({"rawtypes", "unchecked"})
    void demonstrate() {
        List<String> strings = new ArrayList<>();
        strings.add("safe");

        // 通过 raw type 引入 Integer
        List rawList = strings;
        rawList.add(42);  // unchecked warning，但运行时不报错

        // 此时 strings 里既有 "safe" 又有 42——堆污染
        // 读出 42 时才抛 ClassCastException
        for (String s : strings) {
            // 第二次循环抛 ClassCastException: Integer cannot be cast to String
            System.out.println(s);
        }
    }
}

JLS §4.12.2 定义"堆污染"（heap pollution）：一个参数化类型的变量指向一个不是该类型的对象。堆污染通常由 raw type 操作引入，错误延迟到读取时才暴露。

现代 Java 编码原则：

1. 远离 raw type——除了反射和反序列化场景不得已时使用。
2. 全程使用参数化类型，必要时显式 @SuppressWarnings("unchecked") 并注释原因。
3. 不通过不安全的强转把 List<Integer> 赋给 List<String>——这是堆污染的直接来源。

泛型与反射——运行时找回丢失的类型

类型擦除移除了运行时的类型参数信息，但字节码的 Signature 属性（JVM §4.7.9.1）保留了类、字段、方法签名上的泛型签名——这就是反射 API 能拿回部分类型信息的依据。

Type 接口的五个子类

java.lang.reflect.Type 是所有反射类型的根接口，它有五个直接子接口/子类，覆盖了 Java 类型系统的所有形态：

Class

最常见，描述具体类和基本类型。String.class、int.class、int[].class 都是 Class 的实例。

Class<?> stringClass = String.class;
Class<?> intClass = int.class;           // class I
Class<?> intArrayClass = int[].class;    // class [I

对于泛型类，Class 只能描述 raw type——List.class 和 List<String> 的"类"在运行时是同一个 Class 实例：

// 输出：true
System.out.println(List.class == ArrayList.class.getSuperclass());

TypeVariable

描述泛型声明中的类型变量（JLS §4.4）。Class.getTypeParameters() 返回 TypeVariable<?>[]。

import java.lang.reflect.TypeVariable;

class TypeVariableExample {
    public static void main(String[] args) {
        // List 声明为 List<E>，getTypeParameters() 返回 [E]
        TypeVariable<?>[] params = List.class.getTypeParameters();
        System.out.println(params[0].getName());  // E
    }
}

ParameterizedType

描述参数化类型（如 List<String>、Map<String, Integer>）。三个核心方法：

• getRawType()：原始类型，如 List、Map
• getActualTypeArguments()：实际类型参数，如 [String]、[String, Integer]
• getOwnerType()：外部类，如 Map.Entry<K, V> 的 owner 是 Map

只有当类型信息存在时才能拿到 ParameterizedType——纯局部变量、new ArrayList<>() 后通过 getClass() 拿不到。

GenericArrayType

描述泛型数组类型，元素类型是 TypeVariable 或 ParameterizedType。例如 T[]、List<String>[]。

import java.lang.reflect.Field;
import java.lang.reflect.GenericArrayType;
import java.lang.reflect.Type;
import java.util.List;

class GenericArrayField<T> {
    T[] array;
    List<String>[] lists;

    public static void main(String[] args) throws NoSuchFieldException {
        Field arrayField = GenericArrayField.class.getDeclaredField("array");
        Type type = arrayField.getGenericType();
        // type 是 GenericArrayType
        if (type instanceof GenericArrayType) {
            Type component = ((GenericArrayType) type).getGenericComponentType();
            System.out.println(component);  // T
        }
    }
}

WildcardType

描述通配符类型。getUpperBounds() 返回上界（至少包含 Object），getLowerBounds() 返回下界（? super T 才有，否则为空数组）。

import java.lang.reflect.Field;
import java.lang.reflect.ParameterizedType;
import java.lang.reflect.Type;
import java.lang.reflect.WildcardType;
import java.util.List;

class WildcardFieldExample {
    List<? extends Number> upper;
    List<? super Integer> lower;

    public static void main(String[] args) throws NoSuchFieldException {
        Field upperField = WildcardFieldExample.class.getDeclaredField("upper");
        Type type = upperField.getGenericType();
        ParameterizedType pt = (ParameterizedType) type;
        WildcardType wildcard = (WildcardType) pt.getActualTypeArguments()[0];

        System.out.println(java.util.Arrays.toString(wildcard.getUpperBounds()));  // [class java.lang.Number]
        System.out.println(java.util.Arrays.toString(wildcard.getLowerBounds()));  // []

        Field lowerField = WildcardFieldExample.class.getDeclaredField("lower");
        WildcardType lowerWildcard = (WildcardType)
                ((ParameterizedType) lowerField.getGenericType()).getActualTypeArguments()[0];
        System.out.println(java.util.Arrays.toString(lowerWildcard.getUpperBounds()));  // [class java.lang.Object]
        System.out.println(java.util.Arrays.toString(lowerWildcard.getLowerBounds()));  // [class java.lang.Integer]
    }
}

什么时候能拿到类型信息

擦除并非把所有泛型信息都抹掉——类的继承关系、字段声明、方法签名上的泛型信息会写进字节码的 Signature 属性（JVM §4.7.9.1），反射 API 能读出来。但局部变量里的泛型信息不进 Signature，反射拿不到。

能拿到的场景

场景	API
子类继承时显式指定泛型参数	getGenericSuperclass()
字段声明带泛型	Field.getGenericType()
方法返回值带泛型	Method.getGenericReturnType()
方法参数带泛型	Method.getGenericParameterTypes()
实现接口带泛型	getGenericInterfaces()
匿名子类化参数化类型	通过 getGenericSuperclass() 间接拿到

拿不到的场景

场景	原因
局部变量 List<String> list = new ArrayList<>()	局部变量不进 Signature 属性
通过 getClass() 后取泛型参数	getClass() 返回 Class<?>，已是擦除后的 raw type
纯反射 new ArrayList<>() 拿不到 <String>	实例本身不带类型参数信息

类型令牌模式

类型令牌（Type Token / Type Literal / Type Reference）是绕过擦除、在运行时拿到泛型类型参数的标准模式。原理：创建一个泛型类的匿名子类，把 Type Argument 固化到子类的 Signature 属性里，再用 getGenericSuperclass() 读出来。

super type tokens 工作原理

Neal Gafter（Java 5 泛型共同设计者）在 2006 年的博客文章 Super Type Tokens 里给出了这个模式的经典实现：

import java.lang.reflect.ParameterizedType;
import java.lang.reflect.Type;

public abstract class TypeReference<T> implements Comparable<TypeReference<T>> {
    protected final Type type;

    protected TypeReference() {
        Type superClass = getClass().getGenericSuperclass();
        if (!(superClass instanceof ParameterizedType)) {
            throw new IllegalArgumentException("Missing type parameter; " +
                    "construct as new TypeReference<...>(){}");
        }
        this.type = ((ParameterizedType) superClass).getActualTypeArguments()[0];
    }

    public Type getType() {
        return type;
    }

    @Override
    public int compareTo(TypeReference<T> other) {
        return type.getTypeName().compareTo(other.type.getTypeName());
    }
}

两个设计要点：

1. abstract class 强制调用方创建子类——只有子类化才能让 getGenericSuperclass() 返回 ParameterizedType。
2. implements Comparable<TypeReference<T>> 不是真的为了比较，而是防止调用方把 TypeReference 用成 raw type——raw type 的 getGenericSuperclass() 拿不到正确的 Type Argument。

使用：

import java.util.List;

class TypeReferenceUsage {
    public static void main(String[] args) {
        // 匿名子类：new TypeReference<List<String>>() {}
        // 编译后，这个匿名子类的 Signature 属性里保留了 List<String>
        TypeReference<List<String>> ref = new TypeReference<List<String>>() {};
        System.out.println(ref.getType());  // java.util.List<java.lang.String>
    }
}

下图展示类型令牌的工作原理——匿名子类如何把 Type Argument 固化到 Signature 属性：

工业实现

Java 生态里多个库各自实现了这个模式，名字不同但原理一致：

库	类名	用途
Gson	com.google.gson.reflect.TypeToken<T>	反序列化泛型 JSON
Jackson	com.fasterxml.jackson.core.type.TypeReference<T>	反序列化泛型 JSON
Spring	org.springframework.core.ParameterizedTypeReference<T>	REST 客户端的泛型响应
Guice	com.google.inject.TypeLiteral<T>	依赖注入的类型绑定

Gson 的典型用法：

// 反序列化 List<String> 这种参数化类型
List<String> strings = gson.fromJson(json,
        new TypeToken<List<String>>() {}.getType());

Spring 的 RestTemplate：

// 反序列化泛型响应
ParameterizedTypeReference<List<User>> typeRef =
        new ParameterizedTypeReference<List<User>>() {};
List<User> users = restTemplate.exchange(url, HttpMethod.GET, null, typeRef).getBody();

运行时捕获类型参数的三种方法

实际项目里需要"在运行时拿到 T 的 Class"的场景，有三种主流实现。

方法一：传入 Class<T> 令牌

最直接，调用方传入 Class<T>，被调用方直接持有。

public class GenericClass<T> {
    private final Class<T> type;

    public GenericClass(Class<T> type) {
        this.type = type;
    }

    public Class<T> getType() {
        return type;
    }

    public T newInstance() {
        try {
            return type.getDeclaredConstructor().newInstance();
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    }
}

// 使用
GenericClass<String> factory = new GenericClass<>(String.class);

缺点：调用方必须显式传 Class<T>，new GenericClass<String>() 不带令牌就拿不到。

方法二：super type tokens（匿名子类）

如上文 TypeReference，调用方写匿名子类。

TypeReference<Map<String, List<Integer>>> ref =
        new TypeReference<Map<String, List<Integer>>>() {};
Type type = ref.getType();

缺点：每次都要写匿名子类，语法噪声大；只能拿到 Type，要拿 Class<?> 还需进一步解析。

方法三：Spring ResolvableType

Spring 提供的 ResolvableType 封装了 Type 解析逻辑，支持从字段、方法参数、继承链等多种来源推断泛型类型。

import org.springframework.core.ResolvableType;

// 从实例推断
ResolvableType t1 = ResolvableType.forInstance(new ArrayList<String>());

// 从字段推断
ResolvableType t2 = ResolvableType.forField(getClass().getDeclaredField("field"));

// 从类继承链推断：拿 MyClass 实现的 List<E> 的 E
ResolvableType t3 = ResolvableType.forClass(MyClass.class).as(List.class).getGeneric(0);
Class<?> resolved = t3.resolve();

优点：API 友好，解析能力强，能处理嵌套泛型。缺点：依赖 Spring 框架。

黑魔法：直接获取通配符的 bound

字段声明的 ? extends X 这种通配符的 bound，可以通过反射直接读出来——不需要类型令牌：

import java.lang.reflect.Field;
import java.lang.reflect.ParameterizedType;
import java.lang.reflect.Type;
import java.lang.reflect.WildcardType;
import java.util.Arrays;
import java.util.List;

public class WildcardBoundInspector {

    private List<? extends Number> upperBounded;
    private List<? super Integer> lowerBounded;

    public static void main(String[] args) throws NoSuchFieldException {
        inspect("upperBounded");    // upper: [Number], lower: []
        inspect("lowerBounded");    // upper: [Object], lower: [Integer]
    }

    static void inspect(String fieldName) throws NoSuchFieldException {
        Field field = WildcardBoundInspector.class.getDeclaredField(fieldName);
        Type genericType = field.getGenericType();
        ParameterizedType pt = (ParameterizedType) genericType;
        for (Type arg : pt.getActualTypeArguments()) {
            if (arg instanceof WildcardType) {
                WildcardType w = (WildcardType) arg;
                System.out.println(fieldName + " upper: " + Arrays.toString(w.getUpperBounds()));
                System.out.println(fieldName + " lower: " + Arrays.toString(w.getLowerBounds()));
            }
        }
    }
}

字节码的 Signature 属性精确记录了通配符的上下界——即使运行时擦除，字段声明的元信息仍可读。这一能力在序列化框架、ORM、DI 容器里有实际应用。

🔑 模式提炼：反射捕获类型令牌

擦除只擦除实例的类型参数信息，类定义、字段声明、方法签名上的泛型信息保留在字节码 Signature 属性里。当需要在运行时拿到泛型类型参数时，用类型令牌模式：创建泛型类的匿名子类把 Type Argument 固化到子类 Signature，再用 getGenericSuperclass() 读出。Gson 的 TypeToken、Jackson 的 TypeReference、Spring 的 ParameterizedTypeReference 都基于这一原理。

高级模式与黑魔法

前面九章覆盖了泛型的常规使用。这一章讲几个进阶模式——把泛型当作编译期类型系统的"图灵完备"用途来用，让类型检查器帮业务代码挡住错误。

幽灵类型：编译期状态机

幽灵类型（Phantom Types）是一种把运行时状态检查提前到编译期的技巧。核心思想：用不同的类型（而非枚举值）表示状态，用泛型参数携带状态信息，用方法签名的类型变化表达状态转移。非法的状态转移在编译期直接报错，而不是等到运行时抛异常。

经典案例：飞机的状态机。一架飞机有"已着陆（Landed）/飞行中（Flying）/已维修（Maintained）"等状态，某些操作只在特定状态下合法——比如"起飞"只能在 Landed 状态下调用。

用接口子类作为状态标记

// 状态标记接口（不含方法，仅用于类型层面区分）
public interface FlightStatus {}
public interface Landed extends FlightStatus {}
public interface Flying extends FlightStatus {}
public interface Maintained extends FlightStatus {}

// Plane 的 Type Parameter 携带状态信息
public class Plane<S extends FlightStatus> {
    private final int id;

    private Plane(int id) {
        this.id = id;
    }

    // 只能生成初始态实例
    public static Plane<Landed> landed(int id) {
        return new Plane<>(id);
    }

    // 状态转移：起飞，返回 Flying 态的实例
    public Plane<Flying> takeOff() {
        return new Plane<>(this.id);
    }

    // 状态转移：降落，返回 Landed 态的实例
    public Plane<Landed> land() {
        return new Plane<>(this.id);
    }

    // 状态转移：维修，返回 Maintained 态的实例
    public Plane<Maintained> maintain() {
        return new Plane<>(this.id);
    }
}

调用方的非法状态转移会被编译器拒绝：

class PlaneClient {
    void use() {
        Plane<Landed> plane = Plane.landed(1);

        // 合法：Landed -> Flying
        Plane<Flying> flying = plane.takeOff();

        // 合法：Flying -> Landed
        Plane<Landed> landed = flying.land();

        // 编译错误：Flying 没有 maintain 方法
        // flying.maintain();

        // 编译错误：Flying 没有 takeOff 方法（不能重复起飞）
        // flying.takeOff();
    }
}

下图展示 Plane 的状态转移图——每条边对应一个方法签名：

不基于接口的幽灵类型

也可以用 abstract class 的嵌套类作为状态标记，省掉独立接口：

class Team<S> {
    private java.util.List<String> members = new java.util.ArrayList<>();

    // 嵌套 abstract 类作为状态标记
    static abstract class READY {}
    static abstract class STARTED {}
    static abstract class END {}
}

class Game {
    public Team<Team.STARTED> start(Team<Team.READY> team) {
        // ...启动逻辑...
        return new Team<>();  // 返回新状态的实例
    }

    public Team<Team.END> end(Team<Team.STARTED> team) {
        // ...结束逻辑...
        return new Team<>();
    }

    // 编译错误：end 的参数要求 STARTED 状态
    // public Team<Team.END> misuse(Team<Team.READY> team) {
    //     return end(team);
    // }
}

Builder 模式的类型安全实现

幽灵类型最广泛的应用是类型安全的 Builder——确保必填字段都设置了再调用 build()。

public class User {
    private final String name;
    private final String password;

    private User(String name, String password) {
        this.name = name;
        this.password = password;
    }

    public static User build(Builder<TRUE, TRUE> builder) {
        return new User(builder.name, builder.password);
    }

    public static Builder<FALSE, FALSE> builder() {
        return new Builder<>();
    }

    public static class Builder<HNAME, HPASSWORD> {
        private String name;
        private String password;

        private Builder() {}

        // 调 name 后返回 Builder<TRUE, HPASSWORD>，name 字段状态变 TRUE
        public Builder<TRUE, HPASSWORD> name(String name) {
            this.name = name;
            return (Builder<TRUE, HPASSWORD>) this;  // 简化版，省略新建实例
        }

        // 调 password 后返回 Builder<HNAME, TRUE>，password 字段状态变 TRUE
        public Builder<HNAME, TRUE> password(String password) {
            this.password = password;
            return (Builder<HNAME, TRUE>) this;
        }
    }

    // 状态标记
    static abstract class TRUE {}
    static abstract class FALSE {}
}

class UserBuilderClient {
    void use() {
        // 合法：两个字段都设置了
        User user = User.builder()
                .name("alice")
                .password("secret")
                .build();  // build 要求 Builder<TRUE, TRUE>

        // 编译错误：password 没设置，Builder<TRUE, FALSE> 不能传给 build(Builder<TRUE, TRUE>)
        // User invalid = User.builder()
        //         .name("alice")
        //         .build();
    }
}

每个字段对应一个 Type Parameter，表示"已设置（TRUE）“或"未设置（FALSE）”。build 方法的签名要求所有字段状态都是 TRUE——编译器强制调用方必须设置完所有必填字段。这是 Lombok 的 @Builder 也使用的设计。

🔑 模式提炼：编译期状态机

幽灵类型把运行时状态检查提前到编译期。用不同的类型（而非枚举值）表示状态，用泛型参数携带状态信息，用方法签名的类型变化表达状态转移。非法的状态转移在编译期就会报错，而非等到运行时才抛出异常。这一模式特别适合 Builder、状态机、协议流程等需要强制执行调用顺序的场景。

Lambda 与 Optional 中的通配符转换

JDK 内部大量使用泛型擦除的 unchecked cast 来复用单例。Optional.empty() 就是典型——它返回 Optional<T>，但实际持有一个 Optional<?> 单例：

import java.util.Optional;

// JDK 源码（简化）
public final class Optional<T> {
    // 单例：所有 empty() 调用共用这一个实例
    private static final Optional<?> EMPTY = new Optional<>(null);

    private final T value;

    private Optional(T value) {
        this.value = value;
    }

    public static <T> Optional<T> empty() {
        @SuppressWarnings("unchecked")
        Optional<T> t = (Optional<T>) EMPTY;
        return t;
    }

    public static <T> Optional<T> of(T value) {
        return new Optional<>(java.util.Objects.requireNonNull(value));
    }

    public static <T> Optional<T> ofNullable(T value) {
        return value == null ? empty() : of(value);
    }
}

EMPTY 的实际类型是 Optional<?>，但 empty() 把它强转为 Optional<T>。安全性保证：EMPTY 内部 value 是 null，null 可以赋给任何引用类型，所以强转不会引发 ClassCastException。

这个技巧让所有 Optional.empty() 调用共享同一个单例，避免每次创建新对象。代价是一处 @SuppressWarnings("unchecked")——JDK 基础库里类似的 unchecked cast 不少，开发者写库时也可以用同样的思路。

类型注解（JSR 308）

Java 8 引入类型注解（JSR 308），允许在任何使用类型的位置添加注解——不仅限于类、方法、字段声明：

import java.lang.annotation.ElementType;
import java.lang.annotation.Target;
import java.util.List;
import java.util.Map;

@Target(ElementType.TYPE_USE)
@interface NonNull {}

@Target(ElementType.TYPE_USE)
@interface Nullable {}

public class TypeAnnotationExample {
    // 注解泛型类型参数
    private List<@NonNull String> names;

    // 注解嵌套泛型
    private Map<@NonNull String, @Nullable List<@NonNull Integer>> data;

    // 注解通配符边界
    private List<@NonNull ? extends Number> numbers;

    // 注解数组：第一个注解元素类型，第二个注解数组本身
    private @NonNull String @Nullable [] array;
}

类型注解本身不影响运行时行为——它们只写入字节码的 RuntimeVisibleTypeAnnotations 属性（JVM §4.7.20）。配合静态分析工具（如 Checker Framework、SpotBugs、NullAway）可以在编译期检测：

• 空指针：@NonNull 变量不能赋 null，@Nullable 变量使用前必须判空
• 线程安全：@GuardedBy("lock") 标注的字段访问必须持有指定锁
• 国际化：@I18n 标注的字符串需要从资源文件读取
• 单位：@m 标注的数值与 @km 标注的数值不能直接相加

这是把运行时错误提前到编译期的另一种途径，与泛型本身的设计哲学一致。

模式匹配式重载（黑魔法）

Java 的方法分派是按方法签名（方法名 + 参数类型）做的，不支持 C++ 那样的偏特化。但可以用泛型 + varargs 模拟一个"看起来像模式匹配"的重载：

import java.util.List;
import java.util.ArrayList;

class A {}
class B {}

class PatternMatchDispatcher {
    // 注意最后一个 dummy 参数：用不同类型的可变参数区分重载
    void handle(List<A> list, A... dummy) {
        System.out.println("handle List<A>");
    }

    void handle(List<B> list, B... dummy) {
        System.out.println("handle List<B>");
    }
}

class PatternMatchClient {
    public static void main(String[] args) {
        PatternMatchDispatcher dispatcher = new PatternMatchDispatcher();
        dispatcher.handle(new ArrayList<A>());  // 输出：handle List<A>
        dispatcher.handle(new ArrayList<B>());  // 输出：handle List<B>
    }
}

原理：可变参数 A... dummy 编译后是 A[]，B... dummy 编译后是 B[]——数组是具化的，签名不冲突。调用方不传 dummy 参数时，编译器按主参数 List<A> / List<B> 推断 dummy 的类型为对应数组，分派到正确的方法。

注意这是黑魔法——可读性差，IDE 跳转容易混乱，慎用。生产代码优先考虑访问者模式或显式 if-instanceof 分派。

空泛型数组的拷贝方法

Collection.toArray(T[] a) 是 Java 集合 API 的经典方法，实现里包含一个值得学习的泛型数组技巧：

import java.util.Arrays;

public class ArrayCollection<E> {
    private final E[] a;

    public ArrayCollection(E[] array) {
        this.a = java.util.Objects.requireNonNull(array);
    }

    public int size() {
        return a.length;
    }

    @Override
    @SuppressWarnings("unchecked")
    public <T> T[] toArray(T[] pattern) {
        int size = size();
        if (pattern.length < size) {
            // 用 pattern 的运行时类型创建新数组
            return Arrays.copyOf(a, size,
                    (Class<? extends T[]>) pattern.getClass());
        }
        System.arraycopy(a, 0, pattern, 0, size);
        if (pattern.length > size) {
            pattern[size] = null;  // 按约定，多余位置放 null
        }
        return pattern;
    }
}

要点：

1. 如果传入数组不够大，用 Arrays.copyOf 创建一个新数组——pattern.getClass() 提供运行时类型。
2. 如果传入数组够大，把元素拷进去，多余位置放 null。
3. 调用方用法：String[] arr = list.toArray(new String[0]);——传 0 长度数组是现代最佳实践（JIT 优化后比 new String[list.size()] 更快）。

这个方法是"不能创建泛型数组"限制下的标准变通——不在泛型类里直接 new T[]，而是通过传入 Class<T[]> 或类型令牌数组让运行时拿到具体类型。

实战速查表

把全文的模式提炼汇总成一张速查表，方便后续查阅。

场景关键词	对应模式	解决方案
类型擦除后方法签名冲突	擦除桥接	编译器自动生成桥方法，反射时用 Method.isBridge() 过滤
需要泛型数组	具化与擦除的冲突	用 Array.newInstance(Class<T>, int) 或 List<T> 替代
基类方法返回子类型	类型自约束	<T extends Base<T>> 自限定模式（Enum、Builder、fluent API）
运行时获取泛型类型	类型令牌	TypeToken / TypeReference 匿名子类捕获（super type tokens）
Lambda/Stream 类型推断失败	目标类型驱动	类型见证 ClassName.<Type>method() 显式指定
泛型方法不能重载	擦除签名冲突	改用不同方法名、通配符统一、或加类型参数区分
读取用 extends，写入用 super	PECS（读写分离）	<? extends T> 生产者，<? super T> 消费者
编译期空值检查	类型注解	@NonNull / @Nullable + Checker Framework / NullAway
跨泛型边界做比较	Comparable 下界通配符	<T extends Comparable<? super T>>
通配符类型需要写操作	通配符捕获桥接	私有泛型辅助方法捕获 <?>
T 与父类型比较	Comparable 下界	Comparable<? super T>
强制字段调用顺序	幽灵类型 / 编译期状态机	字段状态用 Type Parameter（TRUE/FALSE）标记
子类覆写返回协变类型	协变返回 + 桥接	直接声明协变返回类型，编译器自动生成桥接方法
Lambda 需要可序列化	交叉类型 cast	(Predicate<String> & Serializable) s -> ...
多个接口边界	交叉类型	<T extends A & B & C>，擦除到第一个边界

常见错误对应

错误信息	根因	修复方向
generic array creation	不能 new T[] 或 new List<String>[]	用 Array.newInstance 或 List<T>
Cannot make a static reference to the non-static type T	static 方法引用类级 T	static 方法用自己的 Type Parameter
Cannot use type parameter in catch	catch(T) 非法	catch 具体异常类型，或用 throwAs trick
name clash: ... have the same erasure	擦除后方法签名冲突	改名、用通配符、或加类型参数区分
incompatible types: List<String> cannot be converted to List<Object>	泛型不变	用 List<? extends Object> 或 List<?>
incompatible equality constraint: T and ?	嵌套通配符无法捕获	改用具体类型或重构数据结构
Cannot use type parameter T in catch block	泛型异常受限于 Throwable	catch 具体类型，不能 catch T
Cannot make a static reference to type parameter T from static context	静态上下文不能用类级 T	static 方法声明自己的 Type Parameter <U>

延伸阅读

经典文献

• Angelika Langer’s Java Generics FAQ：Java 泛型最详尽的 FAQ，覆盖几乎所有边角案例。本文里很多"为什么不能"都能在这里找到 JLS 出处。
• Neal Gafter: Super Type Tokens：类型令牌模式的原始出处，Java 5 泛型共同设计者写的。
• Joshua Bloch: Effective Java Item 28-33：泛型章节，PECS 原则、类型令牌、递归边界都讲得很透。
• Brian Goetz: Java Concurrency in Practice：虽然主题是并发，但对泛型在并发容器中的用法有深入讨论。

语言规范

• JLS §4：Types, Values, and Variables（含 §4.4 类型变量、§4.5 参数化类型、§4.6 擦除、§4.7 具化类型、§4.8 raw type）
• JLS §8.1.2：Generic Classes and Type Parameters
• JLS §13.1：The Form of a Binary（含 Signature 属性、桥接方法的合成规则）
• JVM §4.7.9.1：The Signature Attribute（字节码层面的泛型签名存储）

Project Valhalla 与未来方向

• JEP 218: Generics over Primitive Types：原型探索（2004 年提出，至今未落地）。
• JEP 301: Enhanced Enums：允许枚举泛型化（撤销）。
• JEP 390: Warnings for Value-Based Classes：警告 value-based class 的误用。
• JEP 401: Value Classes and Objects (Preview)：Valhalla 的核心——value class。
• Project Valhalla 主页：跟踪 specialized generics / primitive generics 的最新进展。

跨语言对比

C++ Templates

• 编译期为每个类型参数实例化独立代码（template instantiation）
• 图灵完备——编译期能做任意计算（template metaprogramming）
• 代码膨胀代价；不支持跨编译单元的模板 ABI
• f(g<a, b>(c)) 的解析歧义是 Java 把类型见证前置的原因

参考：C++ Reference: Templates

C# Generics

• CLR 在运行时保留泛型类型信息（reified generics）
• List<string> 和 List<int> 在 CLR 内部是不同类型
• 没有擦除带来的种种限制
• C# 2.0 (2005) 引入，没有 Java 的兼容性包袱

参考：MSDN: Generics in the .NET Framework

Kotlin reified generics

Kotlin 引入 reified 关键字让 inline 函数能在函数体内访问泛型类型参数——看起来像绕过了擦除，实际是通过 inline 展开 + 编译期替换实现的：

// Kotlin
inline fun <reified T> isInstance(value: Any?): Boolean {
    return value is T  // 看起来违反 Java 擦除，实际是 inline 函数编译期展开
}

参考：Kotlin: Reified Type Parameters

Scala Higher-Kinded Types

Scala 支持高阶类型（higher-kinded types），可以抽象"类型构造器"本身——比 Java 的泛型表达力更强：

// Scala: 抽象 F[_] 这个类型构造器
trait Functor[F[_]] {
    def map[A, B](fa: F[A])(f: A => B): F[B]
}

Java 至今不支持这种级别的抽象。参考：Scala: Higher-Kinded Types

相关项目与工具

• typetools：第三方类型工具库，简化类型令牌的使用。
• Checker Framework：类型注解静态分析框架，提供 @NonNull、@Regex、@tainted 等丰富类型限定。
• NullAway：Error Prone 插件，专门做 @Nullable 检查。
• Google Gson TypeToken：工业级类型令牌实现源码。
• Spring ParameterizedTypeReference：Spring 的类型令牌实现。

历史脉络

• JSR 14: Adding Generics to the Java Programming Language：2003 年最终发布，Java 5 引入泛型的原始规范。
• Martin Odersky: The Origins of Scala and GJ：GJ（Generic Java）是 Java 泛型的前身，Odersky 后来设计了 Scala。
• Gilad Bracha: Generics in the Java Programming Language：2004 年的官方白皮书，解释为什么选择擦除。

---

本文为 2020 年首发、2026 年重写版。重写重组了结构（以"擦除 + 协变"双主线贯穿全文）、修正了原文的术语和拼写错误、合并了散落各处的重复内容（递归边界、桥接方法、PECS、类型令牌）、补充了历史背景、跨语言对比、Valhalla 展望。原文的 Pair/DateInterval 字节码证据、Enum 自限定案例、绕过 checked exception 的 trick 等核心内容均完整保留。