قرارداد equals/hashCode، رشته، تغییرناپذیری و Boxingequals/hashCode, String, Immutability & Boxing

There are three deceptively simple corners of Java that have sunk more real code than any concurrency bug — precisely because they look trivial. They seem so harmless that nobody pauses to learn them properly, and then one day map.get(key) calmly returns null for a key you inserted three lines earlier. This lesson builds all three corners from scratch so they never ambush you again.

Part 0 — words you must know

Before we move on, let's crack open four words with analogies so none of them ever lands on you cold later.

• reference: the address of an object in memory, not the object itself. Like a slip of paper with a house's address written on it. Two slips can hold the same address (one house) or two different addresses that happen to have identical furniture.
• primitive: the basic types like int, long, double, boolean. These aren't objects; they hold the value directly, not an address to it. int x = 5 means the 5 is right there, not a pointer to a 5.
• wrapper: the object version of each primitive: Integer for int, Long for long, Double for double, and so on. A box that holds a primitive inside so you can use a number where only objects are accepted (like List<Integer>).
• bucket and hash: picture a HashMap as a train-station luggage locker. Instead of lining up all bags in one row, it maps each bag via a short number (a hash) to a shelf (a bucket). Finding a bag means: compute the shelf number, go to that shelf, then only inspect the bags on that one shelf — not the whole station.

Three worlds of equality: == vs .equals

In Java:

• For primitives (int, long, ...) the == operator compares the value itself: 5 == 5 is true. No address is involved.
• For objects (anything made with new, anything that is a reference), == compares addresses: do these two references point to one single object? To compare content you must call .equals.

The default Object.equals your class inherits is exactly == (identity comparison). So until you override equals, you have no "value equality" at all — only "same-object-ness."

The equals/hashCode contract

Object.equals and Object.hashCode come as a pair with a legally binding contract — not a polite suggestion, but a rule the entire standard library relies on. HashMap, HashSet, LinkedHashMap, ConcurrentHashMap, deduplication, caching — all of it rests on you upholding it. Break it and these classes don't crash; they just silently return wrong answers, which is worse.

equals — five rules

For non-null references x, y, z:

These five look obvious, but each closes a real mistake. Symmetric stops a from claiming it equals b while b denies it — which happens with mixed types. Transitive keeps a chain of equality honest. Consistent means if you lean on data not used in equals (say, network state), your results become unstable. And Non-null means your equals must never blow up on a null argument; it should quietly return false.

hashCode — three rules

1. Consistent: the same object returns the same hash value across calls within one run (unless equals-relevant state changes).
2. The one that matters: if a.equals(b) then a.hashCode() == b.hashCode(). Mandatory.
3. Unequal objects may share a hash code (collisions are legal), but distinct hashes improve performance.

Why are collisions allowed? Because the hash space (an int, about four billion states) is finite while the number of possible objects is infinite. So inevitably two different objects sometimes get the same hash. HashMap accepts this: a bucket may hold several entries, and it distinguishes them there using equals. A collision only costs speed, not correctness. But violating rule 2 — equals with unequal hashes — costs correctness.

How breaking it corrupts a HashMap

// BROKEN: overrides equals but NOT hashCode
class Point {
    final int x, y;
    Point(int x, int y) { this.x = x; this.y = y; }

    @Override public boolean equals(Object o) {
        if (!(o instanceof Point p)) return false;
        return x == p.x && y == p.y;
    }
    // hashCode() inherited from Object → identity-based
}

Map<Point, String> map = new HashMap<>();
map.put(new Point(1, 2), "A");
System.out.println(map.get(new Point(1, 2))); // prints null!

Let's walk through why disaster strikes. Two Point(1,2) instances are .equals (their x and y match). But since you didn't override hashCode, each gets the default identity hash derived from its memory address — and two separate news mean two separate addresses, so two different hashes. The librarian (HashMap) put the first instance on shelf 7 (say). Now you come back with the second instance; she runs the formula on it and arrives at shelf 31. Shelf 31 is empty. get never even reaches the equals comparison; it returns empty-handed from the wrong shelf. This is the single most common Java data bug.

