Explain String Pool.

Hook: Java String Pool is one of those features that quietly saves memory every day, which is why interviewers love asking about it.

Question: Explain String Pool.

Answer: The String Pool is a special place where Java keeps one shared copy of each unique string literal and each string that you explicitly intern. If the same text appears again, Java can reuse the existing object instead of creating a duplicate. This helps save memory and makes repeated string access cheaper, but it also means you must understand the difference between content equality with equals() and reference equality with ==.

Interview-Ready Answer: In Java, the String Pool is a canonical storage area for unique string values. When I write a string literal like "hello", Java reuses the pooled instance if it already exists, instead of creating a new object. If I create a string with new String("hello"), that makes a separate heap object, but intern() can return the pooled reference. A useful detail is that since Java 7, the pool lives in the heap, not PermGen, so pooled strings can be garbage-collected when no longer referenced.

What the String Pool is

The String Pool is Java’s cache of unique string values. Think of it as a shared warehouse of labels: if the exact same text is needed again, Java points to the existing label instead of printing a new one. The official idea behind it is canonicalization, which means keeping one standard representative object for a value.

How it works under the hood

1. When the JVM loads a string literal like "cat", it checks the pool first.
2. If "cat" is already there, Java reuses that same object reference.
3. If it is not there, Java creates the string and stores it in the pool.
4. When you write new String("cat"), Java creates a new object on the heap, even if "cat" already exists in the pool.
5. If you call intern(), Java looks up the pool version and returns that canonical reference, adding it if needed.

In HotSpot JVMs, the pool is implemented with a hash table called the StringTable. That means lookup is usually fast, about O(1) on average, but collisions can make it slower in bad cases. The pool is not a magic infinite store; it is a managed structure, and its size can be tuned in HotSpot with -XX:StringTableSize.

Version differences you should know

• Before Java 7, interned strings lived in PermGen, a small fixed memory area that was notorious for OutOfMemoryError problems.
• From Java 7 onward, the string pool moved to the heap.
• Java 8 removed PermGen entirely, but the pool concept stayed the same.

When and why to use it

Use the pool automatically through literals and compile-time constants. Use intern() only when you truly have many repeated values, such as IDs, keys, or protocol tokens coming from external input, and you want to reduce duplicate objects. Do not blindly intern everything: the hash lookup costs something, and overuse can make code harder to reason about.

Common creation paths compared

Important gotchas

• == compares references, not text. Two equal strings may still be different objects.
• equals() compares content, which is what you usually want.
• String literals and compile-time constant expressions are pooled, but runtime expressions are not unless you call intern().
• The pool saves memory mostly when the same text repeats a lot; for mostly unique strings, it adds little value.

Memory hook: “One text, one ticket.” If the text already has a ticket in the pool, Java reuses it instead of printing another one.

Performance-wise, the pool trades a small hash lookup for less memory duplication. In real systems, that is usually a good deal for repeated values like language codes, status names, or feature flags.

Real-world story

Imagine a checkout service in an e-commerce system that reads promo codes from HTTP requests and also keeps a few known codes in constants. A developer mistakenly writes if (promoCode == "SAVE10") instead of using equals(). Most of the time the test fails because request strings usually come from the network and are not the same reference as the literal, even when the text matches.

What goes wrong: customers type a valid code, but the service rejects it. Logs show confusing output such as the same text with different identity hash codes, support tickets rise, and the team may see higher load because the app keeps falling back to a slower validation path or hitting the database unnecessarily. The bug is subtle because it may seem to work in a few local tests where literals are compared to literals, then fail in production with real input.

The fix is simple but important: use equals() for content, and only think about the String Pool when you need sharing or canonicalization, not as a substitute for correct comparison.

Follow-up & Tricky Questions:

• What does intern() actually do? It returns the pooled canonical instance for that text. If the value is not already in the pool, the JVM adds it and returns the pooled reference.
• What changed in Java 7? The String Pool moved from PermGen to the heap, which made it less likely to hit fixed-size memory failures and allowed pooled strings to be garbage-collected when unreachable.
• Why is == dangerous with strings? Because it checks whether two variables point to the same object, not whether the text is the same. Two different string objects can contain identical characters and still fail ==.
• Are all repeated strings pooled automatically? No. Literals and compile-time constants are pooled automatically, but runtime-created strings are not pooled unless you call intern().
• Is StringBuilder related to the pool? Not directly. It helps build strings efficiently, but the resulting string from toString() is a normal heap object unless it is interned later.
• Does pool usage guarantee faster code? Not always. It helps when many duplicate strings exist, but the hash lookup and memory management mean it is only worth using for the right workload.
• Can pooled strings be collected? In modern Java, yes, if nothing else references them, because the pool is on the heap.
• Is final String the same as an interned string? No. final only means the variable cannot be reassigned; it says nothing about pooling.
• Tricky: If two strings are both created with new String("x"), are they ==? No, they are separate objects. They may have equal content, but reference equality is false unless they happen to be the exact same object.
• Tricky: Is "a" + "b" pooled? Yes, because it is a compile-time constant expression and the compiler folds it into one pooled literal. The runtime version with variables is different.
• Tricky: Does intern() clone the string? No, it returns the canonical pooled reference, so the whole point is to share one object for that value.

Common Mistakes:

• Using == for string content. Correct it by using equals() or Objects.equals().
• Thinking every string automatically goes to the pool. Only literals, compile-time constants, and interned strings do.
• Assuming new String("...") is normal or useful. It usually creates unnecessary duplicates and should be avoided unless you have a very specific reason.
• Forgetting the Java 7 change. Older interview answers that say pooled strings live in PermGen are outdated for modern Java.

Memory Hook: The pool is a shared name tag drawer: if the name already exists, Java reuses the same tag instead of cutting a second one.

Cheat Sheet:

• String Pool = shared storage for unique string values.
• Literals are pooled automatically.
• new String() makes a new heap object.
• intern() gives the canonical pooled reference.
• Use equals() for content, == only for reference checks.
• Since Java 7, the pool is on the heap.

Practice Tasks:

• Write a small program that compares a literal, new String(), and intern() using both == and equals().
• Test three cases: a compile-time concat, a runtime concat from variables, and the same runtime concat after calling intern().
• Replace all unsafe string comparisons in one old code sample with Objects.equals() and explain why the behavior becomes correct.