Immutability in Java: Why ‘final' Isn’t Always Enough for Thread Safety

Image taken from https://muratakkan.medium.com/

In modern programming, especially in multi-threaded environments, immutability is a powerful design principle that can greatly simplify code and reduce bugs. Java provides tools like the final keyword to make variables immutable, but achieving true immutability requires more than just marking fields as final. Many Java developers believe that simply using final ensures thread safety, but the truth is more nuanced.

In this article, we’ll dive into immutability in Java, explore why final isn't always enough for thread safety, and examine real-world use cases where immutability can help prevent bugs in concurrent programming. We will also look at examples to better understand the concept.

What is Immutability?

Immutability in Java refers to objects whose state cannot change after they are created. Once an immutable object is constructed, its data cannot be modified. Immutable objects are inherently thread-safe because no thread can change their state after they are created. As a result, there are no race conditions to worry about when using immutable objects across multiple threads.

Image taken from Google

Characteristics of an Immutable Object:

1. All fields of the object are set once and cannot be changed after construction.
2. The object does not provide setters or any methods that modify its state.
3. If the object holds references to other mutable objects, those references are not exposed or modified externally.

Common Immutable Classes in Java:

• String: One of the best-known immutable classes. Once a String object is created, it cannot be modified.
• Wrapper classes: Classes like Integer, Double, Boolean, etc., are also immutable.

The Role of final in Immutability

In Java, the final keyword is often associated with immutability. When used with variables, final ensures that the variable's value cannot be changed after it has been initialized.

For example:

public class Person {
    private final String name;
    private final int age;
    public Person(String name, int age) {
            this.name = name;
            this.age = age;
        }
        public String getName() {
            return name;
        }
        public int getAge() {
            return age;
        }
    }

In this case, the Person class has two final fields, name and age, which are set during construction and cannot be changed later.

However, simply using final does not guarantee immutability, especially when the object has fields that are references to mutable objects.

Example: The Limits of final

Consider the following class:

public class Employee {
    private final String name;
    private final List<String> tasks;
    public Employee(String name, List<String> tasks) {
        this.name = name;
        this.tasks = tasks;
    }
    public List<String> getTasks() {
        return tasks;
    }
}

Here, while tasks is declared final, the reference to the list is immutable, but the contents of the list are not. You can still modify the tasks list, even though the tasks field is final.

Employee emp = new Employee("John", new ArrayList<>());
emp.getTasks().add("Complete project");  // This modifies the task list!

As you can see, marking a reference type (like List) as final only prevents reassigning the reference; it does not prevent modifying the contents of the referenced object. This shows that final alone is insufficient for deep immutability.

Why Immutability is Crucial for Thread Safety

In multi-threaded environments, race conditions occur when multiple threads attempt to modify the same mutable data concurrently. Immutable objects, on the other hand, are inherently thread-safe because their state cannot change once created.

When an object is immutable:

• There are no state changes, so no thread can observe the object in an inconsistent state.
• Synchronization is unnecessary since the object’s state does not change.

Case Study: Concurrent Modification Without Immutability

Let’s consider a simplified banking system where multiple threads update a bank account’s balance:

public class BankAccount {
    private double balance;
    public BankAccount(double balance) {
        this.balance = balance;
    }
    public void deposit(double amount) {
        balance += amount;
    }
    public double getBalance() {
        return balance;
    }
}

In a multi-threaded environment, if two threads call the deposit method simultaneously, you may encounter race conditions. For example, both threads may read the same balance before either has a chance to update it, leading to an incorrect final balance.

Solution: Immutable Design

To avoid such issues, you could create an immutable BankAccount where each update results in a new instance of BankAccount, leaving the original instance unchanged.

public final class BankAccount {
    private final double balance;
    public BankAccount(double balance) {
        this.balance = balance;
    }
    public BankAccount deposit(double amount) {
        return new BankAccount(this.balance + amount);
    }
    public double getBalance() {
        return balance;
    }
}

Now, instead of modifying the balance in place, each deposit returns a new BankAccount object with the updated balance. Since the original object remains unchanged, it’s inherently thread-safe, as no race conditions can occur.

Trade-offs of Immutability

While immutability solves many thread safety problems, it can also come with performance trade-offs, especially when creating new objects for each state change. Careful consideration is needed when working with large, complex objects in performance-critical systems. However, in most cases, immutability simplifies code and minimizes bugs in concurrent environments.

Techniques for Achieving Deep Immutability

1. Defensive Copying: If your object contains mutable fields (like a List or Map), you should make a defensive copy of those fields to ensure immutability.

public class Employee {
    private final String name;
    private final List<String> tasks;

    public Employee(String name, List<String> tasks) {
        this.name = name;
        this.tasks = new ArrayList<>(tasks);  // Create a defensive copy
    }

    public List<String> getTasks() {
        return Collections.unmodifiableList(tasks);  // Return an unmodifiable view
    }
}

In this case, we ensure that the tasks list cannot be modified from outside the class by making a defensive copy and returning an unmodifiable version of the list.

2. Use Immutable Collections: Java provides immutable collections, such as those from the java.util.Collections or java.util.List.of() method in Java 9+.

List<String> immutableTasks = List.of("Task 1", "Task 2");  // Immutable list in Java 9+

Using these immutable collections ensures that once created, the collection cannot be modified.

3. Final Classes: Marking a class as final prevents it from being subclassed, which is essential for maintaining immutability. If a mutable subclass can be created, it can violate the immutability of the parent class.

Case Study: Immutability in Real-World Applications

Example: Google’s Guava Library

Google’s Guava library is widely used in the Java ecosystem and offers a range of immutable collection classes like ImmutableList, ImmutableMap, and ImmutableSet. These classes ensure that the collection cannot be modified after creation.

List<String> immutableList = ImmutableList.of("A", "B", "C");
immutableList.add("D");  // Throws UnsupportedOperationException

In large-scale applications, using immutable collections like these can help prevent accidental modifications, particularly in concurrent environments where race conditions can arise.

Use Case: Financial Applications

Consider a financial trading platform where multiple threads are calculating real-time stock prices. If the system uses mutable objects to store and update prices, there is a high risk of inconsistent data due to race conditions.

Instead, by adopting immutability, the platform can ensure that once a price is calculated, it cannot be changed by other threads. Each update results in a new object, leaving the previous state untouched.

public final class StockPrice {
    private final String ticker;
    private final double price;
    public StockPrice(String ticker, double price) {
        this.ticker = ticker;
        this.price = price;
    }
    public StockPrice updatePrice(double newPrice) {
        return new StockPrice(this.ticker, newPrice);
    }
}

This design ensures that the original StockPrice object is never altered, preventing race conditions and making the system easier to reason about.

Conclusion: Why final Isn’t Always Enough

While the final keyword is a useful tool in achieving immutability, it is not sufficient on its own, especially in the context of complex, mutable objects. To achieve true immutability in Java, you must:

• Ensure that all fields are immutable, either through defensive copying or by using immutable collections.
• Override methods like equals() and hashCode() properly when needed.
• Design classes carefully to prevent unintended modifications, particularly in multi-threaded environments.

Immutability is a key strategy for simplifying concurrent programming, avoiding race conditions, and making your code easier to maintain. While there are trade-offs in terms of performance and memory, the benefits of reduced bugs and easier reasoning often outweigh the downsides, particularly in multi-threaded or distributed systems.