Canonical implementation

Now look at the correct version and dissect every engineering decision:

public final class Money {
    private final long amountMinor;   // store cents, never double
    private final String currency;

    public Money(long amountMinor, String currency) {
        this.amountMinor = amountMinor;
        this.currency = Objects.requireNonNull(currency);
    }

    @Override public boolean equals(Object o) {
        if (this == o) return true;                    // fast path
        if (!(o instanceof Money m)) return false;     // type + null check
        return amountMinor == m.amountMinor
            && currency.equals(m.currency);
    }

    @Override public int hashCode() {
        return Objects.hash(amountMinor, currency);    // combines fields
    }
}

A few practical points that make this "senior":

• if (this == o) return true; is a fast path: if you're comparing an object to itself, there's no need to inspect fields. It saves time in hot loops.
• if (!(o instanceof Money m)) return false; does two things at once: it checks the type is right, and it checks o isn't null (because null instanceof anything is always false). This is the "pattern matching for instanceof" idiom, official since Java 16; the variable m comes straight out of the cast.

Two more points:

• Use the same fields in equals and hashCode. A field in one but not the other directly violates the golden rule (two objects could be equals yet, because a field present in equals is absent from hashCode, get different hashes).
• Objects.hash(...) is convenient but boxes every argument and allocates a varargs array. Fine for an ordinary POJO; but in a hot hashCode inside a tight loop, those allocations add up, and there you should hand-roll it (which we see next). For nullable fields, use Objects.equals(a, b), which handles nulls and won't NPE.

The 31 * result idiom

@Override public int hashCode() {
    int result = Long.hashCode(amountMinor);
    result = 31 * result + currency.hashCode();
    return result;
}

This is the classic hand-rolled pattern: start with the hash of the first field, then for each subsequent field multiply the running result by 31 and add the new field's hash. Why exactly 31?

31 is a prime and odd number. Being prime helps hash distribution (hashes spread more evenly across buckets, fewer collisions). Being odd has a performance trick: 31 * i is exactly (i << 5) - i ("32 times minus one time"), so the JVM turns it into a shift and a subtract, cheaper than a real multiply.

Mutable keys — the silent killer

Even a perfectly correct equals/hashCode is defeated if you mutate a key after insertion:

Set<List<Integer>> set = new HashSet<>();
List<Integer> key = new ArrayList<>(List.of(1, 2));
set.add(key);
key.add(3);                          // hashCode of key just changed
System.out.println(set.contains(key)); // false — even the exact object is "gone"

Here you didn't even make a new object — you ask about the very same key and still get false! Why? Because List.hashCode is computed from the list's contents. When you did add(3), the content went from [1,2] to [1,2,3] and the hash changed. But the element still physically sits in the bucket for its old hash. Now contains computes the new hash and searches a different bucket, where it finds nothing.

Comparable, Comparator, and consistency with equals

So far we've discussed equality. Now let's turn to ordering. Here too you have a pair of concepts that, like equals/hashCode, must stay in sync.

Comparable<T> defines a natural ordering via the compareTo method — "my default way of sorting myself," written inside the class itself. Comparator<T>, by contrast, is an external, swappable ordering: without touching the class, you say from the outside "sort it this way this time."

record Person(String name, int age) {}

// Comparator: sort by age, then name — no need to touch the class
Comparator<Person> byAgeThenName =
    Comparator.comparingInt(Person::age)
              .thenComparing(Person::name);

compareTo returns a negative/zero/positive number: negative means "I am smaller," zero means "we're equal," positive means "I am larger." Its contract mirrors equals: it must form a total order (antisymmetric, transitive) and satisfy signum(x.compareTo(y)) == -signum(y.compareTo(x)) — i.e. if x is greater than y, then y must be less than x. (signum returns just the sign: -1, 0, or +1.)

