Why `1 == 1` is True but `128 == 128` is False in Java — The Integer Caching Trap Explained

Ever written a simple Java comparison like Integer a = 128; Integer b = 128; and got surprised that a == b returned false? 🤯 You're not alone.

Let’s unravel this fascinating corner of the Java language where autoboxing, object pooling, and reference comparison collide in unexpected ways.

Why does Java produce different results for 1 == 1 and 128 == 128?

Integer a = 128;
Integer b = 128;
System.out.println(a == b); // false
 
Integer x = 1;
Integer y = 1;
System.out.println(x == y); // true

At first glance, both a and b are Integer objects with the same value. So why does a == b return false, while x == y returns true?

Short Answer:

Java caches Integer objects from -128 to 127. Outside that range, new objects are created — even if the values are the same.

How does Java's Integer caching mechanism work?

In Java, Integer is a wrapper class, and assigning int to Integer uses autoboxing. When you do:

Integer x = 1;

Java checks if that number is in the cache. If it is, it reuses the object. This makes:

Integer x = 1;
Integer y = 1;
System.out.println(x == y); // true ✅

Because both point to the same object in memory.

But if the value is outside -128 to 127:

Integer a = 128;
Integer b = 128;
System.out.println(a == b); // false ❌

New Integer objects are created each time, so a and b point to different memory locations.

How should you compare Integer objects in Java?

Unlike == which checks reference equality, .equals() compares the actual values:

Integer a = 128;
Integer b = 128;
System.out.println(a.equals(b)); // true ✅

Always use .equals() when comparing wrapper objects or values from unknown sources.

Can you customize the Integer cache range in Java?

You can tweak the cache range by setting a JVM option:

-XX:AutoBoxCacheMax=256

This increases the upper bound of cached values. Note: this works only for Integer, not other wrappers.

🔬 Memory Check Example with System.identityHashCode()

To prove that cached and non-cached Integers are different objects:

Integer c = 128;
Integer d = 128;
System.out.println(System.identityHashCode(c));
System.out.println(System.identityHashCode(d));
 
Integer e = 1;
Integer f = 1;
System.out.println(System.identityHashCode(e));
System.out.println(System.identityHashCode(f));

You'll observe that:

• c and d have different hash codes (not cached)
• e and f have same hash code (cached)

Why does Integer caching matter in real-world Java projects?

This behavior can cause hard-to-find bugs when developers rely on == for wrapper classes. Some common issues:

• Comparing response values from APIs or databases
• Conditional logic failures in object comparisons
• Test assertions failing unexpectedly

When should you use .equals() instead of == in Java?

Use .equals() when comparing:

• Boxed types (Integer, Long, etc.)
• Objects from user input or external systems

Use == only when:

• Comparing primitives (int, long, etc.)
• Checking for exact same object instance (rare)

What should every Java developer know about Integer caching?

• Java caches Integer values from -128 to 127.
• == compares references, not values.
• .equals() is the correct way to compare object values.
• Autoboxing can introduce subtle bugs if not understood well.

Did this save you from a bug? Hit that bookmark or share it with your Java buddies!

Want more Java mysteries decoded? Follow me on GitHub or connect on Instagram. ☕

For the official specification, see the Java Language Specification §5.1.7 on Boxing Conversion and the Integer.valueOf() Javadoc.

Keep Reading

• Top Java Interview Questions for 2025 — This kind of JVM trivia is exactly what interviewers love to ask about.
• Java 25 Compact Object Headers — Dive deeper into how Java represents objects in memory at the JVM level.