In ArrayBlockingQueue, why copy final member field into local final variable?

Question

In ArrayBlockingQueue, all the methods that require the lock copy it to a local final variable before calling lock().

public boolean offer(E e) {     if (e == null) throw new NullPointerException();     final ReentrantLock lock = this.lock;     lock.lock();     try {         if (count == items.length)             return false;         else {             insert(e);             return true;         }     } finally {         lock.unlock();     } } 

Is there any reason to copy this.lock to a local variable lock when the field this.lock is final?

Additionally, it also uses a local copy of E[] before acting on it:

private E extract() {     final E[] items = this.items;     E x = items[takeIndex];     items[takeIndex] = null;     takeIndex = inc(takeIndex);     --count;     notFull.signal();     return x; } 

Is there any reason for copying a final field to a local final variable?

Answer 1

It's an extreme optimization Doug Lea, the author of the class, likes to use. Here's a post on a recent thread on the core-libs-dev mailing list about this exact subject which answers your question pretty well.

from the post:

...copying to locals produces the smallest bytecode, and for low-level code it's nice to write code that's a little closer to the machine

Answer 2

This thread gives some answers. In substance:

• the compiler can't easily prove that a final field does not change within a method (due to reflection / serialization etc.)
• most current compilers actually don't try and would therefore have to reload the final field everytime it is used which could lead to a cache miss or a page fault
• storing it in a local variable forces the JVM to perform only one load