Why it doesn't use the instance field directly, but assigns it to a local variable?

Question

I'm reading the source of java.util.concurrent.ArrayBlockingQueue, and found some code I don't understand:

private final ReentrantLock 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();
    }
}

Notice this line:

final ReentrantLock lock = this.lock;

Why it doesn't use this.lock directly, but assigns it to a local variable?

Answer 1

Could it be for optimization purposes?

Possibly a local variable could more easily be directly allocated to a register with a JIT compiler.

At least in Android, for the first versions of the API, accessing a local variable was cheaper than accessing an instance variable (can't speak for newer versions). It could be that plain Java is the same, and in some cases it makes sense to use a local.

Actually, found a thread confirming this here. Extract:

It's a coding style made popular by Doug Lea. It's an extreme optimization that probably isn't necessary; you can expect the JIT to make the same optimizations. (you can try to check the machine code yourself!) Nevertheless, 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

Since it's just copying the reference and the lock is on the Object instead, and the Object is the same, it shouldn't matter.

The instance variable lock is also declared final, so really, I don't see any point in doing a reference copy.

As JRL pointed out is an optimization, but it's really such a tiny micro-optimization, that I still don't see much point doing it, especially for just one read.

Answer 3

Better safe than sorry?

I guess, when writing fundamental libraries, you'd better go for the safest solution, if it's cheap enough. And this one is extremely cheap.

• Concerning performance, a local variable should be faster than a field access. I guess, any JVM worth its name will do such a trivial optimization(*) itself, but what about interpreted code and possibly C1 (the first, fast and low-quality compiler in Oracle JVM)? It won't make much difference, but the saved microseconds count for millions of users. What about Java running on exotic platforms with a JVM yet to be written...

• The final is not exactly final in reality. The field may get changed using reflection. I can't imagine any reason for doing this and anyone doing such funny things just gets what they deserve. OTOH debugging such problems may take days and fool-proof programming is a good habit when writing such a fundamental stuff.

---

(*) I believe to have read an article by someone reputable claiming the opposite, but I can't find it now.