Object Identity — The Concept of Same Memory Location - Object Identity, Equality, and Hashing | OneNoughtOne

0/290

System Design (LLD)Object Identity, Equality, and Hashing

Object Identity, Equality, and Hashing

LevelIntermediate

Duration60 mins

TopicObject Identity, Equality, and Hashing

1 / 4

Object Identity — The Concept of Same Memory Location

When 'Same' Is Not 'Equal'

Consider this scenario: You create two Person objects with identical names, ages, and addresses. Are they the same person? In the physical world, two people with identical attributes are clearly different individuals. In software, the answer depends on what you mean by 'same'—and getting this distinction wrong is one of the most common sources of subtle, hard-to-debug errors in object-oriented systems.

This page explores object identity—the concept of two references pointing to the exact same location in memory. It's the first of three fundamental concepts (identity, equality, and hashing) that every software engineer must master to build correct, maintainable systems.

What You Will Learn

By the end of this page, you will understand: (1) What object identity means at the memory level, (2) How identity differs from equality, (3) How different programming languages handle identity checks, (4) Common bugs caused by confusing identity with equality, and (5) When to use identity vs equality comparisons in your code.

Understanding Object References

Before we can understand identity, we need to understand what happens when you create an object in memory. In most object-oriented languages, when you declare an object variable, you're not storing the object itself—you're storing a reference (or pointer) to where that object lives in memory.

The Memory Model:

Think of computer memory as a vast warehouse with numbered storage bins. When you create an object, the runtime:

Finds an empty bin (allocates memory)
Stores the object's data in that bin
Returns the bin's address (the reference)
Your variable holds this address, not the contents

This reference-based model has profound implications for how we compare objects.

ReferenceDemo.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// When we write this:
Person alice = new Person("Alice", 30);
Person bob = new Person("Bob", 25);
 
// Memory looks like this:
//
// Stack (Variables)          Heap (Objects)
// ┌─────────────┐            ┌─────────────────────────────┐
// │ alice: 0x1A │ ──────────▶│ Address: 0x1A               │
// └─────────────┘            │ name: "Alice"               │
//                            │ age: 30                     │
// ┌─────────────┐            └─────────────────────────────┘
// │ bob:   0x2B │ ──────────▶┌─────────────────────────────┐
// └─────────────┘            │ Address: 0x2B               │
//                            │ name: "Bob"                 │
//                            │ age: 25                     │
//                            └─────────────────────────────┘
//
// The variables 'alice' and 'bob' hold memory addresses,
// not the actual Person data.

The Postal Address Analogy

Think of object references like postal addresses. The address '123 Main Street' isn't the house itself—it's a way to locate the house. Multiple people can have the same address written on different pieces of paper, but there's still only one house. Similarly, multiple variables can reference the same object in memory.

What Is Object Identity?

Object identity answers a specific question: Do these two references point to the exact same object in memory?

Not 'Do they have the same values?' or 'Do they represent the same real-world entity?'—but literally, 'Are they the same block of memory?'

Formal Definition:

Two object references a and b are identical if and only if they contain the same memory address—meaning any modification through a would be visible through b, because they're different names for the same underlying object.

This is the strictest form of 'sameness.' Objects with exactly the same attribute values are not identical unless they're literally the same object.

IdentityDemo.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
public class IdentityDemo {
    public static void main(String[] args) {
        // Create one object, assign to two variables
        Person alice1 = new Person("Alice", 30);
        Person alice2 = alice1;  // Same reference copied
        
        // Create another object with same values
        Person alice3 = new Person("Alice", 30);
        
        // Memory visualization:
        //
        // alice1: 0x1A ────┐
        //                  │
        //                  ▼
        //            ┌─────────────┐
        //            │ name: Alice │  ◀── ONE object in memory
        //            │ age: 30     │
        //            └─────────────┘
        //                  ▲
        //                  │
        // alice2: 0x1A ────┘
        //
        // alice3: 0x2B ───────────▶ ┌─────────────┐
        //                          │ name: Alice │  ◀── DIFFERENT object
        //                          │ age: 30     │
        //                          └─────────────┘
        
        // Identity checks (comparing memory addresses)
        System.out.println(alice1 == alice2);  // true  - same object
        System.out.println(alice1 == alice3);  // false - different objects
        
        // Proof of identity: mutual modification
        alice1.setAge(31);
        System.out.println(alice2.getAge());   // 31 - change visible!
        System.out.println(alice3.getAge());   // 30 - unchanged
    }
}

