在 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 变量中？

【问题讨论】：

标签： java multithreading optimization final local-variables

【解决方案1】：

This thread 给出了一些答案。实质上：

编译器无法轻易证明最终字段在方法中没有改变（由于反射/序列化等）
大多数当前编译器实际上不会尝试，因此每次使用 final 字段时都必须重新加载它，这可能导致缓存未命中或页面错误
将其存储在局部变量中会强制 JVM 仅执行一次加载

【讨论】：

我不认为 JVM 必须重新加载 final 变量。如果您通过反射修改 final 变量，您将失去程序正常工作的保证（这意味着新值可能不会在所有情况下都被考虑在内）。

【解决方案2】：

这是类的作者Doug Lea喜欢使用的一个极端优化。这是 core-libs-dev 邮件列表上a recent thread 上关于这个确切主题的帖子，它很好地回答了您的问题。

来自帖子：

...复制到当地人会产生最小的字节码，对于低级代码，编写代码很好离机器更近一点

【讨论】：

强烈强调“极端”！这不是每个人都应该效仿的通用良好编程实践。
随机仅供参考：在其他一些情况下，当您看到此操作完成时，这是因为所讨论的字段是易变的，并且该方法需要确保它在整个过程中都有一个一致的值或引用。
我将在这样的核心类中进行这种“极端”优化。
@zamza，局部最终变量仅由 java 编译器使用，而不是字节码（即 JVM 不知道局部变量是否为最终变量）
除了字节码大小，这也是对执行速度的优化吗？