Java 中 Varargs 机制详解
新的J2SE 1.5版本提供了“Varargs”这一机制。使用该机制可以定义能和多个实参相匹配的形参。从而可以用一种更简单的方式，来传递个数可变的实参。本文介绍这一机制的使用方法，以及这一机制与数组、泛型、重载之间的相互作用时的若干问题。
（西安芯学苑http://www.029xhl.com/）
在原来J2SE 1.4版本之前，Java程序一直无法定义实参个数可变的方法——因为Java要求实参(Arguments)和形参(Parameters)的数量和类 型都必须逐一匹配，而形参的数目是在定义方法时就已经固定下来了。尽管可以通过重载机制，为同一个方法提供带有不同数量的形参的版本，但是这仍然不能达到让实参数量任意变化的目的。
然而，有些方法的语义要求它们必须能接受个数可变的实参——例如著名的main方法，就需要能接受所有的命令行参数为实参，而命令行参数的数目，事先根本无法确定下来。
对于这个问题，传统上一般是采用“利用一个数组来包裹要传递的实参”的做法来应付。
用数组包裹实参
“用数组包裹实参”的做法可以分成三步：
一、为这个方法定义一个数组型的参数;
二、在调用时，生成一个包含了所有要传递的实参的数组;
三、把这个数组作为一个实参传递过去。
这种做法调用时的形式不够简单。J2SE 1.5中提供了Varargs机制，允许直接定义能和多个实参相匹配的形参。从而，可以用一种更简单的方式，来传递个数可变的实参。
Varargs的含义
大体说来，“Varargs”是“variable number of arguments”的意思。有时候也被简单的称为“variable arguments”，不过因为这一种叫法没有说明是什么东西可变，所以意义稍微有点模糊。
定义实参个数可变的方法
只要在一个形参的“类型”与“参数名”之间加上三个连续的“.”(即“…”，英文里的句中省略号)，就可以让它和不确定个实参相匹配。而一个带有这样的形参的方法，就是一个实参个数可变的方法。
例：一个实参个数可变的方法
private static int sumUp(int... values) {
}
注意，只有最后一个形参才能被定义成“能和不确定个实参相匹配”的。因此，一个方法里只能有一个这样的形参。另外，如果这个方法还有其它的形参，要把它们放到前面的位置上。
编译器会在背地里把这最后一个形参转化为一个数组形参，并在编译出的class文件里作上一个记号，表明这是个实参个数可变的方法。
例：实参个数可变的方法的秘密形态
private static int sumUp(int[] values) {
}
由于存在着这样的转化，所以不能再为这个类定义一个和转化后的方法签名一致的方法。
例：会导致编译错误的组合
private static int sumUp(int... values) {
}
private static int sumUp(int[] values) {
}
空白的问题
根据J2SE 1.5的语法，在“…”前面的空白字符是可有可无的。这样就有在“…”前面添加空白字符(形如“Object … args”)和在“…”前面不加空白字符(形如“Object… args”)的两种写法。因为目前和J2SE 1.5相配合的Java Code Conventions还没有正式发布，所以无法知道究竟哪一种写法比较正统。不过，考虑到数组参数也有“Object [] args”和“Object[] args”两种书写方式，而正统的写法是不在“[]”前添加空白字符，似乎采取不加空白的“Object… args”的写法在整体上更协调一些。
调用实参个数可变的方法
只要把要传递的实参逐一写到相应的位置上，就可以调用一个实参个数可变的方法。不需要其它的步骤。
例：可以传递若干个实参
sumUp(1, 3, 5, 7);
这种调用方法被编译器秘密转化之后的效果，则等同于这样：
例：零实参对应空数组
sumUp(new int[]{});
注意这时传递过去的是一个空数组，而不是null。这样就可以采取统一的形式来处理，而不必检测到底属于哪种情况。
处理个数可变的实参
处理个数可变的实参的办法，和处理数组实参的办法基本相同。所有的实参，都被保存到一个和形参同名的数组里。根据实际的需要，把这个数组里的元素读出之后，就可以随意了。
例：处理收到的实参们
private static int sumUp(int... values) {
int sum = 0;
for (int i = 0; i < values.length; i++) {
sum += values[i];
}
return sum;
}
转发个数可变的实参
有时候，在接受了一组个数可变的实参之后，还要把它们传递给另一个实参个数可变的方法。因为编码时无法知道接受来的这一组实参的数目，所以“把它们逐一写到该出现的位置上去”的做法并不可行。不过，这并不意味着这是个不可完成的任务，因为还有另外一种办法，可以用来调用实参个数可变的方法。
在J2SE 1.5的编译器的眼中，实参个数可变的方法是最后带了一个数组形参的方法的特例。因此，事先把整组要传递的实参放到一个数组里，然后把这个数组作为最后一个实参，传递给一个实参个数可变的方法，不会造成任何错误。借助这一特性，就可以顺利的完成转发了。
当个数可变的实参遇到泛型
J2SE 1.5中新增了“泛型”的机制，可以在一定条件下把一个类型参数化。例如，可以在编写一个类的时候，把一个方法的形参的类型用一个标识符(如T)来代表， 至于这个标识符到底表示什么类型，则在生成这个类的实例的时候再行指定。这一机制可以用来提供更充分的代码重用和更严格的编译时类型检查。
不过泛型机制却不能和个数可变的形参配合使用。如果把一个能和不确定个实参相匹配的形参的类型，用一个标识符来代表，那么编译器会给出一个“generic array creation”的错误。
重载中的选择问题
Java支持“重载”的机制，允许在同一个类拥有许多只有形参列表不同的方法。然后，由编译器根据调用时的实参来选择到底要执行哪一个方法。
传统上的选择，基本是依照“特殊者优先”的原则来进行。一个方法的特殊程度，取决于为了让它顺利运行而需要满足的条件的数目，需要条件越多的越特殊。
在引入Varargs机制之后，这一原则仍然适用，只是要考虑的问题丰富了一些——传统上，一个重载方法的各个版本之中，只有形参数量与实参数量正 好一致的那些有被进一步考虑的资格。但是Varargs机制引入之后，完全可以出现两个版本都能匹配，在其它方面也别无二致，只是一个实参个数固定，而一 个实参个数可变的情况。
遇到这种情况时，所用的判定规则是“实参个数固定的版本优先于实参个数可变的版本”。
例：实参个数固定的版本优先
public class OverloadingSampleA {
public static void main(String[] args) {
testOverloading(1);// 打印出A
testOverloading(1, 2);// 打印出B
testOverloading(1, 2, 3);// 打印出C
}
private static void testOverloading(int i) {
System.out.println("A");
}
private static void testOverloading(int i, int j) {
System.out.println("B");
}
private static void testOverloading(int i, int... more) {
System.out.println("C");
}
}
如果在编译器看来，同时有多个方法具有相同的优先权，它就会陷入无法就到底调用哪个方法作出一个选择的状态。在这样的时候，它就会产生一个 “reference to 被调用的方法名 is ambiguous”的编译错误，并耐心的等候作了一些修改，足以免除它的迷惑的新源代码的到来。
在引入了Varargs机制之后，这种可能导致迷惑的情况，又增加了一些。例如现在可能会有两个版本都能匹配，在其它方面也如出一辙，而且都是实参个数可变的冲突发生。
