assign instance field to local variable

Question

This is keySet() method on HashMap class from JDK. Why did the author assign the field keySet to local variable ks?

public Set<K> keySet() {
    Set<K> ks;
    return (ks = keySet) == null ? (keySet = new KeySet()) : ks;
}

What is the difference between the above and the below? Does this have something to do with thread-safety?

public Set<K> keySet() {
    return (keySet == null ? (keySet = new KeySet()) : keySet;
}

Answer 1

If you look at the keySet declaration in the abstract class AbstractMap<K,V>, you will see that it is defined as:

transient volatile Set<K>  keySet;

Since it is volatile, reading it just once by using the local variable assignment is cheaper than reading it twice as would be in the other example you provided.

Furthermore, if you were to return the keySet variable directly, then all the client code would be dealing with a volatile reference vs. a non-volatile reference (i.e. the Set<K> ks)

Answer 2

To expand slightly on Michael's answer, I expect it is there to ensure that the keySet() method never returns null, possibly in addition to providing performance benefits noted.

Given this code:

public Set<K> keySet() {
    return (keySet == null ? (keySet = new KeySet()) : keySet;
}

It would be at least theoretically possible in multi-threaded code that the keySet field could be set to null between the first read (keySet == null) and the second read, where it is returned. I haven't looked at the rest of the code, but I assume there are other places where keySet is potentially assigned null. Whether this is as a result of an issue seen in the wild, or a defensive measure would be a question for the authors.

The actual code:

public Set<K> keySet() {
    Set<K> ks;
    return (ks = keySet) == null ? (keySet = new KeySet()) : ks;
}

...doesn't have this problem as the field is only read once.