Integer与int解惑

jdk1.5引入了自动装箱&＃xff08;autoboxing&＃xff09;与自动拆箱&＃xff08;unboxing&＃xff09;&＃xff0c;这方便了集合类以及一些方法的调用&＃xff0c;同时也使初学者对其感到非常之困惑。在此&＃xff0c;我们来揭开其神秘的面纱。

首先&＃xff0c;需要厘清一些概念&＃xff1a;
1、Integer是一个类&＃xff0c;用Integer声明一个变量其是一个对象类型&＃xff08;或者说引用类型&＃xff09;&＃xff1b;int是基本类型&＃xff0c;用int声明的变量是非对象类型&＃xff0c;即不能在其上调用方法。
2、“&＃61;&＃61;”作用于对象上的时候&＃xff0c;其比较的是对象的引用本身的值&＃xff08;或者说对象的地址更容易理解&＃xff09;&＃xff0c;而作用于基本类型的时候比较的就是基本类型的值。
接下来看一段代码&＃xff1a;

public class Test {public static void main(String[] args) {Integer i1 &＃61; 2;int i2 &＃61; 2;System.out.println(i1 &＃61;&＃61; i2);}
}

在这段代码中有两个令人困惑的问题&＃xff0c;首先是将一个基本类型的值赋值给对象的引用&＃xff0c;即Integer i1 &＃61;2&＃xff1b;其次是拿一个对象类型和一个基本类型比较。按理说这两种做法肯定都是有问题的&＃xff0c;在jdk1.4&＃xff08;若使用的jdk版本是1.5或之后的版本中&＃xff0c;可以使用javac -source 1.4 Test.java来编译&＃xff09;上&＃xff0c;确实如此&＃xff0c;第一个问题在编译时会报“不兼容的类型”错误&＃xff0c;第二个问题会报“运算符 &＃61;&＃61; 不能应用于 java.lang.Integer,int”的错误。
但是jdk1.5引入的自动装箱和自动拆箱&＃xff0c;那么&＃xff0c;必然要将其中的一种类型转换成另一种类型&＃xff0c;究竟是将Integer对象i1转换成int基本类型呢&＃xff1f;还是将int基本类型的i2转换成Integer对象&＃xff1f;通过javap -c Test反编译Test.class文件就知道答案了&＃xff1a;

public static void main(java.lang.String[]);
Code:
0:   iconst_2
1:   invokestatic    #2; //Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
4:   astore_1
5:   iconst_2
6:   istore_2
7:   getstatic       #3; //Field java/lang/System.out:Ljava/io/PrintStream;
10:  aload_1
11:  invokevirtual   #4; //Method java/lang/Integer.intValue:()I
14:  iload_2
15:  if_icmpne       22
18:  iconst_1
19:  goto23
22:  iconst_0
23:  invokevirtual   #5; //Method java/io/PrintStream.println:(Z)V
26:  return
}

其中&＃xff0c;[0-4]是Integer i1 &＃61; 2的实现&＃xff0c;我们发现&＃xff0c;编译的字节码里调用了Integer.valueOf方法&＃xff0c;因此Integer i1 &＃61; 2编译后就等同于Integer i1 &＃61; Integer.valueOf(2)&＃xff1b;[5,6]是int i2 &＃61; 2的实现&＃xff1b;[7,23]是System.out.println(i1 &＃61;&＃61; i2)的实现&＃xff0c;也容易看到&＃xff0c;里面调用了Integer.intValue()方法。因此&＃xff0c;这个i1 &＃61;&＃61; i2这两个不同类型的变量比较&＃xff0c;在编译的时候&＃xff0c;编译器是将其转换成相同的类型进行比较的&＃xff0c;即将对象类型转换成基本类型&＃xff0c;System.out.println(i1 &＃61;&＃61; i2)就等同于System.out.println(i1.intValue() &＃61;&＃61; i2)&＃xff0c;前面说了&＃xff0c;“&＃61;&＃61;”作用于基本类型的时候比较的就是基本类型的值&＃xff0c;两个值都是2&＃xff0c;所以结果是true。
另外一个令人困惑的例子就是&＃xff1a;

public class Test {public static void main(String[] args) {Integer i1 &＃61; 127;Integer i2 &＃61; 127;System.out.println(i1 &＃61;&＃61; i2);Integer i3 &＃61; 128;Integer i4 &＃61; 128;System.out.println(i3 &＃61;&＃61; i4);}
}

运行后发现&＃xff0c;i1&＃61;&＃61;i2的结果为true&＃xff0c;i3&＃61;&＃61;i4的结果为false&＃xff1f;这令不知原因的人头疼不已。在前面一个例子里我们已经说过&＃xff0c;诸如Integer i1 &＃61; 127&＃xff0c;在编译后就等同于Integer i1 &＃61; Integer.valueOf(127)&＃xff0c;既然是调用一个方法来获得对象&＃xff0c;那么就有必要对valueOf方法一探究竟了。我们看下源码&＃xff1a;

public static Integer valueOf(inti) {final int offset &＃61; 128;if(i <&＃61; -128 && i 127) { // must cachereturn IntegerCache.cache[i &＃43; offset];}return new Integer(i);
}

到此应该恍然大悟了&＃xff0c;IntegerCache缓存了[-128,127]之间的Integer对象&＃xff0c;如果valueOf的参数i处于这之间&＃xff0c;就返回缓存的对象。否则就new一个新的Integer。前面已经说过&＃xff0c;“&＃61;&＃61;”作用于对象上的时候&＃xff0c;其比较的是对象的地址&＃xff0c;例子中的i1和i2都是从缓存中拿的&＃xff0c;当然是同一个对象&＃xff0c;i3和i4都是通过new Integer获得的&＃xff0c;当然不是同一个对象了。
类似地&＃xff0c;java.lang.Long&＃xff0c;java.lang.Short分别缓存了[-128,127]之间的Long和Short对象&＃xff0c;java.lang.Byte缓存了所有的对象&＃xff0c;java.lang.Character缓存了[0,127]之间的Character对象。java缓存这些对象是为了性能优化&＃xff0c;既然我们已经知道其缓存了这么些对象&＃xff0c;在需要new Integer/Long/…的地方&＃xff0c;可改用Integer/Long/Short…#valueOf方法。
但是&＃xff1a;
使用Oracle/Sun JDK 6&＃xff0c;在server模式下&＃xff0c;使用-XX:AutoBoxCacheMax&＃61;NNN参数即可将Integer的自动缓存区间设置为[-128,NNN]。注意区间的下界固定在-128不可配置。
在client模式下该参数无效。这个参数是server模式专有的&＃xff0c;在c2_globals.hpp中声明&＃xff0c;默认值是128&＃xff1b;不过这个默认值在默认条件下不起作用&＃xff0c;要手动设置它的值或者是开启-XX:&＃43;AggressiveOpts参数才起作用。