java 可变参数列表
我要评论
public class parameter {
static void printarray(object[] args){
for(object obj : args){
system.out.print(obj + " ");
}
system.out.println();
}
public static void main(string[] args){
printarray(new object[] {
new integer(47), new float(3.14), new double(11.11)
});
printarray(new object[]{"one", "two", "there"});
printarray(new object[]{new a(), new a(), new a()});
}
}
对于java se5之后版本添加了特性可以如此写：
public class parameter {
public static void printarray(object... args){
for(object obj : args){
system.out.print(obj + " ");
}
system.out.println();
}
public static void main(string[] args){
printarray(new integer(47), new float(3.14), new double(11.11));
printarray(47, 3.14f, 11.11);
printarray("one", "two", "three");
printarray(new a(), new a(), new a());
printarray((object[]) new integer[]{1, 2, 3, 4});
printarray();
}
}
可以使用object以为的参数列表：
public class varargtype{
static void f(character... args){
system.out.print(args.getclass());
system.out.println(" length " + args.length);
}
static void g(int... args){
system.out.print(args.getclass());
system.out.println(" length " + args.length);
}
public static void main(string[] args){
f('a');
f();
g(1);
g();
system.out.println(" int [] " + new int[0].getclass());
}
}
这是 java 5 引入的一个特性，如果一个方法要接收的参数数量是不确定的，那么这个特性就可以派上用场了。
比如，在涉及io操作的地方，基本上至少需要关闭两个流：输入、输出，我喜欢把流关闭的操作封装成下面的方法，这样只需一次调用就可以关闭多个流。
public static void closesilent(closeable... closeables) {
for (closeable closeable : closeables) {
if (closeable != null) {
try {
closeable.close();
} catch (ioexception ignored) {
}
}
}
}
这是我觉得这个特性唯一适合使用的地方，具备下面的特点：
这些参数具有相同的类型；
参数数量不确定，每一个都是可选的；
这些参数的用途都是一样的，比如上面都是执行关闭。
java 可变长参数列表只能放在方法参数列表的最后。
java可变长参数列表的实现
java可变长参数列表的实现是通过编译器把把这些参数封装成一个数组来传递的。
比如上面的方法的签名实际上是： closesilent(closeable[] closeables) void 。
踩坑
有个方法，被 a、b 两个地方 a、b 调用，9 月，在 a 这里需要增加一个参数，当时脑子一抽疯，决定用可变长参数列表，觉得 b 那里不用改简单点，坑就这样埋下了。
最近要求 b 这里要新增两个参数，那就在方法的参数列表里继续加参数，这些参数的类型是不同的，所以可变长参数列表声明成 object 类型的。
第一个坑就是在这个方法内取可变长参数的元素时，没考虑到有的参数是没传的，直接爆数组越位的异常了。马上就觉得可变长参数列表的不好了，那就不用了呗，改为常规的固定形式的参数传递。
改完之后，在测试环境测了都没问题。把生产环境的几个类替换之后，结果却报错了，方法找不到，一看方法签名，还是数组的，没有替换到。从源码看，那个调用的地方不需要更改，所以没想到要替换；由于测试环境是全量打包，所以不会出现问题。
方法的签名是在编译的时候就确定了的，源码层面看起来不需要改的不表示编译后的类也不需要替换了。
其实以前也听到过，在这种发包不规范的情况下，把源码里的一个常量值改了之后，只替换了这个定义常量的类文件，没有把所有引用这个常量的类文件重新编译替换，导致出现莫名其妙的问题。跟方法签名的情况本质上是一样的问题。
如对本文有疑问， 点击进行留言回复！！
集合框架——Map、泛型以及Collection算法常用方法
Elasticsearch 升级 7.x 版本后，我感觉掉坑里了
Mybatis的插件运行原理以及如何编写一个Mybatis的插件
网友评论