Integer Cache in Java

Here's a famous Java puzzle: two Integer variables holding 127 are ==, but two holding 128 are not. Nothing is wrong with the numbers. == on objects compares references, and Java keeps a ready-made cache of Integer objects for small values. Inside the cache range, boxing the same value always returns the same object; outside it, every boxing creates a new one.

The Puzzle

public class Cache {
    public static void main(String[] args) {
        Integer a = 127, b = 127;
        Integer c = 128, d = 128;
        System.out.println(a == b);
        System.out.println(c == d);
        System.out.println(c.equals(d));
        System.out.println(c.intValue() == d.intValue());
 
        Long x = 127L, y = 127L;
        Double p = 1.0, q = 1.0;
        System.out.println(x == y);
        System.out.println(p == q);
    }
}

true
false
true
true
true
false

How it works

1. Integer a = 127 compiles to Integer.valueOf(127). For values from -128 to 127, valueOf returns an object from a cache built when Integer loads, so a and b refer to the same object: true.
2. 128 is outside the cache, so each valueOf(128) creates a new object: c == d is false.
3. equals compares values: true. Comparing unboxed ints also works.
4. Long has the same -128 to 127 cache. Double has no cache, so even 1.0 == 1.0 on Double objects is false.

Inside the Cache

Integer.valueOf looks like this (simplified from the JDK source):

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

The cache is safe to share because Integer objects are immutable. It saves memory and time for the small numbers programs use most.

The upper limit for Integer can be raised with a JVM option, for example java -XX:AutoBoxCacheMax=1000 Cache; then c == d above prints true. That's a curiosity, not a fix: code must never depend on it.

Why This Matters in Real Code

The bug usually hides in tests: ids, quantities and counts in test data are small, so == passes; in production, with values like 4500, it fails.

Integer expected = order.getQuantity();
Integer actual = shipment.getQuantity();
if (expected == actual) {           // true for 50, false for 500
    markComplete();
}

Common Mistakes

Using == on Integer, Long or other wrappers. Use equals or Objects.equals.

Trusting tests that use small numbers. The cache hides the bug until values exceed 127.

Writing new Integer(5). The constructor is deprecated for removal; use Integer.valueOf(5) or autoboxing.

Interview Corner

Practice

1. Easy: Predict, then check: Integer.valueOf(100) == Integer.valueOf(100) and Integer.valueOf(1000) == Integer.valueOf(1000).
2. Harder: Write a loop from 120 to 135 that boxes i twice and prints where == stops being true.

Key Takeaways