Do Immutability really means Thread Safety?

I have often read articles telling “If an object is immutable, it is thread safe”. Actually, I have never found an article that convinces me that immutable means thread safety. Even the book by Brian Goetz Java Concurrency in Practice with its chapter on immutability did not fully satisfied me. In this book we can read word for word, in a frame : Immutable objects are always thread-safe. I think this sentence deserve more explanations.

So I am going to try to define immutability and its relation to thread safety.

Definitions

Immutability

My definition is “An immutable object is an object which state does not change after its construction”. I am deliberately vague, since no one really agrees on the exact definitions.

Thread safety

You can find a lot of different definition of “thread safe” on internet. It’s actually very tricky to define it. I would say that a thread safe code is a code which has an expected behaviour in multi-thread environment. I let you define “expected behaviour”…

The String example

Lets have a look at the code of String (actually just a part of the code…):

public class String {
    private final char value[];

    /** Cache the hash code for the string */
    private int hash; // Default to 0

    public String(char[] value) {
        this.value = Arrays.copyOf(value, value.length);
    }

    public int hashCode() {
        int h = hash;
        if (h == 0 && value.length > 0) {
            char val[] = value;

            for (int i = 0; i < value.length; i++) {
                h = 31 * h + val[i];
            }
            hash = h;
        }
        return h;
    }
}

String is considered as immutable. Looking at its implementation, we can deduct one thing : an immutable can change its internal state (in this case, the hashcode which is lazy loaded) as long as it is not externally visible.

Now I am going to rewrite the hashcode method in a non thread safe way :

    public int hashCode() {
        if (hash == 0 && value.length > 0) {
            char val[] = value;

            for (int i = 0; i < value.length; i++) {
                hash = 31 * hash + val[i];
            }
        }
        return hash;
    }

As you can see, I have removed the local variable h and affected the variable hash directly instead. This implementation is NOT thread safe! If several threads call hashcode at the same time, the returned value could be different for each thread. The question is, does this class is immutable? Since two different threads can see a different hashcode, in an external point of view we have a change of state and so it is not immutable.

We can so conclude that String is immutable because it is thread safe and not the opposite. So… What’s the point of saying “Do some immutable object, it is thread-safe! But take care, you have to make your immutable object thread-safe!”?

The ImmutableSimpleDateFormat example

Below, I have written a class similar to SimpleDateFormat.

public class VerySimpleDateFormat {

    private final DateFormat formatter = SimpleDateFormat.getDateInstance(SimpleDateFormat.SHORT);

    public String format(Date d){
        return formatter.format(d);
    }
}

This code is not thread safe because SimpleDateFormat.format is not.

Is this object immutable? Good question! We have done our best to make all fields not modifiable, we don’t use any setter or any methods that let suggest that the state of the object will change. Actually, internally SimpleDateFormat change its state and that’s what makes it not thread safe. Since something change in the object graph, I would say that it’s not immutable, even if it looks like it… The problem is not even that SimpleDateFormat changes its internal state, the problem is that it does it in a non-thread safe way.

Conclusion of this example, it is not that easy to make an immutable class. The final keyword is not enough, you have to make sure that the object fields of your object doesn’t change their state, which is sometimes impossible.

Immutable objects can have non thread-safe methods (No magics!)

Let’s have a look at the following code.

public class HelloAppender {

    private final String greeting;

    public HelloAppender(String name) {
        this.greeting = "hello " + name + "!\n";
    }

    public void appendTo(Appendable app) throws IOException {
        app.append(greeting);
    }
}

The class HelloAppender is definitely immutable. The method appendTo accepts an Appendable. Since an Appendable has no guarantee to be thread-safe (eg. StringBuilder), appending to this Appendable will cause problems in a multi-thread environment.

Conclusion

Making immutable objects are definitely a good practice in some cases and it helps a lot to make thread-safe code. But it bothers me when I read everywhere Immutable objects are thread safe, displayed as an axiom. I get the point but I think it is always good to think a bit about that in order to understand what causes non-thread safe codes.

