Why does JDK sourcecode take a `final` copy of `volatile` instances

I read the JDK's source code about ConcurrentHashMap.

But the following code confused me:

public boolean isEmpty() {
    final Segment<K,V>[] segments = this.segments;
    ...
}

My question is:

"this.segments" is declared:

final Segment<K,V>[] segments;

So, here, in the beginning of the method, declared a same type reference, point to the same memory.

Why did the author write it like this? Why didn't they use this.segments directly? Is there some reason?

This is an idiom typical for lock-free code involving volatile variables. At the first line you read the volatile once and then work with it. In the meantime another thread can update the volatile, but you are only interested in the value you initially read.

Also, even when the member variable in question is not volatile but final, this idiom has to do with CPU caches as reading from a stack location is more cache-friendly than reading from a random heap location. There is also a higher chance that the local var will end up bound to a CPU register.

For this latter case there is actually some controversy, since the JIT compiler will usually take care of those concerns, but Doug Lea is one of the guys who sticks with it on general principle.

I guess it's for performance consideration, so that we only need retrieve field value once.

You can refer to a singleton idiom from effective java by Joshua Bloch

His singleton is here:

private volatile FieldType field;
FieldType getField() {
  FieldType result = field;
  if (result == null) { 
    synchronized(this) {
      result = field;
      if (result == null) 
        field = result = computeFieldValue();
    }
  }
  return result;
}

and he wrote:

> This code may appear a bit convoluted. In particular, the need for the > local variable result may be unclear. What this variable does is to > ensure that field is read only once in the common case where it’s > already initialized. While not strictly necessary, this may improve > performance and is more elegant by the standards applied to low-level > concurrent programming. On my machine, the method above is about 25 > percent faster than the obvious version without a local variable.

It may reduce byte code size - accessing a local variable is shorter in byte code than accessing an instance variable.

Runtime optimization overhead may be reduced too.

But none of these are significant. It's more about code style. If you feel comfortable with instance variables, by all means. Doug Lea probably feel more comfortable dealing with local variables.