String, StringBuilder, and StringBuffer: Immutability and the String Pool

Part 1: The Immutability of String

The single most important characteristic of the Java String class is its immutability. This means that once a String object is created, its content cannot be changed. Any operation that appears to modify a String actually creates a brand-new String object.

Let's see this in action and understand the mechanism behind it.

Key Concepts: Immutability and the String Pool

As the video explained, when you write code like this:

String s1 = "Java";
s1.concat(" is great"); // This creates a NEW string object
System.out.println(s1); // This will still print "Java"

The original String object containing "Java" remains untouched. The concat() method returns a new String object containing "Java is great", which is then discarded unless you assign it to a new reference:

String s2 = s1.concat(" is great");
System.out.println(s2); // Prints "Java is great"

This behavior is enabled by the String Pool. As we learned in the last lesson, objects live on the Heap. The String Pool is a special, optimized area of the Heap where Java stores String literals.

When the JVM encounters a string literal like "Java", it does the following:

1. It checks the String Pool to see if a string with this value already exists.
2. If it exists, the JVM returns a reference to that existing object in the pool.
3. If it doesn't exist, a new String object is created in the pool, and a reference to it is returned.

This is a powerful memory optimization technique.

Part 2: Creating Strings: Literals vs. new Keyword

How you create a string has significant implications for memory. You can create a string as a literal or by explicitly using the new keyword.

// s1 refers to an object in the String Pool
String s1 = "Test"; 

// s2 also refers to the SAME object in the String Pool
String s2 = "Test"; 

// s3 refers to a NEW object created directly on the Heap
String s3 = new String("Test");

Let's watch a video segment that clarifies this distinction and introduces the intern() method, a way to manually interact with the String Pool.

To summarize:

• String s = "literal"; uses the String Pool.
• String s = new String("literal"); bypasses the pool and always creates a new object on the heap.
• s.intern() on a heap-allocated string will check the pool. If an equivalent string exists, the pooled reference is returned. If not, the string is added to the pool.

This difference is a classic interview trap, often tested with questions about the == operator versus the .equals() method.

• == compares object references (memory addresses).
• .equals() compares the actual content of the strings.

public class StringComparison {
    public static void main(String[] args) {
        String s1 = "SpringBoot";
        String s2 = "SpringBoot";
        String s3 = new String("SpringBoot");
        String s4 = s3.intern();

        System.out.println("s1 == s2: " + (s1 == s2));
        System.out.println("s1 == s3: " + (s1 == s3));
        System.out.println("s1.equals(s3): " + s1.equals(s3));
        System.out.println("s1 == s4: " + (s1 == s4));
    }
}

s1 == s2: true
s1 == s3: false
s1.equals(s3): true
s1 == s4: true

Part 3: Why Are Strings Immutable?

This is a cornerstone interview question. The decision to make String immutable in Java was deliberate and provides several key benefits.

Here is a summary of the reasons, perfect for an interview response:

1. String Pool & Performance: Immutability is what makes the String Pool possible. If strings were mutable, one reference variable could change the string's value, which would affect all other references pointing to that same object in the pool. This would be chaotic. By being immutable, strings can be safely shared, saving significant memory.

2. Thread Safety: Because a String object's state can never change after creation, it is inherently thread-safe. You can pass strings between threads without any need for synchronization, which simplifies concurrent programming.

3. Security: Strings are widely used for sensitive information like database connection URLs, usernames, passwords, and file paths. If strings were mutable, a malicious piece of code could potentially change the value of a string after a security check has been performed, leading to serious vulnerabilities.

4. Hashcode Consistency: String is a very common key in HashMap. A HashMap relies on the key's hashCode() remaining constant. Since String is immutable, its hashCode() is calculated once and cached. If strings were mutable, the hash code could change, making it impossible to retrieve the value associated with that key from the map.

Part 4: The Mutable Alternatives - StringBuilder and StringBuffer

If every string modification creates a new object, what happens when you need to build a string through many modifications, like in a loop?

// Inefficient code
String logMessage = "";
for (String part : logParts) {
    logMessage += part; // Creates a new String object in every iteration!
}

This is extremely inefficient. It creates a large number of intermediate String objects that need to be garbage collected. To solve this, Java provides two mutable alternatives: StringBuilder and StringBuffer.

Let's watch a video that compares these classes and explains when to use them.

Here's the breakdown of the three classes:

The efficient way to write the previous loop example is with StringBuilder:

// Efficient code
StringBuilder logBuilder = new StringBuilder();
for (String part : logParts) {
    logBuilder.append(part); // Modifies the internal buffer, no new objects created
}
String logMessage = logBuilder.toString(); // Creates the final String once

Conclusion

You've now covered one of the most fundamental topics in Core Java. A deep understanding of how String, StringBuilder, and StringBuffer work is a strong signal to interviewers that you have a solid grasp of Java's design principles.

Key Takeaways:

• String is immutable: Its value cannot change after creation. This provides thread safety, security, and enables performance optimizations like the String Pool.
• The String Pool: A special area in the heap that stores string literals to conserve memory by reusing objects with the same value.
• "literal" vs. new String(): Literals use the pool, while new always creates a new object on the heap.
• StringBuilder and StringBuffer are mutable alternatives for when you need to perform many modifications to a string.
• StringBuilder is the standard choice for most use cases (single-threaded). StringBuffer is its slower, thread-safe counterpart.

In our next lesson, we will dive deeper into a related topic: implementing the equals() and hashCode() contract. We briefly touched on hashcode consistency as a reason for string immutability, and next time, we'll explore exactly what that contract entails and why it's so critical for collections like HashMap.