Consistency with equals — the BigDecimal trap

The docs strongly recommend but do not require that (x.compareTo(y) == 0) == x.equals(y) — "if ordering says they're equal, equality should agree." The famous violator is BigDecimal:

BigDecimal a = new BigDecimal("1.0");
BigDecimal b = new BigDecimal("1.00");

System.out.println(a.equals(b));       // false — scale differs (1 vs 2)
System.out.println(a.compareTo(b));    // 0 — numerically equal

Set<BigDecimal> hashSet = new HashSet<>(List.of(a, b));
Set<BigDecimal> treeSet = new TreeSet<>(List.of(a, b));
System.out.println(hashSet.size());    // 2 — uses equals
System.out.println(treeSet.size());    // 1 — uses compareTo!

"1.0" and "1.00" are numerically one number, but BigDecimal stores, besides the value, the scale (number of digits after the decimal point): the first has scale 1, the second scale 2. equals checks both value and scale, so it calls them unequal. But compareTo sees only the numeric value and calls them equal.

String: immutability, the pool, and identity

String is immutable — meaning once a string is created, its content never changes. Its backing data (byte[] value since Java 9's "compact strings"; char[] before) is both final and never mutated. When you call s.toUpperCase(), the old string stays untouched and a new string is returned.

The string pool and ==

String literals — any string you write directly in code, like "hello" — are automatically interned into a pool in the heap. "Intern" means Java keeps one canonical copy of each distinct string, and all identical literals share that one object:

String s1 = "hello";
String s2 = "hello";
System.out.println(s1 == s2);          // true — same pooled object

String s3 = new String("hello");
System.out.println(s1 == s3);          // false — new() forces a fresh heap object
System.out.println(s1.equals(s3));     // true — same value
System.out.println(s1 == s3.intern()); // true — intern() returns the pooled ref

s1 and s2 both point to the same object inside the pool, so == is true. But new String("hello") explicitly says "make me a fresh object" and skips the pool, so s3 has a different address and s1 == s3 is false — even though their contents are identical, which .equals confirms. And intern() says "give me the canonical pooled reference for this string," which is s1 again.

Compile-time constant folding

Here the behavior gets one layer subtler:

String a = "hel" + "lo";               // folded at compile time → literal "hello"
System.out.println(a == "hello");      // true

String part = "hel";
String b = part + "lo";                // runtime concatenation → new object
System.out.println(b == "hello");      // false

final String cpart = "hel";            // compile-time constant
String c = cpart + "lo";               // folded → true
System.out.println(c == "hello");      // true

The point is: a + performed on compile-time constants — literals, final variables initialized with a constant, and static finals — is computed by the compiler (javac) before execution and folded into a single literal, which is then interned. So "hel" + "lo" is effectively the very same "hello" inside the pool.

But a + that involves a runtime value (like the non-final variable part) builds a brand-new object at runtime that is not in the pool. The magic of the third line is here: you made cpart final and initialized it with a constant, so the compiler knows its value is fixed and folds again.

intern() — use with care

intern() returns the canonical pooled instance, enabling a later ==. When you have a huge number of duplicate strings, it can save memory (all pointing to one copy instead of thousands). But the pool is a fixed-size hash table (tunable via the -XX:StringTableSize flag), and interning huge sets of distinct strings just adds pressure and CPU with no benefit. Modern default: don't intern; let the pool handle literals, and use equals to compare.

StringBuilder — why and how

Because strings are immutable, s = s + x in a loop is O(n²): each iteration allocates a brand-new string and copies all the previous characters into it. So at the 100th iteration, 100 prior characters are copied again; at the 1000th, 1000 characters — and the total is quadratic.

// BAD: quadratic, allocates n intermediate Strings
String r = "";
for (String w : words) r += w;

// GOOD: one buffer, amortized O(n)
StringBuilder sb = new StringBuilder(words.size() * 8); // pre-size to avoid resizes
for (String w : words) sb.append(w);
String r = sb.toString();

StringBuilder is a mutable buffer: instead of building a fresh string each step, it appends into the same buffer and only occasionally grows it when full. With new StringBuilder(words.size() * 8) you make the buffer big from the start with a rough guess, to avoid repeated resizes.

Autoboxing, unboxing, and the Integer cache

Autoboxing means Java automatically converts an int to an Integer (behind the scenes via Integer.valueOf). Unboxing is the reverse: Integer to int (via intValue). This automation is very convenient — you can drop an int straight into a List<Integer> — but it's also a minefield.

The cache: -128..127

Here's the key point: Integer.valueOf caches instances for values -128 to 127 inclusive. So same-valued boxes in that range are the very same object; but outside that range, each box is a fresh object.

Integer a = 127, b = 127;
System.out.println(a == b);   // true  — both from the cache

Integer c = 128, d = 128;
System.out.println(c == d);   // false — outside cache, distinct objects
System.out.println(c.equals(d)); // true — value equality

Which types have a cache? Boolean, Byte, Short (range -128..127), Character (range 0..127), Integer (range -128..127, whose upper bound you can raise via the -XX:AutoBoxCacheMax=<n> flag or the java.lang.Integer.IntegerCache.high property), and Long (range -128..127, but this one not tunable). And importantly: Float and Double have NO cache — Double d1 = 1.0; Double d2 = 1.0; d1 == d2 is always false.

Mixed ==: one primitive forces unboxing

If either operand of == is a primitive, the other is unboxed too and the comparison is no longer a reference comparison but a numeric one — and the cache is not involved at all:

Integer i = 1000;
int j = 1000;
System.out.println(i == j);   // true — i is unboxed to int, numeric compare

Here j is a raw int. Java can't directly compare an int and an Integer with reference ==, so it must unbox i to make both ints, then compare values. 1000 equals 1000, so true — even though 1000 is well outside the cache range!

NullPointerException from unboxing

Map<String, Integer> counts = new HashMap<>();
int n = counts.get("missing");  // get returns null → auto-unbox → NPE

counts.get("missing") returns null because the key is absent — and that null is of type Integer. Now you want to put it into an int (a primitive), so Java tries to unbox it, i.e. call intValue() on null — and right there a NullPointerException is thrown, on a line with no null written in it! This is one of the most surprising production crashes.

Performance: boxing in hot paths

// SLOW: Long autoboxes ~ every iteration → millions of allocations
Long sum = 0L;
for (long i = 0; i < 100_000_000L; i++) sum += i; // unbox, add, re-box each time

// FAST: primitive, zero allocation
long sum2 = 0L;
for (long i = 0; i < 100_000_000L; i++) sum2 += i;

The only difference between these two loops is one capital letter: Long vs long. But in the slow version, every time sum += i runs, Java must unbox sum, do the addition, and re-box the result into a fresh Long. A hundred million iterations means a hundred million object allocations and enormous pressure on the garbage collector. The primitive version allocates nothing.

Designing immutable classes

We saw what superpowers immutability gave String. Now let's learn to build our own immutable class. Immutability buys thread-safety, safe hashing, safe sharing, and cache-friendliness. The recipe (from Effective Java) has four steps:

1. Make the class final (or use a private constructor + factory methods) so nobody can subclass it and mutate it through that.
2. Make all fields private final.
3. Provide no mutators (no setters or other state-changing methods).
4. Defensively copy mutable inputs on the way in and mutable state on the way out.

public final class Period {
    private final Date start;   // Date is mutable — danger
    private final Date end;

    public Period(Date start, Date end) {
        // copy IN: caller can't mutate our internals afterward
        this.start = new Date(start.getTime());
        this.end   = new Date(end.getTime());
        if (this.start.after(this.end))
            throw new IllegalArgumentException("start after end");
        // validate the COPIES, not the args (TOCTOU safety)
    }

    public Date start() { return new Date(start.getTime()); } // copy OUT
    public Date end()   { return new Date(end.getTime());   }
}

A subtle point inside the constructor: you validate the copies, not the original arguments. This guards against a TOCTOU attack (time-of-check to time-of-use): if you checked the original argument, another thread could change its value exactly between your check and your copy. By checking the copy, what you check is what you keep. And the best move: choose immutable field types from the start — java.time.Instant, LocalDate, List.copyOf(...) — so no copying is needed at all.

Records — data carriers done right

Java 16+ records are transparent, immutable data aggregates. You just declare the components, and the compiler generates the canonical constructor, the private final fields, the accessors, and — most importantly — contract-correct equals, hashCode, and toString derived from all the components.

public record Money(long amountMinor, String currency) {
    // compact constructor: validate/normalize, no field assignment needed
    public Money {
        Objects.requireNonNull(currency);
        if (amountMinor < 0) throw new IllegalArgumentException("negative");
        currency = currency.toUpperCase(); // reassigning the parameter normalizes the field
    }
}

Notice how clean the compact constructor is: no parameter list, no this.currency = currency; you just validate and normalize, and the compiler wires up the rest. Even when you reassign the currency parameter (toUpperCase), that normalized value lands in the final field.

But a few caveats seniors know:

• Records are shallowly immutable: a record Holder(List<String> items) still exposes that mutable List outward. For true immutability you must copy in the compact constructor: items = List.copyOf(items).
• The generated equals uses all components. But if a component is an array, equals uses the array's identity, not its contents (because arrays don't override equals). So record + array is a subtle bug: two records with identical array contents will have equals return false.
• Records are implicitly final, can't extend a class, but can implement interfaces. They're good for data, not for behavior-rich hierarchies.

