Java 解惑知多少二

8. +=复合赋值问题
8. +=复合赋值问题
x+=i与x=x+i等效吗，许多程序员都会认为第一个表达式x+=i只是第二个表达式x=x+i的简写方式，但这并不准确。

Java语言规范中提到：复合赋值 E1 op= E2等价于简单赋值 E1 = (T)((E1) op (E2))，其中T是E1的类型。
复合赋值表达式自动地将所执行计算的结果转型为其左侧变量的类型。如果结果的类型与该变量的类型相同，那么这
个转型不会造成任何影响，然而，如果结果的类型比该变量的类型要宽，那么复合赋值操作符将悄悄地执行一个窄化
原生类型转换，这样就会导致结果不正确：

short x=0;  
int i = 123456;  
x +=i;  
System.out.println(x);//-7616 

使用简单的赋值方式就不会有这样的问题了，因为宽类型不能自动转换成窄的类型，编译器会报错，这时我们就会注
意到错误：x = x + i;//编译通不过

请不要将复合赋值操作符作用于byte、short或char类型的变量；在将复合赋值操作符作用于int类型的变量时，要确
保表达式右侧不是long、float或double类型；在将复合赋值操作符作用于float类型的变量时，要确保表达式右侧不
是double类型。其实一句：不要将让左侧的类型窄于右侧的数字类型。

总之，不要在short、byte或char类型的变量之上使用复合赋值操作符，因为这一过程会伴随着计算前类型的提升与计
算后结果的截断，导致最后的计算结果不正确。

9. i =++i;与i=i++;的区别

int i = 0;   
i = i++;  
System.out.println(i);  

上面的程序会输出什么？大部分会说是 1，是也，非也。运行时正确结果为0。

i=++i;相当于以下二个语句（编译时出现警告，与i=i;警告相同）：
i=i+1;
i=i;

i = i++;相当于以下三个语句：
int tmp = i;
i = i + 1;
i = tmp;
下面看看下面程序片段：

int i = 0, j = 0, y = 0;  
i++;//相当于：i=i+1;  
System.out.println("i=" + i);// i=1  
++i;//相当于：i=i+1;  
System.out.println("i=" + i);// i=2  
i = i++;//相当于：int tmp=i;i=i+1;i=tmp;  
System.out.println("i=" + i);// i=2  
i = ++i;//编译时出现警告，与i=i;警告相同。相当于：i=i+1;i=i;  
System.out.println("i=" + i);// i=3  
j = i++;//相当于：int tmp=i;i=i+1;j=tmp;  
System.out.println("j=" + j);// j=3  
System.out.println("i=" + i);// i=4  
y = ++i;//相当于：i=i+1;y=i;  
System.out.println("y=" + y);// y=5  
System.out.println("i=" + i);// i=5  

10. Integer.MAX_VALUE + 1=?

System.out.println(Integer.MAX_VALUE + 1); 

上面的程序输出多少？2147483647+1=2147483648？答案为-2147483648。
查看源码Integer.MAX_VALUE 为MAX_VALUE = 0x7fffffff；所以加1后为0x80000000，又0x80000000为整型字面常量，满了32位，且最位为1，所以字面上等于 -0，但又由于 -0就是等于0，所以-0这个编码就规定为最小的负数，32位的
最小负数就是-2147483648。
11. -1<<32=?、-1<<65=?
如果左操作数是int（如果是byte、short、char型时会提升至int型再进行位操作）型，移位操作符只使用其右操作数
的低5位作为移位长度（也就是将右操作数除以32取余）；如果左操作数是long型，移位操作符只使用其右操作数的低
6位作为移位长度（也就是将右操作数除以64取余）；

再看看下面程序片段就会知道结果：

System.out.println(-1 << 31);// -2147483648 向左移31%32=31位  
System.out.println(-1 << 32);// -1 向左移32%32=0位  
System.out.println(-1 << 33);// -2 向左移33%32=1位  
System.out.println(-1 << 1);// -2 向左移1%32=1位  
  
System.out.println(-1L << 63);// -9223372036854775808 向左移63%64=63位  
System.out.println(-1L << 64);// -1 向左移64%64=0位  
System.out.println(-1L << 65);// -2 向左移65%64=1位  
System.out.println(-1L << 1);// -2 向左移1%64=1位  
  
byte b = -1;// byte型在位操作前类型提升至int  
System.out.println(b << 31);// -2147483648 向左移31%32=31位  
System.out.println(b << 63);// -2147483648 向左移63%32=31位  
  
short s = -1;// short型在位操作前类型提升至int  
System.out.println(s << 31);// -2147483648 向左移31%32=31位  
System.out.println(s << 63);// -2147483648 向左移63%32=31位  
  
char c = 1;// char型在位操作前类型提升至int  
System.out.println(c << 31);// -2147483648 向左移31%32=31位  
System.out.println(c << 63);// -2147483648 向左移63%32=31位  

12. 一个数永远不会等于它自己加1吗？i==i+1

// 注，整型数不能被 0 除，即(int)XX/0运行时抛异常  
double i = 1.0 / 0.0;// 正无穷大  
double j = -1.0 / 0.0;// 负无穷大  
// Double.POSITIVE_INFINITY定义为：POSITIVE_INFINITY = 1.0 / 0.0;  
System.out.println(i + " " + (i == Double.POSITIVE_INFINITY));//Infinity true  
// Double.NEGATIVE_INFINITY定义为：NEGATIVE_INFINITY = -1.0 / 0.0;  
System.out.println(j + " " + (j == Double.NEGATIVE_INFINITY));//-Infinity true  
System.out.println(i == (i + 1));// true  
System.out.println(0.1f == 0.1);// false  
float f = 33554432;  
System.out.println(f + " " + (f==(f+1)));//3.3554432E7 true  

