String Constant Pool

JavaMidjava

The Question

What is the String Constant Pool in Java?

What a Strong Answer Covers

• special storage in heap
• stores string literals
• JVM checks pool before creating
• reuses references for duplicates
• memory saving

Senior-Level Answer

The String Constant Pool (also called String Intern Pool) is a special memory region inside the JVM's heap where string literals are stored and reused. When you write a string literal like `String s = "hello"`, the JVM checks the pool first. If "hello" already exists, it returns the same reference rather than allocating a new object. This is possible precisely because Strings are immutable — sharing references is safe since no one can modify the underlying character data.

Prior to Java 7, the pool lived in PermGen (Permanent Generation), which had a fixed size and could cause `OutOfMemoryError` under heavy string usage. From Java 7 onwards, the pool was moved to the main heap, allowing it to participate in normal garbage collection and be resized dynamically.

You can manually add a string to the pool using `String.intern()`. This is useful when you receive strings from external sources (e.g., parsing files) and want to deduplicate them for memory efficiency. For example, `String s = new String("hello").intern()` places the value in the pool and returns the canonical reference.

The key distinction is between `String s1 = "hello"` (uses the pool) and `String s2 = new String("hello")` (creates a new heap object, bypassing the pool). This is why `s1 == s2` returns false even though the content is identical — `==` compares references, and `s2` is a distinct heap object.

Understanding the pool matters for performance-sensitive applications: overuse of `new String()` inflates heap usage unnecessarily, while aggressive interning of dynamic strings can bloat the pool. The practical guidance is to use literals and compile-time constants wherever possible and reserve `intern()` for well-understood deduplication scenarios.

What Separates a 2/3 from a 3/3

Common Mistakes

• Claiming the pool still lives in PermGen — it was moved to the heap in Java 7.
• Confusing pool membership with value equality; assuming all equal strings share the same reference.
• Overusing String.intern() on arbitrary runtime strings, treating it as a free optimization without considering pool bloat.

Follow-Up Questions

• Why does `new String("hello") == "hello"` return false even though the values match? — Focus on reference identity vs value equality, and how `new String()` bypasses the pool.
• When would you use String.intern() in production code? — Consider memory deduplication of high-cardinality repeated strings, e.g., parsed field names.
• How did moving the pool from PermGen to heap in Java 7 change GC behavior? — Interned strings became eligible for GC once no references remain, reducing OOM risk.

Related Questions

• JVM vs JRE vs JDK
• Java Platform Independence
• How JVM Works
• Main Features of Java
• public static void main