Integer判断相等，到底该用==还是equals

在项目中涉及到整数判断的时候一直都是使用"=="进行判断的，但是用的时候心里老是在犯嘀咕，是不是应该使用equals呀？今天来看下这个问题！

在Object类中，equals方法的定义是这样的，

public boolean equals(Object obj) {
    return (this == obj);
}

可见在Object类中中，equals()和"=="是等价的，但是在大部分的包装类中，都重写了equals()方法，所以两者还是有区别的。总的来说"=="是一个关系运算符，如果比较的两端都为原生数据类型，则表示判断两者的值是否相等，如果比较的两端都为引用类型，则比较两者所指向对象的地址是否相同；对于equals()方法，如果这个对象所在的类重写了equals方法，则按照重写的方法进行比较，如果没有，则比较两者所指向对象的地址是否相同,其实就是使用"=="进行比较。

下面就对上面的论述进行测试。

 public class Test {
     public static void main(String[] args) {
         Integer a = new Integer(200);
         Integer b = new Integer(200);
         Integer c = 200;
         Integer e = 200;
         int d = 200;

         System.out.println("a == b -> " + (a == b));
         System.out.println("a.equals(b) -> " + a.equals(b));
         System.out.println("a == c -> " + (a == c));
         System.out.println("a.equals(c) -> " + (a.equals(c)));
         System.out.println("c == e -> " + (c == e));
         System.out.println("c.equals(e) -> " + (c.equals(e)));
         System.out.println("d == a -> " + (d == a));
         System.out.println("a.equals(d) -> " + (a.equals(d)));
         System.out.println("d == c -> " + (d == c));
         System.out.println("c.equals(d) -> " + (c.equals(d)));
     }
 }

运行结果

a == b -> false
a.equals(b) -> true
a == c -> false
a.equals(c) -> true
c == e -> false
c.equals(e) -> true
d == a -> true
a.equals(d) -> true
d == c -> true
c.equals(d) -> true

a == b -> false:对于两个new出来的Integer对象，因为每次使用new关键字都会在堆内存中开辟一块空间，存放相应的对象的值，然后在栈内存中存放这块内存地址的引用。而==运算符比较两者所指向对象的地址是否相同，申请了两块空间，地址肯定不相同，所以结果为false。
a.equals(b) -> true:结果为true，查看Integer源码我们发现重写的equals方法是这样的：

public boolean equals(Object obj) {
    if (obj instanceof Integer) {
        return value == ((Integer)obj).intValue();
    }
    return false;
}

首先判断传进来的Object类型是不是Integer类的一个实例，如果不是直接返回false；如果是则判断两者的成员变量value值是不是相等的(Integer类中定义的private final int value)，这块又回到了基本类型的比较("==")。value的值在创建这个对象的时候被赋值，两个Integer对象传递的参数都为200，所以value值相等，返回true。

代码的第5行Integer c = 200用int给Integer赋值，因为从jdk5开始java引入了自动装箱、自动拆箱机制。第5行就是一个自动装箱的过程，相当于：Integer c = Integer.valueOf(200);在Integer类中，valueOf方法是这么实现的：

/**
 * Returns an {@code Integer} instance representing the specified
 * {@code int} value.  If a new {@code Integer} instance is not
 * required, this method should generally be used in preference to
 * the constructor {@link #Integer(int)}, as this method is likely
 * to yield significantly better space and time performance by
 * caching frequently requested values.
 *
 * This method will always cache values in the range -128 to 127,
 * inclusive, and may cache other values outside of this range.
 *
 * @param  i an {@code int} value.
 * @return an {@code Integer} instance representing {@code i}.
 * @since  1.5
 */
public static Integer valueOf(int i) {
    if (i >= IntegerCache.low && i <= IntegerCache.high)
        return IntegerCache.cache[i + (-IntegerCache.low)];
    return new Integer(i);
}

上面这段代码首先规定了一个范围，默认是-128-127之间，如果参数中的i在这个范围内，则返回一个数组中的内容，如果不在这个范围，则new一个新的Integer对象并返回。查看Integer类的源码可以发现，这个数组里面缓存了基本类型-128-127之间的Integer对象。但是由于第11行是与一个new出来的对象做比较，所以==肯定返回的false。

第12行，equals方法比较两个对象的value值，所以为true。
第13行，两个自动装箱的变量，但是装箱传递的值大于127，都new了一个Integer对象，所以返回false。如果装箱传递的值在-128到127之间，结果为true。
第14行，结果为true。两个自动装箱的Integer对象，比较value。
第15行，这块进行比较的时候，会对Integer对象进行自动拆箱，也就是调用intValue方法。两个基本数据类型进行==判断，根据值比较，所以结果为true。这块可能有人会问，为什么不是对int类型进行自动装箱处理呢？其实这块是java根据一个很明显的道理进行设计的：如果有人比较一个int类型的值和Integer类型的值，是想比较什么呢？肯定是值呀，所以这块是对Integer对象进行拆箱而不是对int类型装箱了。
第16行这块，首先调用equals方法的肯定是Integer对象，但是Integer类中重写的equals方法参数是一个Object类型呀，怎么能传递一个基本数据类型进去呢？所以，这块又有一个自动装箱的操作，当传递一个int类型给equals这个方法时，java会自动将这个值装箱为Integer类，而Integer类的最终父类又是Object，所以这块参数的问题就解决了，然后就是两个Integer对象进行equals判断，返回true。
第17行，首先d为一个基本类型int，c为一个Integer对象，所以进行==比较的时候，肯定会对Integer对象进行拆箱处理，所以结果为true。
第18行，同第16行。