Key Characteristics of Identity

•Same Memory Address — Identical objects share the exact same location in the heap.
•Mutual Modification — Any change through one reference affects all references to that object.
•Reflexive — An object is always identical to itself (a == a is always true).
•Symmetric — If a == b, then b == a (identity is bidirectional).
•Transitive — If a == b and b == c, then a == c (identity chains).
•Consistent — Identity never changes during an object's lifetime—same address forever.

Identity Operators Across Languages

Different programming languages express identity checks differently. Understanding these differences is essential when working across language boundaries or reviewing unfamiliar code.

The Common Thread: All these operators compare memory addresses, not values.

Identity Operators by Language
Language	Identity Operator	Example	Notes
Java	==	obj1 == obj2	For objects only; primitives use value comparison
Python	is	obj1 is obj2	Clear distinction from == (equality)
C#	object.ReferenceEquals()	ReferenceEquals(a, b)	Can also use == if not overloaded
JavaScript	===	obj1 === obj2	Compares references for objects
C++	== on pointers	ptr1 == ptr2	Compare pointer addresses directly
Ruby	equal?	obj1.equal?(obj2)	Distinct from == and eql?
Go	== on pointers	a == b	Need to compare pointer values
Kotlin	===	obj1 === obj2	Referential equality operator

identity_python.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
# Python's 'is' operator checks identity
# Python's '==' operator checks equality
 
class Person:
    def __init__(self, name, age):
        self.name = name
        self.age = age
    
    def __eq__(self, other):
        # Equality: same values
        return self.name == other.name and self.age == other.age
 
alice1 = Person("Alice", 30)
alice2 = alice1               # Same reference
alice3 = Person("Alice", 30)  # Different object, same values
 
# Identity checks with 'is'
print(alice1 is alice2)   # True  - same object in memory
print(alice1 is alice3)   # False - different objects
 
# Equality checks with '=='
print(alice1 == alice2)   # True  - same values (same object)
print(alice1 == alice3)   # True  - same values (different object)
 
# The critical difference:
# 'is' asks: "Are these the same box?"
# '==' asks: "Do these boxes contain equivalent things?"

The Java String Trap

In Java, using == on strings can produce confusing results due to string interning. "hello" == "hello" returns true (interned), but new String("hello") == new String("hello") returns false. This catches countless developers. Always use .equals() for string comparison in Java.

Identity vs. Equality — The Fundamental Distinction

This is the central concept of this entire module: Identity and equality are different concepts that answer different questions.

Question	Concept	Metaphor
Are these the same box?	Identity	Two labels on one box
Do these boxes contain equivalent things?	Equality	Two boxes with identical contents

Identity is physical sameness—one object viewed through different lenses. Equality is logical equivalence—different objects that should be treated as interchangeable for some purpose.

Why This Matters:

The distinction directly affects program behavior in collections, caching, comparisons, and virtually every non-trivial software system.

Identity (Same Memory)

•One object, multiple references
•Modifications shared across all references
•Fastest possible comparison (address check)
•Cannot be overridden or customized
•Asks: 'Same physical thing?'

Equality (Same Value)

•Different objects, logically equivalent
•Modifications independent
•Comparison cost depends on object complexity
•Programmer-defined behavior
•Asks: 'Logically interchangeable?'

IdentityVsEquality.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
public class IdentityVsEquality {
    public static void main(String[] args) {
        // Scenario 1: Same object (identity implies equality)
        Money m1 = new Money(100, "USD");
        Money m2 = m1;
        
        // If identical, always equal
        assert m1 == m2;        // Identity: true
        assert m1.equals(m2);   // Equality: true (trivially)
        
        // Scenario 2: Different objects, equal values
        Money m3 = new Money(100, "USD");
        Money m4 = new Money(100, "USD");
        
        // Not identical, but should be equal
        assert m3 != m4;        // Identity: false (different objects)
        assert m3.equals(m4);   // Equality: true (same value)
        
        // Scenario 3: Different objects, different values
        Money m5 = new Money(100, "USD");
        Money m6 = new Money(200, "EUR");
        
        assert m5 != m6;        // Identity: false
        assert !m5.equals(m6);  // Equality: false
        
        // KEY INSIGHT:
        // Identity IMPLIES equality (same object = same values)
        // Equality DOES NOT IMPLY identity (same values ≠ same object)
    }
}

