Understanding Java Integer Caching and Autoboxing: When == Can Mislead

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

Consider the following code snippet:

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);
    }
}

The output is:

true
false

The reason is that the JVM caches Integer objects only for values between -128 and 127. Values outside this range are allocated on the heap, so == compares references and returns false.

The caching logic resides in Integer.valueOf(int i):

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 upper bound with the JVM option -XX:AutoBoxCacheMax=<size>, which changes IntegerCache.high and can improve performance when frequently using large constant Integers.

To see the exact bytecode, you can use IDEA's external tool configuration to run javap -c on the compiled class. The relevant bytecode lines (2, 8, 15, 22) invoke Integer.valueOf, confirming that autoboxing always calls this method.

/Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/bin/javap -c IntegerTest.class
Compiled from "IntegerTest.java"
public class com.github.codedrinker.basic.IntegerTest {
  public com.github.codedrinker.basic.IntegerTest();
    Code:
       0: aload_0
       1: invokespecial #1 // Method java/lang/Object."<init>":()V
       4: return

  public static void main(java.lang.String[]);
    Code:
       0: bipush 100
       2: invokestatic #2 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
       5: astore_1
       6: bipush 100
       8: invokestatic #2 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
      11: astore_2
      12: sipush 200
      15: invokestatic #2 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
      18: astore_3
      19: sipush 200
      22: invokestatic #2 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
      25: astore 4
      27: getstatic #3 // Field java/lang/System.out:Ljava/io/PrintStream;
      30: aload_1
      31: aload_2
      32: if_acmpne 39
      35: iconst_1
      36: goto 40
      39: iconst_0
      40: invokevirtual #4 // Method java/io/PrintStream.println:(Z)V
      43: getstatic #3 // Field java/lang/System.out:Ljava/io/PrintStream;
      46: aload_3
      47: aload 4
      49: if_acmpne 56
      52: iconst_1
      53: goto 57
      56: iconst_0
      57: invokevirtual #4 // Method java/io/PrintStream.println:(Z)V
      60: return
}

The same caching behavior applies to other wrapper types such as Character, Long, and Short, which also have their own cache ranges.

Understanding this mechanism helps avoid subtle bugs in Java code and can be leveraged for performance tuning.