🎬 Intro — “I Thought I Knew ==… Until Java Proved Me Wrong”
I was casually writing:
Integer a = 128;
Integer b = 128;
System.out.println(a == b); // Output: false ❌
…and confidently told myself:
“Yeah, that’s definitely true.”
💥 WRONG! Output: false
I was like… 🧍♂️ “Hello? Java, are you okay?”
Let's break this down, and I’ll show you what I learned — in my usual style: with humor, diagrams, dumb-but-smart questions, and gotchas!
🧪 1. Code Examples That Confused Me
✅ Primitive Comparison Works
int a = 128;
int b = 128;
System.out.println(a == b); // true ✅
➡️ Simple! Both values are 128, both stored in stack. Done.
❌ Object Comparison Fails?
Integer a = 128;
Integer b = 128;
System.out.println(a == b); // false ❌
➡️ Wait, same values, but still false?
✅ Mixed (Object + Primitive)
Integer a = 128;
int b = 128;
System.out.println(a == b); // true ✅
➡️ What? Now it works again?
🧠 2. The Root Cause: Memory Layout (With Diagram!)
Let’s see how these are stored in memory.
📦 Primitive Example:
int a = 128;
int b = 128;
📍 Stack Memory:
+--------+ +--------+
| a | 128 | b | 128
+--------+ +--------+
✅ a == b → compares 128 == 128 → ✅ true
📦 Object Example:
Integer a = 128;
Integer b = 128;
📍 Stack 🧠 Heap
+--------+ +-----------------+
| a | ─────┐ | Integer@0xABC |
+--------+ └──────▶ | value = 128 |
+-----------------+
+--------+ +-----------------+
| b | ─────┐ | Integer@0xDEF |
+--------+ └──────▶ | value = 128 |
+-----------------+
❌ a == b → compares 0xABC != 0xDEF → false
🧠 3. So What Does == Actually Do?
| Case | What == Compares |
Output |
|---|---|---|
int == int |
Primitive values | ✅ true |
Integer == Integer |
Object references (memory) | ❌ false |
Integer == int |
Auto-unboxed to primitive | ✅ true |
🧠 Java is smart! It decides based on types at compile time:
- Primitives? → Compare values
- Objects? → Compare reference (i.e., memory address)
- Mix? → Unbox object → Compare values
🧵 4. What About Small Numbers?
Integer a = 127;
Integer b = 127;
System.out.println(a == b); // ✅ true
😲 Surprise! This one is true. Why?
🔥 5. Behind-the-Scenes: Integer Caching!
Integer a = 127;
Integer b = 127;
Java caches values from -128 to 127. These are reused from a common pool:
IntegerCache:
-128 → memory@100
...
127 → memory@300
So a == b → both point to memory@300 → ✅ true
🚧 6. Gotchas & Surprises
Integer a = 127;
Integer b = 127;
System.out.println(a == b); // ✅ true
Integer x = 128;
Integer y = 128;
System.out.println(x == y); // false ❌
✅ Because 128 is outside the cache range, Java creates new objects.
Want to increase the cache?
-Djava.lang.Integer.IntegerCache.high=256
🧠 Where is the Integer Cache (-128 to 127) Stored — Stack or Heap?
✅ Answer:
👉 In the Heap — specifically as part of the IntegerCache class inside the Integer class.
📦 What exactly happens?
When you write:
Integer a = 100;
Integer b = 100;
System.out.println(a == b); // ✅ true
Java does not create a new object every time for small values (from -128 to 127). Instead, it returns a pre-cached object stored in a static array.
🔍 Internally:
private static class IntegerCache {
static final Integer cache[] = new Integer[-(-128) + 127 + 1];
static {
for (int i = 0; i < cache.length; i++)
cache[i] = new Integer(i - 128);
}
}
- This static
cache[]is initialized once. - These objects live in the heap memory (because they're part of class static fields).
- So when you do
Integer.valueOf(100), Java gives you a reference tocache[100 + 128].
💾 Memory Layout:
Stack (Thread Local)
┌────────────┐
│ Integer a │──┐
└────────────┘ │
┌────────────┐ │
│ Integer b │──┘
└────────────┘
Heap (Shared)
┌────────────────────────┐
│ IntegerCache.cache[] │
│ ┌────┬────┬────┐ │
│ │... │100 │101 │... │ ← 🧠 shared, reused
│ └────┴────┴────┘ │
└────────────────────────┘
Both a and b point to the same Integer object in the heap when the value is within the cached range.
🔥 What happens outside the range?
Integer x = 128;
Integer y = 128;
System.out.println(x == y); // ❌ false
Integer.valueOf(128) creates new objects, not from the cache.
💡 Fun Fact:
You can change the cache range at JVM startup (not recommended):
-Djava.lang.Integer.IntegerCache.high=255
That would cache from -128 to 255.
🧵 Summary:
| Feature | Location |
|---|---|
Integer a = 100; |
Stack (reference) |
IntegerCache.cache[] |
Heap (actual cached objects) |
| Value outside cache | Heap (new object each time) |
🧃 7. The Dumb Questions That Actually Matter
| Question ❓ | Answer ✅ |
|---|---|
Is == always reference compare? | ❌ No — depends on types |
Are int and Integer treated same? | ❌ Nope, one is primitive, one is object |
| Why is 127 working, 128 not? | Because of Integer cache (−128 to 127) |
Why does Integer == int work? | Java auto-unboxes the object to compare values |
| Are object references in stack? | ✅ Yes! But they point to heap objects |
Is there heap involved in int a = 128? | ❌ No. Only stack — just raw value |
📜 8. Final Rules to Live By (with Emojis 😎)
- 🔹
int == int→ ✅ compares values - 🔹
Integer == Integer→ ❌ compares references - 🔹
Integer == int→ ✅ unboxes & compares values - 🔹 Use
.equals()to compare objects safely - 🔹 Don't rely on
==unless you're 100% sure of what you're comparing - 🔹 Java caches small Integers (−128 to 127) — don’t assume it for all values
🧑💻 9. Developer Tip 💬
"If you're not sure whether you're holding a value or a reference, you're probably comparing the wrong thing with ==."
🎁 Wrapping Up
This one line of code taught me more about Java memory, references, unboxing, and compiler behavior than most tutorials ever did.
The next time you write:
if (a == b)
Ask yourself:
🧠 Are you comparing values or just hoping they're pointing to the same object?
📢 Over to You!
- 👨💻 Have you ever been shocked by a
==behaving weirdly? - 😱 Ever wasted 2 hours debugging a bug that was just a reference comparison?
Comments
Post a Comment