Understanding Java Integer Caching and the Pitfalls of Using == vs equals

Alibaba's development handbook (section 4) states that all comparisons between integer wrapper objects must use equals rather than ==, because values outside the -128 to 127 range are not cached and result in distinct objects.

The following code illustrates the behavior:

public class IntegerTest {
    public static void main(String[] args) {
        Integer a = 100, b = 100, c = 200, d = 200;
        System.out.println(a == b);
        System.out.println(c == d);
    }
}

Output:

true
false

Only integers within the cache range are identical with ==. The source of this behavior is the Integer.valueOf method, which returns a cached instance when the value lies between IntegerCache.low and IntegerCache.high:

public static Integer valueOf(int i) {
    if (i >= IntegerCache.low && i <= IntegerCache.high)
        return IntegerCache.cache[i + (-IntegerCache.low)];
    return new Integer(i);
}

Developers can enlarge the cache by setting the JVM option -XX:AutoBoxCacheMax=<size>, which changes IntegerCache.high. After increasing the limit, the same test prints true for both comparisons.

To see how the compiler translates the code, you can use IDEA's external tool integration to run javap -c on the compiled class. Configure the tool with the JDK's javap path, arguments -c $FileNameWithoutExtension$.class, and the working directory $OutputPath$/$FileDirRelativeToSourcepath$. The decompiled bytecode shows that each assignment to an Integer variable invokes Integer.valueOf (lines 2, 8, 15, 22).

Similar caching behavior exists for other wrapper types such as Character, Long, and Short, which you can explore by decompiling their classes in the same way.