在 ArrayBlockingQueue 中,为啥要将 final 成员字段复制到本地 final 变量中?
Posted
技术标签:
【中文标题】在 ArrayBlockingQueue 中,为啥要将 final 成员字段复制到本地 final 变量中?【英文标题】:In ArrayBlockingQueue, why copy final member field into local final variable?在 ArrayBlockingQueue 中,为什么要将 final 成员字段复制到本地 final 变量中? 【发布时间】:2011-02-16 16:13:44 【问题描述】:在ArrayBlockingQueue
中,所有需要锁的方法在调用lock()
之前将其复制到本地final
变量中。
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();
当字段this.lock
为final
时,是否有任何理由将this.lock
复制到局部变量lock
?
此外,它还在操作之前使用E[]
的本地副本:
private E extract()
final E[] items = this.items;
E x = items[takeIndex];
items[takeIndex] = null;
takeIndex = inc(takeIndex);
--count;
notFull.signal();
return x;
是否有任何理由将 final 字段复制到本地 final 变量中?
【问题讨论】:
【参考方案1】:This thread 给出了一些答案。实质上:
编译器无法轻易证明最终字段在方法中没有改变(由于反射/序列化等) 大多数当前编译器实际上不会尝试,因此每次使用 final 字段时都必须重新加载它,这可能导致缓存未命中或页面错误 将其存储在局部变量中会强制 JVM 仅执行一次加载【讨论】:
我不认为 JVM 必须重新加载final
变量。如果您通过反射修改 final
变量,您将失去程序正常工作的保证(这意味着新值可能不会在所有情况下都被考虑在内)。【参考方案2】:
这是类的作者Doug Lea喜欢使用的一个极端优化。这是 core-libs-dev 邮件列表上a recent thread 上关于这个确切主题的帖子,它很好地回答了您的问题。
来自帖子:
...复制到当地人会产生最小的 字节码,对于低级代码,编写代码很好 离机器更近一点
【讨论】:
强烈强调“极端”!这不是每个人都应该效仿的通用良好编程实践。 随机仅供参考:在其他一些情况下,当您看到此操作完成时,这是因为所讨论的字段是易变的,并且该方法需要确保它在整个过程中都有一个一致的值或引用。 我将在这样的核心类中进行这种“极端”优化。 @zamza,局部最终变量仅由 java 编译器使用,而不是字节码(即 JVM 不知道局部变量是否为最终变量) 除了字节码大小,这也是对执行速度的优化吗?以上是关于在 ArrayBlockingQueue 中,为啥要将 final 成员字段复制到本地 final 变量中?的主要内容,如果未能解决你的问题,请参考以下文章
LinkedBlockingQueue与ArrayBlockingQueue
ArrayBlockingQueue与LinkedBlockingQueue对比
多个线程同时从ArrayBlockingQueue中取数据冗余