Concurrency-interest邮件列表中有人问了这么一个问题：ArrayBlockingQueue中有个对象字段lock，在ArrayBlockingQueue的很多方法中，使用这个lock时都将其先赋值给一个局部变量，然后再通过局部变量调用lock上的方法，而没有直接使用lock字段，如remainingCapacity方法中先将this.lock赋值给一个局部变量lock，然后再使用这个局部变量：
public class ArrayBlockingQueue {
private final ReentrantLock lock; //...other fields and methods
public int remainingCapacity() {
final ReentrantLock lock = this.lock;
lock.lock();
try {
return items.length - count;
}
finally {
lock.unlock();
}
}}
而不是像这样直接使用类中的字段：
public class ArrayBlockingQueue {
private final ReentrantLock lock; //...other fields and methods
public int remainingCapacity() {
this.lock.lock();
try {
return items.length - count;
}
finally {
this.lock.unlock();
}
}}
那么为什么要这么做，有什么理由或说法？
Doug Lea给出了回复，大意如下：
归根究底是由于内存模型与OOP之间的原则不一致。
几乎j.u.c包中的每个方法都采用了这样一种策略：当一个值会被多次使用时，就将这个字段读出来赋值给局部变量。虽然这种做法不雅观，但检查起来会更直观。
final字段也会做这样处理，可能有些令人不解。这是因为JVM并不足够智能，不能充分利用JMM已经提供了安全保证的可优化点，比如可以不用重新加载final值到缓存。相比过去，JVM在这方面有很大进步，但仍不够智能。
原文如下：
It’s ultimately due to the fundamental mismatch between memory modelsand OOP [图片上传中。。。（1）]
Just about every method in all of j.u.c adopts the policy of reading fields as locals whenever a value is used more than once.This way you are sure which value applies when.This is not often pretty, but is easier to visually verify.
The surprising case is doing this even for “final” fields.This is because JVMs are not always smart enough to exploit the fine points of the JMM and not reload read final values, as they would otherwise need to do across the volatile accesses entailed in locking. Some JVMs are smarter than they used to be about this, but still not always smart enough.
