BrewlearnThe String pool in Java
Literals are interned; new String creates a separate object.
"cat" in a hundred places in your program. How many "cat" objects exist in memory? The answer is one — and new can quietly break that.One shared shelf
Java keeps a String pool: a shelf with one copy of every literal in your code. Every "cat" you write points to the same pooled object. That's safe precisely because Strings are immutable.
String a = "cat";
String b = "cat";
// a and b: the SAME object`new` skips the shelf
new String("cat") always creates a separate object, outside the pool, even though the text matches. It doesn't add a second pool entry and it isn't mutable — it's just a wasteful extra copy. You almost never need it.
String c = new String("cat");
// same text, different objectShelf or new?
== checks whether two variables point to the same object. What prints?
String x = "dog";
String y = "dog";
String z = new String("dog");
System.out.println(x == y);
System.out.println(x == z);true truetrue falsefalse false
Show the answer
true then false. x and y share the pooled literal. z was built by new, so it's a different object even though the text is identical.
Glued at compile time
"hel" + "lo" uses only literals, so the compiler joins them into "hello" before the program runs — it's the pooled literal. But if a piece is an ordinary variable, the join happens at runtime and produces a new object.
String a = "hel" + "lo"; // pooled "hello"
String part = "hel";
String b = part + "lo"; // new objectintern() fetches the shelf copy
intern() returns the pooled String with the same text. What prints?
String p = "ja";
String b = p + "va";
System.out.println("java" == b);
System.out.println("java" == b.intern());true truefalse truefalse false
Show the answer
false then true. p + "va" was built at runtime, so it's a new object. b.intern() hands back the pooled "java", which is the very object the literal refers to.
Don't lean on the pool
Because literals share one object, == *seems* to compare text — in tests full of literals. Text built at runtime (concatenation, user input, files) is a new object, and == suddenly fails. The pool is a memory optimization, not a way to compare Strings.
In real projects
Apps that hold millions of repeated strings (country codes, status values, JSON keys) can waste lots of memory on duplicates. The G1 garbage collector offers -XX:+UseStringDeduplication to share the character data of equal Strings automatically — the pool idea, applied at runtime.
Key takeaways
- Identical literals share one pooled object
- new String(...) always creates a fresh object
- Constant expressions like "a" + "b" are joined at compile time and pooled
- intern() returns the pooled copy of a String's text
💡 The pool is a shared library shelf: everyone asking for the same title gets the same copy, unless they insist on a new print.
Before Java 7 the String pool lived in "PermGen", a small fixed memory area, and interning too many Strings could crash with OutOfMemoryError: PermGen space. Since Java 7 the pool lives on the normal heap.
Practice questions
What does this print?
String a = "cat";
String b = "cat";
String c = new String("cat");
System.out.println(a == b);
System.out.println(a == c);- true true
- true false
- false false
- false true
Check your answer
true false. a and b both point to the pooled literal. new String always creates a separate object, so a == c compares two different references.
What does this print?
String a = "hello";
String b = "hel" + "lo";
System.out.println(a == b);- true
- false
- Compile error
Check your answer
true. "hel" + "lo" is a compile-time constant, so the compiler folds it into the literal "hello", which is the same pooled object as a.