The Mathematical Perspective

In mathematical terms: Identity is to equality as A ⊆ B. If a == b (identity), then a.equals(b) must be true. But if a.equals(b) is true, a == b may still be false. Identity is a stricter condition that guarantees equality, but not vice versa.

Identity in Real-World Scenarios

Understanding when identity matters versus when equality matters is crucial for correct software design. Let's examine scenarios where the distinction is critical.

Scenario 1: Object Modification Propagation

When you pass an object to a method, are you passing the same object (identity preserved) or a copy (new identity)? This determines whether modifications are visible to the caller.

ModificationScenario.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public void demonstrateIdentityAndModification() {
    List<String> originalList = new ArrayList<>();
    originalList.add("A");
    
    // Pass by reference: identity preserved
    modifyList(originalList);
    System.out.println(originalList);  // [A, B] - modified!
    
    // Pass a copy: new identity, original unchanged
    List<String> copy = new ArrayList<>(originalList);
    modifyList(copy);
    System.out.println(originalList);  // [A, B] - still unchanged!
}
 
private void modifyList(List<String> list) {
    list.add("B");  // Modifies whichever object 'list' references
}
 
// The same reference (identity) means shared fate.
// A different reference (copy) means independent lives.

Scenario 2: Caching and Object Reuse

Caches often rely on identity to determine if an object is already cached. If you create a new object with the same values, the cache may not recognize it as 'the same' unless you explicitly check equality.

CachingScenario.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
public class IdentityCache<T> {
    private Set<T> cache = new IdentityHashSet<>();  // Uses identity, not equals
    
    public void cache(T object) {
        cache.add(object);
    }
    
    public boolean isCached(T object) {
        return cache.contains(object);  // Checks identity!
    }
}
 
// Usage
User user1 = new User("alice@example.com");
User user2 = new User("alice@example.com");  // Same email, different object
 
IdentityCache<User> cache = new IdentityCache<>();
cache.cache(user1);
 
cache.isCached(user1);  // true  - same object
cache.isCached(user2);  // false - different object, even though equal!
 
// When is IdentityCache useful?
// - Tracking which exact instances are in use
// - Preventing duplicate processing of the same object reference
// - Detecting object cycles during serialization

Scenario 3: Singleton Pattern Verification

Singletons guarantee exactly one instance exists. Identity checks verify this guarantee.

SingletonScenario.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public class DatabaseConnection {
    private static DatabaseConnection instance;
    
    private DatabaseConnection() { /* private constructor */ }
    
    public static DatabaseConnection getInstance() {
        if (instance == null) {
            instance = new DatabaseConnection();
        }
        return instance;
    }
}
 
// Verify singleton behavior with identity check
DatabaseConnection conn1 = DatabaseConnection.getInstance();
DatabaseConnection conn2 = DatabaseConnection.getInstance();
 
// This MUST be true for a correct singleton
assert conn1 == conn2;  // Identity check confirms one instance
 
// If a bug created multiple instances, equals might still return true
// (if poorly implemented), but identity check would catch it.

When to Use Identity Checks

Use identity (==) when: (1) Checking for null, (2) Verifying singleton behavior, (3) Optimizing equality checks (if identical, must be equal—fast path), (4) Tracking specific object instances, (5) Detecting reference cycles. Use equality (.equals()) for most logical comparisons.

Common Bugs From Confusing Identity and Equality

Confusing identity with equality is responsible for countless bugs in production systems. Let's examine the most common patterns and how to avoid them.

Bug Pattern 1: String Comparison in Java

•The Bug: Using == to compare strings
•Why It Sometimes Works: String interning caches literals
•Why It Fails: Runtime-created strings aren't interned
•The Fix: Always use .equals() for string comparison

StringBug.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// BUG: Works by accident, fails unpredictably
String greeting1 = "hello";
String greeting2 = "hello";
if (greeting1 == greeting2) {  // true - but only because of interning!
    System.out.println("Same");
}
 
// This WILL fail:
String userInput = readFromNetwork();  // Returns "hello"
if (greeting1 == userInput) {          // false! Different objects
    System.out.println("Same");        // Never prints
}
 
// CORRECT approach:
if (greeting1.equals(userInput)) {     // true - compares values
    System.out.println("Same");        // Works correctly
}

