String Immutability

In Java, the String class is immutable, meaning that once a String object is created on the heap, its character sequence cannot be modified. This design decision was made to support core JVM features including security, memory pooling, and performance caching.

Engineering Reasons for Immutability

The String class is designed as immutable for four primary reasons:

1. Security: Strings are used as parameters for critical configurations (e.g., classloading names, file system paths, database connection strings, network ports). If Strings were mutable, a malicious agent could pass a validated path and then modify it on another thread (TOCTOU vulnerability) to access sensitive data.
2. String Pool Caching: Immutability allows the JVM to share string objects among multiple references in the String Pool safely. If a string were modified through one reference, it would unexpectedly change values for all other references pointing to the same pool entry.
3. Thread Safety: Immutable objects are inherently thread-safe. They can be shared across multiple threads without synchronization, eliminating thread lock overhead.
4. HashCode Caching: Since the character content is immutable, the string's hashcode is guaranteed never to change. The JVM computes the hashcode once during initialization and caches it in a private hash field. This enables constant-time key lookups in HashMap and HashSet.

How Immutability is Enforced

The immutability contract is enforced through class design:

• The class is declared final, preventing subclasses from overriding methods to inject mutable behavior.
• The backing array (byte[] or char[]) is declared private final.
• The class does not expose any setter methods, and internal methods use defensive copying when returning arrays.

Common Pitfalls

• Assuming Mutability: Expecting methods like toUpperCase() to modify the calling string in-place (e.g. writing str.toUpperCase(); without re-assigning the returned string).
• Attempting Reflection modifications: Accessing private fields to modify backing arrays. This corrupts String Pool entries, causing unpredictable bugs.
• Memory retention: Storing sensitive data like passwords as Strings, leaving them in memory until garbage collection runs.

Best Practices

• Always re-assign variables when using string modification methods: str = str.trim();.
• Use char[] arrays instead of Strings for passwords so they can be zeroed out immediately after use.
• Leverage final variables when declaring string configurations to protect runtime invariants.

Interview-Relevant Information