Common pitfalls & gotchas

A compact list to review — each unpacked in the lesson above:

• map.get(new Point(1,2)) returns null because you overrode equals but not hashCode.
• Mutating a key after putting it in a HashSet/HashMap orphans it.
• Integer == Integer is true only within -128..127; your integration tests pass with small IDs and prod breaks at 128.
• int x = map.get(k) NPEs when the key is absent.
• str1 == str2 "works" in unit tests (interned literals) and fails on runtime-built strings.
• Double d = 1.0; d == 1.0 — the 1.0 literal is a primitive, so d unboxes; this is true. But Double == Double is false.
• BigDecimal in a HashSet vs TreeSet gives different sizes for 1.0 and 1.00.
• Objects.hash() allocates — don't call it in a hot loop's hashCode.
• Overriding equals with a wrong parameter type: public boolean equals(Point p) overloads rather than overrides Object.equals(Object) — collections still call the Object version. Always @Override and take Object.

Best practices

• Always override equals and hashCode together, on the same fields, and always add @Override.
• Prefer records for value objects and map keys — free, correct contract.
• Never compare boxed wrappers or strings with ==; use .equals.
• Keep hash keys immutable.
• Use primitive types and primitive streams in numeric hot paths.
• Defensively copy mutable inputs/outputs, or use immutable types to begin with.
• Keep Comparator consistent with equals unless you deliberately document otherwise.