Bug Pattern 2: Integer Caching Trap

•The Bug: Using == on Integer wrapper objects
•Why It Sometimes Works: Java caches Integer values -128 to 127
•Why It Fails: Values outside cache create new objects
•The Fix: Use .equals() or unbox to primitives

IntegerCacheBug.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// DANGEROUS: Works within cache range
Integer a = 100;
Integer b = 100;
System.out.println(a == b);  // true - cached!
 
// FAILS outside cache range
Integer x = 200;
Integer y = 200;
System.out.println(x == y);  // false! Different objects
 
// This bug is particularly insidious because:
// - Tests pass (with small numbers)
// - Production fails (with real data, larger numbers)
 
// CORRECT approaches:
System.out.println(a.equals(b));     // true - value comparison
System.out.println(x.equals(y));     // true - value comparison
System.out.println(x.intValue() == y.intValue());  // true - primitives

Bug Pattern 3: Collection Membership Failure

•The Bug: Expecting equality-based lookup but getting identity-based
•Cause: Not overriding equals/hashCode in custom classes
•Symptom: 'Contains' returns false for logically equal objects
•The Fix: Override equals and hashCode together

CollectionBug.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// Class without equals/hashCode override
class UserId {
    private final String id;
    
    public UserId(String id) { this.id = id; }
    
    // NO equals() override - uses Object.equals (identity)
}
 
// The bug in action:
Set<UserId> activeUsers = new HashSet<>();
activeUsers.add(new UserId("user123"));
 
UserId checkId = new UserId("user123");  // Same value, new object
System.out.println(activeUsers.contains(checkId));  // false!
 
// Why? HashSet uses equals() for contains(), and Object.equals()
// defaults to identity comparison. Different objects = not found.
 
// The fix: override equals() and hashCode() in UserId
// (We'll cover this in detail in later pages)

The Silent Failure

These bugs are particularly dangerous because they don't throw exceptions. The code runs, produces wrong results, and you might not notice until users report problems—or until an audit reveals corrupted data.

Identity and Null — The Special Case

Null is the one case where identity checks are not just acceptable but required. Calling .equals() on null throws a NullPointerException, so we must use identity to check for null first.

The Pattern:

Always check for null with identity (==) before using methods like .equals().

NullSafety.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
// WRONG: Throws NullPointerException
String input = getUserInput();  // might be null
if (input.equals("expected")) {  // CRASH if input is null!
    // ...
}
 
// CORRECT: Check null first (identity check)
String input = getUserInput();
if (input != null && input.equals("expected")) {
    // Safe - null check prevents the method call
}
 
// BETTER: Use Objects.equals() for null-safe comparison
import java.util.Objects;
 
if (Objects.equals(input, "expected")) {
    // Works if input is null - returns false, no exception
}
 
// How Objects.equals() works internally:
public static boolean equals(Object a, Object b) {
    return (a == b) || (a != null && a.equals(b));
    //      ↑ identity ↑ null check  ↑ equality
}

Null as Identity

In most languages, null has no identity—it's the absence of a reference. null == null is true (the absence is 'equal' to itself), but null doesn't point to any object. This is why you can't call methods on null—there's no object to receive the message.

Summary: Object Identity

We've explored the foundational concept of object identity—what it means for two references to point to the same memory location. Let's consolidate the key insights:

Key Takeaways

•Identity = Same Memory Location — Two references are identical if they point to the exact same object on the heap.
•Identity Is Stricter Than Equality — If two references are identical, they must be equal. Equal references are not necessarily identical.
•Identity Cannot Be Overridden — It's determined by memory addresses, not programmer logic.
•Common Bugs Arise From Confusion — Using == when you mean .equals() (and vice versa) causes subtle, hard-to-find bugs.
•Null Requires Identity Checks — Always use == for null comparisons to avoid NullPointerException.
•Different Languages, Same Concept — Whether it's ==, is, or ===, all languages have a way to check identity.

What's Next:

Now that we understand identity (same memory), we'll explore equality (same value) in the next page. You'll learn how to define what 'equal' means for your objects, implement the equals() method correctly, and avoid the treacherous pitfalls that trip up even experienced developers.

Page Complete

You now understand object identity—the concept of same memory location. This foundational knowledge prepares you for the more nuanced concept of equality, where you'll define logical equivalence for your objects. Next: Equality — Same Value.