equals() vs == for Strings in Java

== compares references: it asks whether the two variables point at the same object. equals compares contents: it asks whether the two objects hold the same sequence of characters. For Strings those two questions have different answers, which is why the distinction matters.

The trap is that == appears to work for a long time. Two literals with the same text usually come from the constant pool and are the same object, so == returns true. The moment a String comes from somewhere else — a database column, a request parameter, a file, a computed value — it is a separate heap object, and == returns false even though the text is identical.

public class Main {
    public static void main(String[] args) {
        String a = new String("tutorsbot");
        String b = new String("tutorsbot");
        System.out.println("a == b         : " + (a == b));        // false
        System.out.println("a.equals(b)    : " + a.equals(b));   // true

        String c = "tutorsbot";
        String d = "tutorsbot";
        System.out.println("c == d         : " + (c == d));        // true, pooled
        System.out.println("c.equals(d)    : " + c.equals(d));

        // equals is case sensitive, and safe on the receiver.
        System.out.println("case sensitive : " + c.equals("TUTORSBOT"));
        System.out.println("null receiver  : " + "x".equals(null));
    }
}

Two details about equals itself. It is case sensitive, so c.equals("TUTORSBOT") is false; use equalsIgnoreCase if you want case folding. And it is null-safe on the receiver only — calling a.equals(b) throws a NullPointerException if a is null, whereas b.equals(a) is safe. That asymmetry is why code often does a null check before comparing.

The house rule is simple and worth stating without hesitation in an interview: compare Strings with equals, never with ==. If you want to compare against a literal, use "expected".equals(value) so that a null value cannot blow up the comparison.

It is acceptable in exactly one situation: when you are deliberately asking about object identity — for instance, checking whether two references point at the same interned instance while investigating a memory question. That is a diagnostic use, not a comparison use.

For comparing values it is never safe. The reason it seems to work is that the constant pool gives you the same object for identical literals, so "abc" == "abc" is true, and a compiler even folds that to a single constant. But a String that arrived at run time — from a method argument, a getter, a database result, a parsed file — is a separate object, and the comparison flips to false.

That is why this bug is so common in production and so rare in testing. The unit test uses literals, and passes. The integration test loads a row from the database, and the same comparison now fails. By then the code is deployed.

There is a second reason to avoid it that has nothing to do with correctness: == on Strings encourages a reading of the code where the comparison is cheap and immediate, which leads people to use it on other reference types too — where it is never right. And because String literals are interned, some engineers assume all Strings are, which is false.

The habit to build instead: reach for equals by default, and put the constant on the left when a null is possible — "expected".equals(actual) — so a null actual simply compares false instead of throwing.

A HashMap finds its bucket using the key's hashCode and then confirms the match with equals. Both of those must stay stable for as long as the key is in the map. A mutable key breaks that contract: if you change the key after putting it in the map, its hash code changes, and the map can no longer find the entry — because the entry is sitting in the bucket for the old hash.

The entry is not deleted, and it is not duplicated. It simply becomes unreachable, and the map starts reporting the wrong size for the number of live entries it actually holds.

import java.util.HashMap;
import java.util.Map;

public class Main {
    public static void main(String[] args) {
        Map<StringBuilder, String> map = new HashMap<>();

        StringBuilder key = new StringBuilder("id-1");
        map.put(key, "first");
        System.out.println("size before   : " + map.size());

        // Mutating the key changes its hashCode, so the entry is now unreachable.
        key.append("-v2");
        System.out.println("lookup after  : " + map.get(key));   // null
        System.out.println("size after    : " + map.size());

        // The fix: use an immutable key.
        Map<String, String> safe = new HashMap<>();
        safe.put("id-1-v2", "first");
        System.out.println("safe lookup   : " + safe.get("id-1-v2"));
    }
}

The output is the diagnosis. The map reports one entry, but looking the key up returns null, because the map is searching the bucket for the key's new hash code while the entry is filed under the old one. There is no exception and no warning; the map is quietly wrong.

Three ways to avoid it. Use an immutable key, which is why String is the most common key type in Java and why the language makes String immutable in the first place. Or use an immutable value type that implements hashCode and equals consistently — a record does this correctly by construction. And if you genuinely need a mutable key, compute a stable hash from the immutable part of the object's state, so that changes to the mutable part do not affect the bucket.

The same rule applies to HashSet, which is built on a HashMap, and to any object you put into a hash-based collection. If the object overrides equals but not hashCode, or the two disagree, you get a related class of bug.