Interview Questions

These are the questions that come up in a senior interview. Read each with its full answer and say it out loud to yourself.

Integer i = 1000; int j = 1000;
System.out.println(i == j);

System.out.println("a" + "b" == "ab");           // (1)
String x = "a"; System.out.println(x + "b" == "ab"); // (2)

class Id {
    final String v; Id(String v){this.v=v;}
    public boolean equals(Id o){ return v.equals(o.v); } // bug
    public int hashCode(){ return v.hashCode(); }
}

Map<String,Integer> m = new HashMap<>();
System.out.println(m.get("x") + 1);

Object o = true ? Integer.valueOf(1) : Double.valueOf(2.0);
System.out.println(o);

Senior notes & advanced edge cases

You know the contract now. Let's go where a senior pulls ahead of a strong mid-level: what actually happens inside a HashMap, how an innocent-looking Comparator takes a production service down with an exception, why the default hashCode is not the memory address at all, and why equals/hashCode for a Hibernate @Entity is one of the hardest design calls — one that 90% of teams get wrong.

Part 1 — Inside HashMap: what the senior interview really asks

Once you respect the contract, the next question is: "what exactly happens on put?" The shallow answer ("it computes the hash and drops it in a bucket") marks you as mid-level. The senior answer has three layers.

Layer one: hash spreading

