How Strings live in memory: the string pool

For this lesson, we'll focus on what happens in memory when you write a literal versus new String(...), how the ldc bytecode and the class constant pool feed the pool, where the pool has lived since Java 7, which expressions the compiler folds into constants, and how pooled strings get garbage collected. This topic is asked in almost every Java screen because one line, new String("a"), lets an interviewer check whether you can picture references, objects and the heap at the same time.

01Picture it first: a shared dictionary on the office shelf

Think of the pool as one printed dictionary on a shared shelf. When you need the word "PAID", you don't print your own copy; you walk to the shelf and point at the page that already exists. Everyone who points at that page is pointing at the same physical paper. new String("PAID") is like photocopying the page anyway: same words, different sheet.

That gives you the two questions an interviewer is really asking. "Same sheet?" is ==. "Same words?" is equals(). Let's draw it.

The picture below shows three variables after String a = "order"; String b = "order"; String c = new String("order");.

Fig. 1

Variables a and b point to the single pooled String for "order"; c points to a separate String created by new, and both String objects share one byte array

Notice three things.

1. a and b hold the same reference, because both literals resolve to the pooled object.
2. c points to a second String object that lives outside the pool.
3. Since Java 9, the String(String original) constructor copies the value field from the original, so both objects share one byte[]. You pay for one extra 24-byte String header object, not a second copy of the text.

02How literals reach the pool: the constant pool, ldc and the StringTable

Let's get the mechanics right, because senior interviewers like to go one level below "literals are pooled".

public class Order {
    static String status() {
        return "PAID";
    }

    static String copy() {
        return new String("PAID");
    }
}

Compile it with JDK 21 and run javap -c -v Order. The interesting parts look like this (constant pool indexes vary between compilers):

#7 = String             #8           // PAID
#8 = Utf8               PAID

static java.lang.String status();
   0: ldc           #7                // String PAID
   2: areturn

static java.lang.String copy();
   0: new           #9                // class java/lang/String
   3: dup
   4: ldc           #7                // String PAID
   6: invokespecial #11               // Method java/lang/String."<init>":(Ljava/lang/String;)V
   9: areturn