Where is String Pool Stored (Which Memory Area)?

🟢 Junior Level

String Pool is a special area where JVM stores unique strings. Its location has changed across different Java versions.

Brief history:

Java 6 and earlier: PermGen (special area for metadata) — frequent OutOfMemoryError: PermGen space errors
Java 7+: Java Heap (regular heap where all objects live) — now GC can remove unused strings from the pool

Why this matters: In modern Java, String Pool is in Heap, so it’s limited by the total memory size (-Xmx), not a separate limit.

Simple analogy: PermGen — like a small safe with fixed size. Heap — like a large warehouse that can be expanded.

Practical meaning: in Java 7+ you can intern more strings without separate configuration, but now the pool competes for the same memory as your objects.

When String Pool location doesn’t matter

For 95% of applications this is academic knowledge. This knowledge matters when: (1) mass intern(), (2) GC tuning, (3) migration between Java versions.

🟡 Middle Level

Version details

Java 6: PermGen

PermGen — a separate memory area for class metadata
Size is limited (-XX:MaxPermSize, usually 64-256MB)
GC in PermGen was inefficient
Excessive intern() → OOM: PermGen space

Java 7 (specifically, 7u6): String Pool moved from PermGen to Java Heap.

Moved to main heap
String Pool shares memory with all application objects
GC efficiently removes unreferenced strings
Limited only by -Xmx

Java 8+: Metaspace (NOT String Pool!)

PermGen replaced by Metaspace (in Native Memory)
String Pool remained in Java Heap (not in Metaspace!)
Common misconception — thinking the pool moved to Metaspace

Practical application

// In Java 7+ you can safely intern more strings
for (String city : cities) {
    city = city.intern(); // Won't cause OOM: PermGen
}
// But may cause OOM: Java heap space if heap is full

Typical mistakes

Mistake: Thinking String Pool is in Metaspace Solution: Pool is in Heap. Metaspace — only for class metadata
Mistake: Not configuring StringTableSize for mass intern() Solution: -XX:StringTableSize=1000003

🔴 Senior Level

Internal Implementation

JVM Memory Structure (Java 8+):

JVM Memory Layout:
├── Heap
│   ├── Young Generation (Eden, S0, S1)
│   ├── Old Generation
│   └── String Pool (StringTable) ← HERE
├── Metaspace (Native Memory)
│   └── Class metadata, method data
└── Code Cache
    └── JIT compiled code

StringTable:

// OpenJDK — StringTable — native hash table in C++
class StringTable : public RehashableHashtable<oop, mtSymbol> {
  // oop (ordinary object pointer) — internal JVM type for reference to Java object.
  // mtSymbol — memory category in JVM (Symbol = string data).
  // Stored in C++ heap, but String objects themselves — in Java Heap
};

Evolution — details of the move

Java 6 (PermGen):

Strings in pool lived forever (or until OOM)
GC didn’t clean PermGen efficiently
-XX:MaxPermSize=256m — hard limit

Java 7 (move to Heap):

JEP: moving String Table to Java Heap
Reason: PermGen was being removed in future versions
Strings became regular objects for GC

Java 8 (Metaspace):

PermGen removed completely
Metaspace — Native Memory, auto-expanding
String Pool did not move — stayed in Heap

Architectural Trade-offs

Pool in Heap — pros:

GC manages strings as regular objects
No separate limit — limited by common -Xmx
String entries without references can be GC’d

Pool in Heap — cons:

Large number of interned strings competes for Heap with business objects
May increase GC pause time (more objects to scan)
G1 GC: StringTable scan adds overhead to evacuation pause

Edge Cases

GC and String Pool: In Java 7+ strings from pool CAN be GC’d if no strong references exist. But if you hold references — they won’t be collected.
Weak References in StringTable: Some JVMs experimented with weak references for StringTable entries, but HotSpot uses strong references.
String Deduplication vs Pool: Deduplication (G1 GC) combines byte[] arrays in Heap, but this is a separate mechanism from String Pool.

Performance

Production Experience

Scenario: Migrating application from Java 8 to Java 17:

Team thought String Pool was in Metaspace
Configured -XX:MaxMetaspaceSize=512m, but didn’t increase -Xmx
Result: OOM: Java heap space under load
Fix: increased -Xmx from 2g to 4g, pool worked correctly

Monitoring

# Check StringTable size
jcmd <pid> VM.stringtable -verbose

# Memory usage
jstat -gc <pid> 1000

# Heap dump analysis
jmap -dump:live,format=b,file=heap.hprof <pid>
# In MAT: java.lang.String → dominator tree

Best Practices for Highload

String Pool in Heap → account for it when calculating -Xmx
For mass intern(): -XX:StringTableSize=1000003 (or larger)
Monitor via jcmd VM.stringtable
For automatic deduplication: -XX:+UseStringDeduplication (G1 GC)

🎯 Interview Cheat Sheet

Must know:

Java 6 and below: String Pool in PermGen (fixed size, frequent OOM)
Java 7+: String Pool moved to Java Heap (managed by GC, limited by -Xmx)
Java 8+: Metaspace replaced PermGen, but String Pool stayed in Heap (NOT in Metaspace!)
In Heap, GC can remove strings from pool if unreferenced
Common misconception — thinking pool is in Metaspace
StringTable — native hash table in C++, but String objects — in Java Heap

Frequent follow-up questions:

Why was String Pool moved from PermGen to Heap? — PermGen was being removed, GC in PermGen was inefficient, in Heap strings became regular objects for GC.
Can String Pool cause OOM? — Yes, OOM: Java heap space in Java 7+ (previously OOM: PermGen space).
In which memory area is String Pool in Java 17? — In Java Heap. Not in Metaspace, not in Code Cache.
How to monitor String Pool? — jcmd <pid> VM.stringtable -verbose.

Red flags (DON’T say):

❌ “String Pool is in Metaspace” — most common mistake, pool is in Heap
❌ “String Pool has a separate memory limit” — limited by common -Xmx
❌ “GC doesn’t clean String Pool” — in Java 7+ can remove unreachable entries
❌ “PermGen and Metaspace — the same thing” — Metaspace is in Native Memory, PermGen was in Heap

Related topics:

[[1. How String Pool Works]]
[[12. Can String Pool Cause OutOfMemoryError]]
[[3. When to Use intern()]]
[[22. What is String Deduplication in G1 GC]]