Your hashCode() gives a 32-bit int, but HashMap only uses the low bits to pick a bucket (because the table size is always a power of two, and index = hash & (n-1)). If your hashCodes differ only in their high bits, everything lands in one bucket. So HashMap "stirs" the hash before using it:

static final int hash(Object key) {
    int h;
    return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}

That h ^ (h >>> 16) XORs the high bits down so they influence the index. Senior lesson: HashMap partially compensates for bad hashCodes but performs no miracles — a constant return 42; piles everything into one bucket and collapses performance to O(n).

Layer two: bucket treeification

Since Java 8, if a single bucket gets very crowded, HashMap converts that bucket from a linked list to a red-black tree, so intra-bucket lookup goes from O(n) to O(log n). Two thresholds are involved:

• TREEIFY_THRESHOLD = 8: a bucket that reaches 8 entries becomes a treeify candidate.
• MIN_TREEIFY_CAPACITY = 64: but only if the whole table has at least 64 slots; otherwise it resizes first instead of treeifying.
• UNTREEIFY_THRESHOLD = 6: if removals drop it back to 6, it reverts to a list.

Bucket lifecycle inside a HashMap — چرخهٔ عمرِ یک سطل در HashMap:

stateDiagram-v2
    [*] --> Empty
    Empty --> LinkedList: put (collision)
    LinkedList --> Tree: size >= 8 AND table >= 64
    LinkedList --> Resize: size >= 8 AND table < 64
    Resize --> LinkedList: rehash spreads entries
    Tree --> LinkedList: size <= 6 (untreeify)
    Tree --> [*]: clear

Layer three: load factor and rehash

When the element count exceeds capacity * loadFactor (default 0.75), HashMap doubles capacity and rehashes everything. Three senior consequences:

• If you know the final size, pre-size with new HashMap<>(expectedSize / 0.75f + 1) to eliminate repeated rehashes.
• HashMap iteration order is not guaranteed and can change after a resize; never rely on it — insertion order → LinkedHashMap, sorted order → TreeMap.
• HashMap accepts a null key and null values, but ConcurrentHashMap accepts neither — because concurrently, map.get(k) == null would be ambiguous ("absent" vs "value is null?").

Part 2 — the Comparator trap that takes a service down

This is one of the most dangerous "looks like clean code" bugs.

Subtraction instead of comparison = silent overflow

// BUG: int overflow
Comparator<Integer> byValue = (a, b) -> a - b;
byValue.compare(Integer.MAX_VALUE, -1); // expected: positive. reality: overflow → negative!

a - b overflows when a is large and b is a large negative, and the sign flips. The result is wrong ordering, or worse, a violated Comparator contract. Always use Integer.compare(a, b) (or Long.compare, Double.compare) — never subtraction.

The infamous TimSort crash

Java's sort for objects (Arrays.sort/Collections.sort) is TimSort, and it validates the Comparator contract at runtime. If your Comparator is inconsistent/non-transitive (from that overflow, or from comparing fields that are sometimes null or NaN), it throws this mid-sort:

java.lang.IllegalArgumentException: Comparison method violates its general contract!

// correct: null-, NaN-, and overflow-safe
Comparator<Person> safe =
    Comparator.comparing(Person::name, Comparator.nullsFirst(Comparator.naturalOrder()))
              .thenComparingInt(Person::age);

Part 3 — the default hashCode is not the memory address

A widespread belief (simplified even in this very chapter) is that Object's default hashCode is the "memory address." On modern JVMs this is wrong.

