Integer示例程序反编译代码的分析，附带“==”的再次理解

Integer属于包装类，int属于基本数据类型，初始化时，int赋值默认为0，Integer默认指向null。
创建对象时，可以写成
1. Integer a = 128;
2. Integer b = new Integer(128);
我们都知道，String也可以写成这两种方式，但是对于String来说，这两种写法是不一样的；而这里对于包装类来说，这两种写法是的效果是完全一样的，等同于Integer b = new Integer(128);，这一点可以通过查看class文件反编译结果看出：
反编译1. Integer a = Integer.valueOf(128);
反编译2. Integer b = new Integer(128);
为什么说等同于Integer b = new Integer(128)呢？因为valueOf()方法是这样写的：

 public static Integer valueOf(int i) {
        final int offset = 128;
        if (i >= -128 && i <= 127) { // must cache 
         return IntegerCache.cache[i + offset];
        }
        return new Integer(i);
        }    

这两种方法到底都是要创建Integer对象，这时就是跟普通对象一样的性质，每new一个出来，其地址绝对独一无二，用==判断肯定输出false，因此，此处判断boolean flag = (a==b);输出false。但是！！！！这是在a,b的值在-128~127这个范围外的情况下。

反过来另一种情况就是-128~127范围内的Integer值，他们不需new对象出来，return IntegerCache.cache[i + offset];他们是将Integer标识符直接指向byte的常量池对应数据的地址，因此这个范围内只要值相等，那么地址也就相等，所以用==判断就会输出true。

在思考这个问题的时候，想到判断两个变量的内存地址是否相同，能否调用hashcode()方法呢？在此前操作时，hashcode方法返回的都是对象的地址呀。可是此处不行！查看源码可以看到hashcode方法重写为等同于当前变量所赋的值，也就是说不能反悔地址值，所以不能想当然。那么这一下让我反省到了一个错误认识，hashcode不能代表对象的地址，其实和地址并没有必然关系，不同的类重写此方法后代表的意义不一样，总之每个普通类（目前知道Integer指向常量池例外），只要new出来了就具有独一无二的地址，==比较的是内容和地址，不能说内容相同，hashcode相同==就输出true了，这是错误的。

类似的类还是其他的包装类，Byte，Float等等