Strings
String Pool
Understand Metaspace memory allocations, interned string caching, and String Pool garbage collection.
Interview: Tests String.intern() allocations, pool locations across Java versions, and garbage collection behavior of interned entries.
The String Pool (also known as the String Table) is a special storage area in Java heap memory. It is a hashtable maintained by the JVM to cache unique string instances. By reuse of identical string literals, the pool reduces memory allocations and optimizes memory utilization.
Core Idea
The String Pool is a JVM-managed hashtable that stores references to unique string literals, preventing duplicate allocations.
Why It Matters
In Java 7+, the pool was relocated to the main heap. This allows unused interned strings to be garbage collected, avoiding PermGen OOM crashes.
Interview Lens
Expect deep checks on String.intern() mechanics, pool memory location changes, and GC behavior of pool entries.
The intern() Method
When a program invokes str.intern(), the JVM checks the String Pool for an identical string:
- If the pool already contains a string equal to this object (as determined by
equals()), the reference of the pooled string is returned directly. - If the string is not in the pool, this string object's reference is added to the pool, and this reference is returned.
Memory Location Evolution
The memory location of the String Pool changed in Java 7:
| JVM Area | Java 6 and Earlier | Java 7 and Later |
|---|---|---|
| Location | PermGen (Permanent Generation) | Java Heap |
| Size Limit | Fixed (difficult to configure dynamically) | Dynamic (bound only by heap limits) |
| Garbage Collection | Rarely collected (causes OutOfMemoryError) | Standard GC (collected when references expire) |
Common Pitfalls
- Over-Interning: Calling
intern()on thousands of dynamic strings (like UUIDs or user inputs). This increases hash collisions in the JVM's internal hashtable, degrading search speeds. - Assuming No GC: Assuming pooled strings are never garbage collected, which is untrue since Java 7.
- Confusing references: Forgetting that
intern()returns the pooled reference, but does not modify the original reference. You must re-assign the returned reference.
Best Practices
- Only intern strings that have a bounded, highly repetitive set of values (e.g., country codes or state statuses).
- Always re-assign the result of
intern():str = str.intern();. - If your application interns millions of strings, adjust the pool bucket capacity using the JVM flag
-XX:StringTableSize=<size>.
Interview-Relevant Information
Q1: What is the benefit of moving the String Pool from PermGen to the Heap in Java 7?
Answer: PermGen was a fixed-size memory area that was rarely garbage collected, making applications prone to java.lang.OutOfMemoryError: PermGen space if they interned many strings. Relocating it to the main heap enables standard GC cycles to reclaim unused interned strings, avoiding PermGen OOM crashes.
Q2: If s1 = new String("abc"), does s1 == s1.intern() return true or false?
Answer: It returns false. s1 references the duplicate String object created on the heap. Calling s1.intern() returns the reference to the cached string in the pool. Since they are different objects at different memory addresses, == evaluates to false.
Quick Checklist
Can you explain String.intern() execution, locate the pool in memory across Java versions, configure table sizes, and manage GC behaviors? If yes, you understand the String Pool.
Use Cases
Reducing heap memory consumption in applications that process repetitive values like state codes.
Optimizing lookup comparisons by interning keys to enable faster identity evaluations.
Common Mistakes
Interning unique dynamic strings like transaction IDs, filling the StringTable and slowing down searches.
Neglecting to assign the result of the intern() method to a variable.