13. 自己不等于自己吗？i!=i
NaN（Not a Number）不等于任何数，包括它自身在内。

double i = 0.0/0.0;可表示NaN。

float和double类型都有一个特殊的NaN值，Double.NaN、Float.NaN表示NaN。

如果一个表达式中产生了NaN，则结果为NaN。

System.out.println(0.0 / 0.0);// NaN  
System.out.println(Double.NaN + " " + (Double.NaN == (0.0 / 0.0)));//NaN false  

14. 自动拆箱

// 為了兼容以前版本，1.5不會自動拆箱  
System.out.println(new Integer(0) == new Integer(0));// false  
// 1.4编译非法，1.5会自动拆箱  
System.out.println(new Integer(0) == 0);// true  

15. 为什么-0x00000000==0x00000000、-0x80000000== 0x80000000
为了取一个整数类型的负值，要对其每一位取反（如果是对某个十六进制形式整数求负，如：-0x00000000则直接对这
个十六进制数进行各位取反操作——但不包括前面的负号；如果是对某个十进制求负，如-0，则需先求其绝对值的十
六进制的原码后，再各位取反），然后再加1。

注：如果是对某个十进制数求负，如-1（0xffffffff），实质上按照平时求一个负数补码的方式来处理也是一样的，求某个负数的补码规则为：先求这个数绝对值的原码，然后从该二进制的右边开始向左找第一个为1的位置，最后将这个1前的各位取反（包括最高位符号位，即最高位0取反后为1），其他位不变，最终所得的二进制就为这个负数的补码，也就是最终在内存中负数所表示的形式。不过在找这个第一个为1时可能找不到或在最高位，比如-0，其绝对值为0（0x00000000）；也有可能最高位为1，比如-2147483648，其绝对值为2147483648（0x80000000），如果遇到绝对值的原码为0x00000000或0x80000000的情况下则不变，即为绝对值的原码本身。

-0x00000000的运算过程：对0x00000000先取反得到0xffffffff，再加1，-0x00000000的最后结果就为 0xffffffff+1
，其最后的结果还是0x00000000，所以-0x00000000 == 0x00000000。前面是对0x00000000求负的过程，如果是对0求负呢?先求0的十六进制形式0x00000000，再按前面的过程来即可。或者根据前面规则对0x00000000求负不变，即最后
结果还是0x00000000。

-0x80000000的运算过程：对0x80000000先取反得到0x7fffffff，再加1，-0x80000000的最后结果就为 0x7fffffff+1
，其最后的结果还是0x80000000，即-0x80000000 == 0x80000000。前面是对0x80000000求负的过程，如果是对
2147483648求负呢?先求2147483648的十六进制形式0x80000000，再按前面的过程来即可。或者根据前面规则对0x80000000求负不变，即最后结果还是0x80000000。

-0x00000001的运算过程，实质上就是求-1的补码过程，即对其绝对值的十六进制0x00000001求补码，即为0xffffffff
，即-1的补码为0xffffffff。

System.out.println(Integer.MIN_VALUE == -Integer.MIN_VALUE);// true   
/* 
 *  0x80000000取反得0x7fffffff，再加1得0x80000000，因为负数是 
 *  以补码形式存储于内存中的，所以推导出结果原码为：0x80000000， 
 *  即为-0，又因为-0是等于0的，所以不需要-0这个编码位，那就多了 
 *  一个0x80000000编码位了，所以最后就规定0x80000000为最小负数  
 */  
System.out.println(-0x80000000);// -2147483648  
/* 
 *  0x7fffffff取反得0x80000000，再加1得0x80000001，因为负数是 
 *  以补码形式存储于内存中的，所以推导出结果原码为：0xffffffff， 
*  第一位为符号位，所以最后的结果就为 -0x7fffffff = -2147483647 
 */  
System.out.println(-0x7fffffff);// -2147483647  

另外，还发现有趣现象：最大整数加1后会等于最小整数：

// MAX_VALUE = 0x7fffffff; MIN_VALUE = 0x80000000;  
System.out.println((Integer.MAX_VALUE + 1) == Integer.MIN_VALUE);// true  
// MIN_VALUE = 0x8000000000000000L; MIN_VALUE = 0x8000000000000000L;  
System.out.println((Long.MAX_VALUE + 1) == Long.MIN_VALUE);// true  

16. Math.abs结果一定为非负数吗?

System.out.println(Math.abs(Integer.MIN_VALUE));// -2147483648  

上面的程序不会输出2147483648，而是-2147483648，为什么？

其实我们看一下Math.abs源码就知道为什么了，源码：(a < 0) ? -a : a;，结合上面那个迷题，我们就发现-Integer.MIN_VALUE= Integer.MIN_VALUE，所以上面的答案就是最小整数自己。

另外我们也可以从API文档看到对Math.abs()方法的解释：如果参数等于 Integer.MIN_VALUE 的值（即能够表示的最
小负 int 值），则结果与该值相同且为负。

所以Math.abs不能保证一定会返回非负结果。

当然，Long.MIN_VALUE也是这样的。


参考：http://jiangzhengjun.iteye.com/blog/652639