在 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.lockfinal 时,是否有任何理由将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中取数据冗余

JAVA多线程之ArrayBlockingQueue看Condition的实现

并发队列之ArrayBlockingQueue

源码阅读(32):Java中线程安全的QueueDeque结构——ArrayBlockingQueue