What Is the String Constant Pool?

The String constant pool is a special area of memory that the JVM uses to store String literals and the results of intern(). Its defining rule is that every distinct literal value has exactly one canonical instance, and the pool hands out references to that instance. Two pieces of code that both write "hello" therefore end up pointing at the same object.

Three kinds of value end up in the pool. String literals written directly in the source. The compiled constant pool of each class file, which the class loader resolves at link time, is where the literal comes from. And the results of calling intern() explicitly.

What is not in the pool is any String built at run time by concatenation of non-constant expressions, or by new String(...), or by reading from a file. Those are ordinary heap objects like any other. The exception is the compile-time constant folding: if every operand of a + is a compile-time constant, the compiler folds the expression into a single literal, and that literal is interned like any other.

Because interning means one instance per value, the pool also acts as a garbage-collection root for those entries. The pool used to live in the permanent generation, which was never collected; it now lives on the heap, so pooled Strings can be reclaimed under memory pressure. That change is invisible in normal code and important under load, and it is why old advice about permanent generation size no longer applies.

The practical reason the pool matters is performance: a literal comparison against a pooled String can be a cheap reference check, and the shared instances cut memory use for repeated values.

You compare the references with == and compare the values with equals. Running both tells you whether the two references point at the same pooled instance.

public class Main {
    public static void main(String[] args) {
        String literal = "hello";
        String literal2 = "hello";
        String fromNew = new String("hello");
        String fromConcat = "he" + "llo";   // folded at compile time

        System.out.println("literal == literal2         : " + (literal == literal2));
        System.out.println("literal == fromNew         : " + (literal == fromNew));
        System.out.println("literal == fromConcat      : " + (literal == fromConcat));
        System.out.println("literal.equals(fromNew)    : " + literal.equals(fromNew));

        // intern() returns the canonical pooled instance.
        System.out.println("literal == fromNew.intern(): " + (literal == fromNew.intern()));
    }
}

Reading the output: the two literals are the same object because they came from the same pooled entry. The new String version is a distinct object with the same contents, so == is false while equals is true. The concatenated literal is the same object as the original because both operands were compile-time constants, so the compiler folded the expression into a single interned literal. And interning the new String returns the pooled instance, making the reference comparison true again.

The important caveat is that == on Strings is almost always a bug. It happens to work for literals, so tests pass, and then it fails the first time the value arrives from a database, a configuration file or a network response. The fix is equals, and the only time reference comparison on Strings is legitimate is when you are deliberately testing pool identity, which is exactly what this snippet does.

The location of the pool has changed over time. Interned Strings used to live in the permanent generation, a special area of the heap that the garbage collector never touched — the reasoning was that a literal is reachable for as long as its class is loaded, so freeing it early was pointless. The pool now lives in the ordinary heap, alongside the rest of the live objects. The practical effect is that pooled Strings now participate in normal garbage collection, so a heap under pressure can reclaim them and the pool no longer grows without limit in the way the permanent generation did.

The more visible change came later: the permanent generation was removed entirely. Class metadata moved to Metaspace, which is native memory rather than heap, and the string pool stayed on the heap with it. The practical consequence for anyone who used to tune permanent generation size is that the old -XX:PermSize flags are gone and Metaspace is bounded by the limits of the operating system instead.

There is a second, subtler change people forget: the internal representation of a String also changed. Instead of always storing a char array, a String keeps a byte array plus a coder flag saying whether the contents are Latin-1 or UTF-16. For the ASCII text that dominates most business data that halves the memory a String occupies, while non-Latin-1 content still uses the wider form.

Why it matters: on a service holding millions of Strings, the pool and the String representation dominate the heap. Interning every incoming value to collapse duplicates is a legitimate optimisation, but it needs a bounded cache, because an unbounded intern of user-supplied values is itself a memory leak.