In HotSpot, the identity hash code is a number generated the first time it's needed and cached in the object's own header mark word. Since JDK 8 the default comes from a pseudo-random algorithm based on thread state (not the address). Why can't it be the address? Because GC (especially compacting collectors) moves objects in memory; if the hash came from the address, it would change after each GC and break the "hashCode must be consistent during a run" contract. By caching it in the header, the hash stays fixed even if the object relocates.

Part 4 — floating-point equality: NaN and negative zero

Three ways to compare a double give three different answers, and a senior must know which is which:

double n = Double.NaN;
System.out.println(n == n);                      // false — NaN != anything, even itself
System.out.println(Double.valueOf(n).equals(n)); // true  — Double.equals works on bits

System.out.println(0.0 == -0.0);                    // true  — the == operator sees them equal
System.out.println(Double.valueOf(0.0).equals(-0.0)); // false — equals distinguishes them
System.out.println(Double.compare(0.0, -0.0));      // 1     — compare puts -0.0 below +0.0

Why? Double.equals and Double.compare convert the value to bits (doubleToLongBits) to stay reflexive: NaN must equal NaN, otherwise one NaN gets inserted into a HashSet twice and is never found; and +0.0 and -0.0, which have different bit patterns, are counted separately.

record P(double x) {}
new P(Double.NaN).equals(new P(Double.NaN)); // true!  (unlike ==, which was false)
new P(0.0).equals(new P(-0.0));              // false! (unlike ==, which was true)

Part 5 — equals/hashCode for JPA/Hibernate entities (the real production trap)

This is where textbook theory collides with ORM reality, and most teams get it wrong. Take an @Entity whose id is generated by the database on persist (@GeneratedValue).

Problem 1 — the id is null before persist. If you base equals/hashCode on id: you put a new entity (id = null) into a HashSet, then save it, now the id gets a value and hashCode changes → the exact "mutable key" trap from the main chapter: the entity is lost in its old hash bucket and set.contains(entity) returns false.

Problem 2 — the lazy proxy. For lazy relations Hibernate creates a subclass proxy whose getClass() differs from the real class; so getClass() in equals (the one shown in the main chapter) makes the real entity unequal to the proxy of the very same row.

The senior fix (Vlad Mihalcea's recommendation):

@Entity
public class Book {
    @Id @GeneratedValue Long id;
    @Column(unique = true) String isbn; // stable, unique business key

    @Override public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof Book)) return false; // instanceof works with the proxy
        return isbn != null && isbn.equals(((Book) o).isbn);
    }
    @Override public int hashCode() {
        return getClass().hashCode(); // constant! never changes
    }
}

Part 6 — strings at scale

String hashCode is cached

String caches its hashCode in an int hash field (it can, because it's immutable and never changes). The formula is a polynomial: s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]. Two fine points: (1) "".hashCode() is 0, and since the cache's initial value is also 0, the empty string and any string that happens to hash to zero get recomputed every time (newer JDKs added a hashIsZero flag to fix this). (2) Because the formula is public and well known, an attacker can craft strings with equal hashes — another vector for hash-flooding.

intern has a memory cost

String.intern() since Java 7 keeps the pool on the heap (it used to live in PermGen, the source of a famous OOM). But interned strings, like any heap object, aren't GC'd while referenced; interning millions of distinct strings is a slow memory leak. Interning only pays off when you have a small number of high-frequency values (e.g. column names while parsing a large file).

Part 7 — modern immutable collections, a few sharp edges

Since Java 9, List.of, Set.of, Map.of build lightweight immutable collections, but they behave differently from ArrayList/HashMap, and three of those differences bite seniors: (1) they're null-hostile — List.of(null) or Map.of("k", null) throw; (2) a duplicate key/element like Set.of("a","a") throws IllegalArgumentException at construction, unlike HashSet, which silently ignores it; (3) iteration order is randomized and unstable — they use a random SALT per JVM run, so order changes between runs and an order-sensitive test breaks.

Senior interview questions (advanced)