In ArrayBlockingQueue
, all the methods that require the lock copy it to a local final
variable before calling lock()
.
在ArrayBlockingQueue中,所有需要锁的方法都在调用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:
此外,它还使用E[]的本地副本进行操作:
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?
是否有任何理由将最终字段复制到本地最终变量?
2 个解决方案
#1
52
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.
这个类的作者Doug Lea喜欢使用这种极端的优化。这是最近在核心-libs-dev邮件列表中发布的一篇关于这个主题的帖子,它很好地回答了你的问题。
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
…复制到本地代码可以生成最小的字节码,对于低级代码来说,编写更接近机器的代码是很好的
#2
9
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
- 将其存储在本地变量中会迫使JVM只执行一个负载
#1
52
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.
这个类的作者Doug Lea喜欢使用这种极端的优化。这是最近在核心-libs-dev邮件列表中发布的一篇关于这个主题的帖子,它很好地回答了你的问题。
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
…复制到本地代码可以生成最小的字节码,对于低级代码来说,编写更接近机器的代码是很好的
#2
9
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
- 将其存储在本地变量中会迫使JVM只执行一个负载