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

Question

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?

Answer 1

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.