故事的小黄花 从出生那年就飘着
童年的荡秋千 随记忆一直晃到现在
可变参数（ vararg ） 方法（详见第 53 条）和泛型都是在 Java 5 中就有了，因此你可能会期待它们可以良好地相互作用；遗憾的是，它们不能 。 可变参数的作用在于让客户端能够将可变数量的参数传给方法，但这是个技术露底（ leaky abstration ）：当调用一个可变参数方法时，会创建一个数组用来存放可变参数；这个数组应该是一个实现细节，它是可见的 。因此，当可变参数有泛型或者参数化类型时，编译警告信息就会产生温乱 。
回顾一下第28条，非具体化( non-reifable)类型是指其运行时代码信息比编译时少，并且显然所有的泛型和参数类型都是非具体化的。如果一个方法声明其可变参数为non-reifiable类型，编译器就会在声明中产生一条警告。如果方法是在类型为non-reifiable的可变参数.上调用，编译器也会在调用时发出一条警告信息。这个警告信息类似于：
当一个参数化类型的变量指向一个不是该类型的对象时，会产生堆污染（ heap pollution)。 它导致编辑器的自动生成转换失败，破坏了泛型系统的基本保证 。
举个例子 。 下面的代码是对第 28 条中的代码片段稍加修改而得：
这个方法没有可见的转换，但是在调用一个或者多个参数时会抛出 ClassCastException 异常。 上述最后一行代码中有一个不可见的转换，这是由编译器生成的 。 这个转换失败证明类型安全已经受到了危及，因此将值保存在泛型可变参数数组参数 中是不安全的 。
这个例子引出了 一个有趣的问题：为什么显式创建泛型数组是非法的，用泛型可变参数声明方法却是合法的呢？换句话说，为什么之前展示的方法只产生一条警告，而第 28 条中的代码片段却产生一个错误呢？答案在于，带有泛型可变参数或者参数化类型的方法在实践中用处很大，因此 Java 语言的设计者选择容忍这 一矛盾的存在 。 事实上，Java 类库导出了好几个这样的 方法，包括 Arrays.asList(T ... a ）、Collections.addAll (Collection<? super T> C, T . . . elements ），以及 EnumSet.of (E first,E ... rest ） 。 与前面提到的危险方法不一样这些类库方法是类型安全的 。
在 Java 7 之前，带泛型可变参数的方法的设计者，对于在调用处 出错的警告信息一点办法也没有。 这使得这些 API 使用起来非常不愉快 。 用户必须忍受这些警告，要么最好在每处调用点都通过＠SuppressWarnings （飞rnchecked”）注解来消除警告（详见第 27条） 。 这么做过于烦琐，而且影响可读性，并且掩盖了反映实际问题的警告 。
在 Java 7 中，增加了 SafeVarargs 注解，它让带泛型 vararg 参数的方法的设计者能够自动禁止客户端的警告 。 本质上，SafeVarargs 注解是通过方法的设计者做出承诺，声明这是类型安全的。 作为对于该承诺的交换，编译器同意不再向该方法的用户发出警告说这些调用可能不安全。
重要的是，不要随意用＠ SafeVarargs 对方法进行注解，除非它真正是安全的 。 那么它凭什么确保安全呢？回顾一下，泛型数组是在调用方法的时候创建的，用来保存可变参数 。 如果该方法没有在数组中保存任何值，也不允许对数组的引用转义（这可能导致不被信任的代码访问数组），那么它就是安全的 。 换句话说，如果可变参数数组只用来将数量可变的参数从调用程序传到方法（毕竟这才是可变参数的目的），那么该方法就是安全的 。
值得注意的是，从来不在可变参数的数组中保存任何值，这可能破坏类型安全性 。以下面的泛型可变参数方法为例，它返回了一个包含其参数的数组 。 乍看之下，这似乎是一个方便的小工具 ：
static<T> T[] toArray(T... args) {
return args;
}这个方法只是返回其可变参数数组，看起来没什么危险，但它实际上很危险 ！这个数组的类型，是由传到方法的参数的编译时类型来决定的，编译器没有足够的信息去做准确的决定 。 因为该方法返回其可变参数数组 ，它会将堆污染传到调用堆枝上 。
下面举个具体的例子 。 这是一个泛型方法，它带有三个类型为 T 的参数，并返回 一个包含两个（随机选择的）参数的数组：
这个方法本身并没有危险，也不会产生警告，除非它 调用了 带有泛型 可 变参数的toArray 方法 。
在编译这个方法时，编译器会产生代码， 创建一个可变参数数组，并将两个 T 实例传到 toArray 。 这些代码配置了 一个类型为 Object[ ]的数组，这是确保能够保存这些实例的最具体的类型，无论在调用时给 pickTwo 传递什么类型的对象都没问题 。toArray 方法只是将这个数组返回给 pickTwo ，反过来也将它返回 给其调用程序，因 此 pickTwo 始终都会返回一个类型为 Object[]的数组 。
允许另一个方法访问一个泛型可变参数数组是不安全的 ，有两种情况例外 ： 将数组传给另一个用＠ SafeVarargs 正确注解过的可变参数方法是安全的，将数组传给只计算数组内容部分函数的非可变参数方法也是安全的 。
确定何时应该使用 SafeVarargs 注解的规则很简单 ： 对于每一个带有泛型可变参数或者参数化类型的方法，都要用＠ SafeVarargs 进行注解，这样它的用户就不用承受那些无谓的、令人困惑的编译警报了 。
每当编译器警告你控制 的某个带泛型可变参数的方法可能形成堆污染，就应该检查该方法是否安全 。 这里先提个醒，泛型可变参数方法在下列条件下是安全的 ：
- 它没有在可变参数数组中保存任何值 。
- 它没有对不被信任的代码开放该数组（或者其克隆程序） 。
以上两个条件只要有任何一条被破坏，就要立即修正它 。
注意，SafeVarargs 注解只能用在无法被覆盖的方法上，因为它不能确保每个可能的覆盖方法都是安全的 。 在 Java 8 中，该注解只在静态方法和 final实例方法中才是合法的；在 Java 9 中，它在私有的实例方法上也合法了 。
总而言之，可变参数和泛型不能良好地合作，这是因为可变参数设施是构建在顶级数组之上的一个技术露底，泛型数组有不同的类型规则 。 虽然泛型可变参数不是类型安全的，但它们是合法的 。 如果选择编写带有泛型（或者参数化）可变参数的方法，首先要确保该方法是类型安全的，然后用＠SafeVarargs 对它进行注解，这样使用起来就不会出现不愉快的情况了 。