Why `String` Is Immutable in Java — Security, Hashing, the String Pool, and Thread Safety

Q: Why `String` Is Immutable in Java — Security, Hashing, the String Pool, and Thread Safety

`String` is immutable for **four intertwined reasons**: **(1) Security** — strings used as file paths, URLs, class names, and credentials can be passed between trust boundaries knowing no caller can mutate them later; **(2) Hash caching** — `String` caches its `hashCode()` on first call; mutation would silently break every `HashMap` and `HashSet` entry; **(3) String pool / interning** — the JVM interns string literals to save memory and relies on immutability to share instances safely; **(4) Thread safety** — immutable objects are inherently thread-safe, no synchronization needed. The trade-off is modification cost — `s = s + "x"` allocates a new String — so use `StringBuilder` for heavy concatenation and Java 9+ compact strings reduce the memory overhead.

Intermediate·3 min read·

AmazonGoogleMicrosoftOracleFlipkart

Fast recall

Quick revision

Core answer

String is immutable for four intertwined reasons: (1) Security — strings used as file paths, URLs, class names, and credentials can be passed between trust boundaries knowing no caller can mutate them later; (2) Hash caching — String caches its hashCode() on first call; mutation would silently break every HashMap and HashSet entry; (3) String pool / interning — the JVM interns string literals to save memory and relies on immutability to share instances safely; (4) Thread safety — immutable objects are inherently thread-safe, no synchronization needed. The trade-off is modification cost — s = s + "x" allocates a new String — so use StringBuilder for heavy concatenation and Java 9+ compact strings reduce the memory overhead.

Interview Answer3 min

Immutability of String is one of Java's foundational design decisions — it's not just a default; it's there for four interconnected reasons.

Security

Strings flow across trust boundaries as file paths, URLs, class names, credentials
If mutable, a caller could validate a safe path and another thread could rewrite it before the actual filesystem call — a TOCTOU race
ClassLoader.loadClass, Class.forName, File, URL, SSL — all rely on strings being immutable to remain secure

Hash caching

String.hashCode() is computed once and cached internally
Every HashMap.get("key") uses the cached hash — near-free after the first call
If strings were mutable, cached hashes would point to old buckets; entries would silently disappear
This is why mutable objects shouldn't be map keys in general

String pool

The JVM interns string literals: "hello" == "hello" from two different places is the same object
Saves significant memory (50KB–tens of MB depending on app)
Sharing is only safe because strings are immutable — otherwise one caller mutating the pooled instance corrupts everyone

Thread safety

Immutable objects are inherently thread-safe — no locks, no volatile, no memory barriers
You can pass a String between threads with zero synchronization overhead
Contrast with StringBuilder, which is not thread-safe; StringBuffer exists only because String avoided that synchronization cost

Cost and modern mitigations

Every modification creates a new object — naive += in a loop is O(n²)
StringBuilder for heavy concatenation, StringBuffer for the rare thread-safe case
Java 9+ compact strings use byte[] internally with a Latin-1 flag — half the memory for English text
Java 9+ StringConcatFactory lets the JVM pick the fastest + strategy at runtime via invokedynamic

Recommendation: Treat String immutability as a feature, not a limitation. Use StringBuilder in loops and any heavy text construction, but rely on String everywhere else — the hash caching, interning, and thread safety payoffs show up in almost every Java application. And remember: the same reasoning argues for making your own value types immutable — records and value classes (Project Valhalla) extend this philosophy to user code.

Interview-ready guide

Interview answer