Difference Between Creating String via Literal and via new

🟢 Junior Level

There are two ways to create a string in Java, and they work differently:

Via literal (recommended):

String s = "Hello";

JVM checks the String Pool. If such a string already exists — returns a reference to it. If not — creates a new one in the pool.

Via constructor new (not recommended):

String s = new String("Hello");

Always creates a new object in regular heap, ignoring the String Pool for the object itself.

Example:

String s1 = "Hello";
String s2 = "Hello";
String s3 = new String("Hello");

System.out.println(s1 == s2); // true  (same object in pool)
System.out.println(s1 == s3); // false (s3 — separate object)
System.out.println(s1.equals(s3)); // true (content is the same)

When to use: In 99% of cases, use literals. The new String(...) constructor is mainly needed when converting from byte[]/char[], and also in rare cases for creating a guaranteed independent copy (defensive copying).

🟡 Middle Level

How it works internally

Literal:

String s = "Hello";

Bytecode: LDC instruction (Load Constant)
JVM checks String Pool by string hash
If found — returns reference, if not — creates object in pool
Optimization happens at class loading stage

Constructor:

String s = new String("Hello");

Bytecode: NEW → DUP → LDC "Hello" → INVOKESPECIAL
The literal "Hello" is already in String Pool
new String(...) creates a second object in Regular Heap with the same content
Result: two objects in memory with identical text

Typical mistakes

Mistake: new String("literal") for “guaranteed uniqueness” Solution: This is an antipattern. String object uniqueness is almost never needed
Mistake: Thinking new String() is faster Solution: Literals are faster — they use the pool and don’t create extra objects

When the constructor is actually needed

🔴 Senior Level

Internal Implementation

Literal bytecode:

0: ldc           #2  // String Hello
2: astore_1

One instruction — loading constant from class Constant Pool.

Constructor bytecode:

new           #3  // class java/lang/String    // NEW — allocates memory for new String object
dup                                        // DUP — duplicates reference for constructor
ldc           #2  // String Hello            // LDC — loads literal from Constant Pool
invokespecial #4  // Method ..."<init>":...  // INVOKESPECIAL — calls String constructor
astore_1

Four instructions: memory allocation, reference duplication, constant loading, constructor call.

Architectural Trade-offs

Why the constructor exists:

Historically: for creating strings from raw data (byte[], char[], int[] code points)
Practically: new String(String original) copies content into a new array (in Java 7+), guaranteeing independence from the original

Why an independent copy might be needed:

Before Java 7u6: substring() shared the parent’s char[]. new String(substring) copied the data, freeing the parent array for GC
In modern Java this is irrelevant — substring() always copies data

Edge Cases

String with intern():
```
String s = new String("Hello").intern();
```
Creates an object in Heap, then intern() checks the pool. If "Hello" is already in pool — returns pool reference, and the Heap object becomes garbage.

Constant Folding:

String s = "Hel" + "lo"; // Compiler folds this into "Hello" at compile time

Result will be in String Pool, as if you wrote "Hello".

Runtime concatenation:

String a = "Hel";
String s = a + "lo"; // NOT in pool! Created via invokedynamic/StringBuilder

Performance

Production Experience

In JSON/XML parsers, where the same field ("name", "id", "type") appears millions of times:

Without pool: millions of String objects → significant GC overhead
With pool: dozens of unique strings → 90%+ memory savings on strings

Monitoring

# See number of String objects
jmap -histo:live <pid> | grep java.lang.String

# Analysis via JOL
System.out.println(GraphLayout.parseInstance(s1).toFootprint());
System.out.println(GraphLayout.parseInstance(s2).toFootprint());

Best Practices

Never use new String("literal") without a justified reason
To move a string from Heap to Pool, use .intern()
If you need a guaranteed independent copy — new String(existingString) (though this is rarely required)

🎯 Interview Cheat Sheet

Must know:

Literal String s = "Hello" — JVM checks String Pool, returns reference from pool or creates in pool
new String("Hello") — always creates a NEW object in heap (even if literal is already in pool)
Literal uses LDC bytecode, constructor — NEW + DUP + LDC + INVOKESPECIAL
Constant folding: "Hel" + "lo" is folded by compiler into "Hello" at compile time
Runtime concatenation (a + "lo") — NOT in pool, created via invokedynamic/StringBuilder
new String("...") creates 2 objects: literal in pool + object in Heap

Frequent follow-up questions:

How many objects does new String("Hello") create? — One or two. The literal "Hello" is already in pool (on class load), new String() creates a second object in Heap.
Why does new String(String) constructor even exist? — For creating an independent copy (defensive copying). Before Java 7u6 this was needed to free memory from shared array.
Which is faster: literal or new String()? — Literal is faster — 0 allocations (if already in pool). new String() — ~10-20ns + GC pressure.
When is new String() from byte[]/char[] needed? — This is the main approach for I/O: new String(bytes, UTF_8), new String(chars).

Red flags (DON’T say):

❌ “new String("literal") creates a unique string” — creates a duplicate, not uniqueness
❌ “Literal and new String() — the same thing” — different memory placement
❌ “new String() is faster than literal” — opposite, literal is faster
❌ “Constant folding works for variables” — only for static final constants and literals

Related topics:

[[1. How String Pool Works]]
[[3. When to Use intern()]]
[[9. Can You Use == to Compare Strings]]
[[7. What Happens When Concatenating Strings with + Operator]]