Thanks to the comment of Jose, I end up this article with a different conclusion. It’s all about the definition of immutable. It needs clarifications!

An object is immutable if :

  • All its field are initialized before being used (which means you can do lazy initialization)
  • The states of the field does not change after their initialization (does not change means that the object graph doesn’t change, even the internal state of the children)

An immutable object will always be thread-safe unless it deals it has to manipulate non thread safe objects.

This entry was posted in Java Core and tagged , . Bookmark the permalink.

6 thoughts on “Do Immutability really means Thread Safety?

  1. I don’t agree.

    “An immutable can change its internal state (in this case, the hashcode which is lazy loaded) as long as it is not externally visible.” Immutable means state does not change. The value of the hash does not change, it is just lazy loaded. It’s more like an on/off switch than changing values. The value of 0 would never be used anywhere. The state was always the calculated value, it just didn’t bother to do the calculation until first asked.

    Immutability means external factors cannot change internal state. As SimpleDateFormat has internal state that can be changed, I would say your VerySimpleDateFormat is not immutable in the first place. It doesn’t matter that the formatter reference doesn’t change.

    In HelloAppender, if Appendable was also immutable, you would have a thread-safe scenario. The problem isn’t with HelloAppender, but with the Appendable implementation. If they were both immutable, you would have thread safety.

    Read up on functional programming and languages like Clojure and you will understand how true immutability leads to thread safety.

  2. @Jose Fernandez : That is precisely why I write a blog, to have clever feedbacks like yours! Thanks for your comment!

    For String, the hashcode change from an internal point of view. It goes from zero to its calculated value. From an external value, it doesn’t, and that’s what make String immutable. If you take my not-thread safe implementation, you put a synchronised keyword at the correct place, everyone would have said that’s this String implementation makes it also immutable.

    For SimpleDateFormat, if you read the book “Java Concurrency in Practice” there is an example of immutable class containing a Set. I agree with the author, an immutable can be composed of mutable objects as long as they don’t modify their state. As I say, I don’t consider that VerySimpleDateFormat is immutable since the state of SimpleDateFormat changes. My point was just to say that making immutable objects is hard because you must have the control over your children hierarchy. Unfortunately Java is not designed to make it easy.

    For Appendable, I agree with you. And that’s why I said in the title “no magics”. An immutable object cannot expect to handle non thread-safe objects without having thread safety issues just because someone said “Immutable objects are thread-safe”.

    I am far from being an expert in Clojure, but functional programming is a completely different paradigm. It makes sense to have immutable data structures in functional programming and to have immutability everywhere. If you do that with Java, you loose all the benefits of OOP.

    I have based my article on an incomplete definition of immutable and my point was “With that definition of immutable, we cannot say that immutable is thread-safe”. Where I have failed is that I haven’t give a good definition of immutable.
    Anyway, Your comment has helped me t make things clearer, thanks for that!
    I am going to edit my article based on that.

  3. @Jose: Hi, in the case, I’m agree with Tibo, for String class, the hash method, if you use a non-thread safe implementation for the same ‘value’, in a multithreading enviroment you will get different ‘hash codes’, this mean that String class it’s not immutable because his state was changed for the same input parameters(in this case the value of string).

    Thanks

  4. Hi, great article on a very difficult subject.

    I don’t really think that anyone said that “immutability means thread safety”. I think that the point is that an immutable object can be shared between several threads easily. There is no problem, because as the object is immutable, there is no need to “synchronize” anything. In this case, an object is considered immutable as long as its state can not be changed (of course, you pointed clearly the problems when a reference is mutable).

  5. Immutability is a tricky subject and as rightly pointed out in your article, all the fields of a class must be considered carefully before declaring the object immutable. Better still Java could have a construct for enforcing immutability for the whole class instead of individual fields. :-)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>