Java-Generics-PartV

类型参数边界

在正式介绍类型参数边界之前，先回顾前文定义的核心概念：类型参数是定义泛型类 / 泛型方法时声明的占位符，该占位符会在泛型实例化的过程中，被具体的类型实参替换。

若类型参数T未添加任何约束，则代表未知类型。在泛型类或泛型方法的定义内部，T类型的变量仅能调用Object类中定义的方法，无法调用其他自定义方法，这一限制无法满足实际开发中的多数场景需求。开发中通常需要对类型参数进行限定，要求类型参数必须为指定类的子类，或实现指定接口，而非支持任意类型传入。

为类型参数T添加类型限制后，即可在泛型定义中直接调用限制类型所包含的方法；同时在泛型实例化时，仅满足约束条件的类型实参才符合语法规范。

该特性即为类型参数边界（Type Parameter Bounds）。类型参数边界是一种引用类型约束，用于规范类型参数的取值范围：既限制了可作为类型实参的类型集合，又允许在泛型定义中访问边界类型的成员方法。每个类型参数支持声明多个边界，具体语法格式如下：

<TypeParameter extends Class & Interface 1 & ... & Interface N >

类型参数边界规定，泛型实例化时传入的类型实参，必须满足所有边界的约束条件。以上述语法为例，TypeParameter对应的类型实参，必须同时是指定类的子类、以及所有声明接口的实现类。

关键字 extends 可应用于 Java 的多个语法特性中，且语法结构高度相似，极易产生混淆，以下对常见场景进行区分：

class A extends B {} // 类继承
interface A extends B, C {} // 接口继承
class A implements B, C // 接口实现
class A<T extends B & C> // 参数类型边界
A<? extends B> // 有界通配符参数化类型

在 Java 语法规则中，类仅支持单类继承，有界通配符仅支持单个类边界；与之不同的是，接口支持多接口继承、类支持多接口实现、类型参数支持多边界声明。此外，由于参数类型边界与有界通配符参数化类型的语法结构高度相似，二者在实际使用中极易产生混淆，需要明确区分。

绝大多数引用类型均可作为类型参数边界，包括类、接口、枚举类型、参数化类型；基本数据类型与数组类型不支持作为类型参数边界。前文已说明，为类型参数指定边界后，即可在泛型定义域内直接调用边界类型的方法。若类型边界为有界通配符参数化类型，则可调用的方法范围与该有界通配符参数化类型保持一致。例如下述类定义：

class X< T extends List<? extends Number> > {
  public void someMethod(T t) {
    t.add(new Long(0L));    // error
    Number n = t.remove(0);
  }
}

T 类型的变量绑定了 List<? extends Number> 这一有界通配符参数化类型边界。因此，集合的 add 方法仅接受 Number 的未知子类类型参数，为保证类型安全，编译器仅允许传入 null 作为入参，直接传入 Long 实例会触发编译错误；而 remove 方法的返回值类型可确定为 Number，能够直接使用 Number 类型的引用接收。这和Java-Generics-PartIII中提到的通配符参数化类型的限制是一致的。

上下边界

前文介绍的类型参数边界，所有示例均采用**上边界（upper bound）**声明。回顾有界通配符参数化类型的特性：该语法支持同时定义通配符的上边界与下边界。

Collection<? extends Animal> // 通配符上边界
Collection<? super Animal> // 通配符下边界

但在类型参数边界的语法规则中，仅支持声明上边界，不支持下边界，非法语法会直接触发编译错误：

class Box<T extends Number> // 合法：类型参数上边界
class Box<T super Number> // 语法错误：类型参数不支持下边界

想要理解 Java 禁止类型参数使用下边界的原因，可先回顾上边界带来的三个核心作用：

1. 限制泛型实例化的类型实参范围
2. 允许在泛型定义域内访问边界类型的非静态方法、成员变量
3. 作为类型擦除后 JVM 使用的实际类型

假设类型参数支持下边界语法，其特性分析如下：

编译器可以实现对类型实参的限制。若定义Box<T super Number>，则Box<Object>符合约束，而Box<Long>不符合约束，这一规则与上边界保持一致。

但该语法无法实现核心价值：无法访问边界类型的方法与成员变量。T super Number仅能确定类型实参是Number的超类，无法明确其具备的成员方法；唯一可确定的是所有类型实参均为引用类型，即Object的子类，而这一特性无需声明下边界即可生效。

从类型擦除角度分析，下边界不会改变擦除结果：泛型定义中的类型参数占位符，最终仍会被替换为Object，与未声明边界的泛型类完全一致。

综上，类型参数下边界既无法访问指定边界的成员，类型擦除后也无任何实际作用，仅会增加语法复杂度与理解成本。因此 Java 语法明确禁止了类型参数声明下边界的写法。

静态上下文

在前几篇内容中，已经简要提及泛型在静态上下文中失效的相关问题。泛型类虽然可以定义静态成员，但该类所有不同的参数化类型，会共享同一个静态成员实例。同时也提到，枚举类中的枚举常量均为静态实例，因此无法绑定具体的泛型实参类型，泛型枚举类不具备实际意义。

可以通过一个核心问题理解这一机制：泛型类中定义的静态成员，最终会存在多少个实例？

泛型类可以被无数个合法的类型实参实例化，如果每一个参数化类型都独立持有一个静态成员实例，那么实例数量将不可控，这与 Java 静态成员的设计原则相悖。

根本原因在于类型擦除机制：编译完成后，所有参数化类型都会被擦除为原始类型，不同的参数化类型最终对应同一份字节码。静态上下文的内容不会随类型实参的变化而改变，在静态上下文中直接使用类型参数不具备实际意义。因此，泛型类的静态成员在内存中仅存在唯一实例，由所有参数化类型共享。

总结

1.定义泛型类或泛型方法时，可对类型参数施加类型约束，该特性称为类型参数边界。

2.声明类型参数边界后，泛型实例化仅允许传入符合边界约束的类型实参，同时可在泛型定义域内直接调用边界类型的非静态成员。

3.类型参数边界仅支持上边界，不支持下边界声明。

4.静态上下文无法使用类型参数。核心原因是类型擦除机制会使同一泛型类的所有参数化类型统一转为原始类型，所有实例共享同一份静态成员，类型参数在静态场景中不具备区分意义。