← Back to Java

String Immutability

JavaMidjava

The Question

Why are Strings immutable in Java?

What a Strong Answer Covers

  • security
  • String Constant Pool sharing
  • thread safety without synchronization
  • hash code consistency
  • once created value cannot change

Senior-Level Answer

String immutability in Java means that once a `String` object is created, its character sequence cannot be changed. Any operation that appears to modify a string — concatenation, `replace()`, `substring()` — actually creates and returns a new `String` object. The original remains unchanged.

There are four core reasons this design decision was made.

First, thread safety. Because strings cannot be mutated, they can be freely shared across threads without synchronization. No thread can corrupt another's view of the string.

Second, security. Strings are widely used for sensitive data — file paths, network hostnames, database URLs, class names for reflection. If strings were mutable, defensive code could pass a validated string to a security-sensitive API only to have it mutated by another thread before the API consumed it. Immutability closes that attack surface.

Third, hashCode caching. `String` caches its `hashCode` after the first computation. This is only safe because the content can never change. It makes strings highly efficient as `HashMap` keys — the hash is computed once and reused on every lookup.

Fourth, String Constant Pool participation. The JVM pools string literals and returns shared references for identical values. This optimization is only correct if strings cannot be mutated — otherwise modifying one reference would corrupt all others sharing the same pooled object.

The implementation enforces immutability by making the internal `char[]` (or `byte[]` in Java 9+ with compact strings) both `private` and `final`, and by never exposing a reference to it. Even though `final` on an array only freezes the reference, not the array contents, the array is never leaked.

A common interview follow-up: immutability does not mean the reference variable is constant. `String s = "a"; s = "b";` is valid — you are rebinding the variable, not mutating the object.

What Separates a 2/3 from a 3/3

2/3 — Passing but Incomplete

Names thread safety and security as motivations and explains that operations produce new objects.

3/3 — Strong Answer

Also explains hashCode caching, String Constant Pool safety, and the internal implementation detail of a private final char array.

Common Mistakes

  • Saying the reference variable is immutable rather than the object itself.
  • Omitting hashCode caching as a motivation, which is directly tied to HashMap performance.
  • Confusing `final` on a variable with immutability of the object it points to.

Follow-Up Questions

  • How does immutability make String a good HashMap key? — hashCode is computed once and cached; the value cannot change between put() and get() calls.
  • Could you make a class behave like String in terms of immutability? What steps are required? — Private final fields, no setters, defensive copies of mutable fields, final class or sealed hierarchy.
  • Why is StringBuilder preferred over String concatenation in loops? — Each `+` creates a new String object; StringBuilder mutates a buffer in place, avoiding O(n²) allocations.

Related Questions

  • JVM vs JRE vs JDK
  • Java Platform Independence
  • How JVM Works
  • Main Features of Java
  • public static void main

Can You Explain This Cold?

Reading the answer is step one. Explaining it unprompted — under interview pressure — is what actually matters. Get AI-graded feedback on your answer with follow-up probes on your weak points.

Get Graded — Free Assessment
GrindQuestionsAITechnical interview assessment
TermsPrivacyAbout