Strings: Garbage Collection and Immutability in Java

In Java, strings play a unique role in memory management due to their immutability and interning characteristics. These concepts not only improve performance but also introduce nuances to memory handling that are often essential in interviews.

Let’s explore Garbage Collection, and Immutability in depth, with notes on how the String Pool and JVM memory management interact with these concepts.

This post builds on concepts discussed in the previous article on String Pool and Memory Management. Reviewing that article first will provide a helpful foundation for understanding the topics covered here.

1. String Garbage Collection

In Java, string literals behave differently in terms of garbage collection (GC).

1. Unreferenced Literals in the String Pool

String string3 = "World"; // Stored in String Pool

// A new string is created in the pool due to case-sensitivity
string3 = "WORLD";

• In this example, the original "World" is still in the String Pool, even though string3 is reassigned.

• The JVM retains unreferenced literals in the pool, allowing future reuse, but these literals are NOT subject to garbage collection like regular heap objects.

2. Heap Objects

String str1 = new String("World"); // Stored in Heap

// String Pool reference is used now
// leaving the previous "World" eligible for GC in Heap
str1 = "WORLD";

• When created with new, a String goes to the heap instead of the String Pool.

• If the reference changes, as with str1, the unused "World" string in the heap can be garbage-collected since it is no longer referenced.

2. String Immutability

Strings in Java are immutable—once created, they cannot be modified. Any “modification” results in a new string object rather than changing the existing one.

Practical Effects of Immutability

1. Compile-Time Concatenation (Optimization with Literals)

   String string5 = "This" + "String";

• When concatenating literals, the Java compiler optimizes by performing the concatenation at compile time.

• The resulting string ("ThisString") is directly stored in the String Pool, avoiding the heap entirely.

• This process is also known as Constant Pool Folding.

2. Runtime Concatenation (No Optimization)

   String string1 = "Hello";
   string1 = string1 + "Hello"; // Stored in Heap

• When one or more operands are variables (non-literals), concatenation happens at runtime, resulting in a heap object that doesn’t reside in the String Pool.

• Example: The original "Hello" literal remains in the pool, while the concatenated "HelloHello" string is stored in the heap, confirming the immutability of the original "Hello".

3. Using concat() Method

   String string2 = "Hello";
   string2 = string2.concat("Hello"); // Stored in Heap

• The concat() method always performs runtime concatenation, placing the new string in the heap, irrespective of whether the operands are literals or variables.

4. Applying intern() Method

   String string3 = "World".concat(" says Hello").intern();

Process:

• First, the concat() operation creates a new string in the heap with the value "World says Hello", which string3 initially references.

• When we call intern(), it checks if this value is already in the String Pool. If not, it adds the value to the pool and returns a reference to that pooled instance.

• After calling intern(), string3 points to the pooled copy of the string. The original heap instance, now without any active references, becomes eligible for garbage collection, reducing unnecessary memory usage.

Summary of Key Points

• String Pool Optimization: The String Pool is crucial for saving memory by reusing literals.
• Immutability: Immutability makes strings thread-safe and reliable but can result in additional heap objects when modifying strings.
• Garbage Collection: Unreferenced literals in the pool are not garbage-collected, but unused heap-based strings are.

By understanding and leveraging these principles, Java developers can write more memory-efficient and performant code.

Related Posts

Happy Coding!