多线程之 Final变量 详解

原文：

http://www.tuicool.com/articles/2Yjmqy

并发编程网：http://ifeve.com/java-memory-model/

 

总结：

Final 变量在并发当中，原理是经过禁止cpu的指令集重排序（重排序详解http://ifeve.com/java-memory-model-1/ http://ifeve.com/java-memory-model-2/），来提供现成的课件性，来保证对象的安全发布，防止对象引用被其余线程在对象被彻底构造完成前拿到并使用。

 

与前面介绍的锁和volatile相比较，对final域的读和写更像是普通的变量访问。对于final域，编译器和处理器要遵照两个重排序规则：

 

1. 在构造函数内对一个final域的写入，与随后把这个被构造对象的引用赋值给一个引用变量，这两个操做之间不能重排序。
2. 初次读一个包含final域的对象的引用，与随后初次读这个final域，这两个操做之间不能重排序。

 

 

与Volatile 有类似做用，不过Final主要用于不可变变量（基本数据类型和非基本数据类型），进行安全的发布（初始化）。而Volatile能够用于安全的发布不可变变量，也能够提供可变变量的可见性。

 

 

---

 

安全发布的经常使用模式

可变对象必须经过安全的方式来发布，这一般意味着在发布和使用该对象的线程时都必须使用同步。如今，咱们将重点介绍如何确保使用对象的线程可以看到该对象处于已发布的状态，并稍后介绍如何在对象发布后对其可见性进行修改。

安全地发布一个对象，对象的应用以及对象的状态必须同时对其余线程可见。一个正确构造的对象能够经过如下方式来安全地发布：

• 在静态初始化函数中初始化一个对象引用
• 将对象的应用保存到volatile类型的域或者AtomicReferance对象中
• 将对象的引用保存到某个正确构造对象的final类型域中
• 将对象的引用保存到一个由锁保护的域中。

在线程安全容器内部的同步意味着，在将对象放入到某个容器，例如Vector或synchronizedList时，将知足上述最后一条需求。若是线程A将对象X放入一个线程安全的容器，随后线程B读取这个对象，那么能够确保B看到A设置的X状态，即使在这段读/写X的应用程序代码中没有包含显式的同步。尽管Javadoc在这个主题上没有给出很清晰的说明，但线程安全库中的容器类提供了如下的安全发布保证：

• 经过将一个键或者值放入Hashtable、synchronizedMap或者ConcurrentMap中，能够安全地将它发布给任何从这些容器中访问它的线程（不管是直接访问仍是经过迭代器访问）
• 经过将某个元素放入Vector、CopyOnWriteArrayList、CopyOnWriteArraySet、synchronizedList或synchronizedSet中，能够将该元素安全地发布到任何从这些容器中访问该元素的线程
• 经过将某个元素放入BlockingQueue或者ConcurrentLinkedQueue中，能够将该元素安全地发布到任何从这些队列中访问该元素的线程。

类库中的其余数据传递机制（例如Future和Exchanger）一样能实现安全发布，在介绍这些机制时将讨论它们的安全发布功能。

一般，要发布一个静态构造的对象，最简单和最安全的方式是使用静态的初始化器： public static Holder holder = new Holder(42);

静态初始化器由JVM在类的初始化阶段执行。因为在JVM内部存在着同步机制，所以经过这种方式初始化的任何对象均可以被安全地发布[JLS 12.4.2]。

 

---

 

 

详解以下：

1、不变性

知足同步需求的另外一种方法是使用不可变对象（Immutable Object）。到目前为止，咱们介绍了许多与原子性和可见性相关的问题，例如获得失效数据，丢失更新操做或光查到某个对象处于不一致的状态等等，都与多线程视图同时访问同一个可变的状态相关。若是对象的状态不会改变，那么这些问题与复杂性也就天然消失了。

若是某个对象在被建立后其状态就不能被修改，那么这个对象就被成为不可变对象。线程安全型是不可变对象的固有属性之一，他们的不变性条件是由 构造函数建立的，只要他们的状态不改变，那么这些不变性条件就能得以维持。

不可变对象很简单。他们只有一种状态，而且该 状态由构造函数来控制 。在程序设计中一个最困难的地方就是判断复杂对象的可能状态。然而，判断不可变对象的状态却很简单。

虽然在 Java 规范和 Java 内存模型中都没有给出不可变性的正式定义，但不可变性并不等于将对象中全部的域都声明为 final 类型，即便对象中全部的域都是 final 类型的，这个对象也仍然是可变的，由于在 final 类型的域中能够保存对可变对象的引用。

当知足如下条件时，对象才是不可变的：

• 对象建立完以后其状态就不能修改
• 对象的全部与都是 final 类型
• 对象时正确建立的（建立期间没有 this 的逸出）

咱们来分析下面这个类。

@Immutable
public final class ThreeStooges {  private final Set<String> stooges = new HashSet<String>();  public ThreeStooges() {   stooges.add("Moe");   stooges.add("Larry");   stooges.add("Curly");  }  public boolean isStooge(String name) {   return stooges.contains(name);  } }

在不可变对象的内部仍可使用可变对象来管理它们的状态，如 ThreeStooges 所示。尽管保存姓名的Set对象是可变的，但从ThreeStooges的设计中能够看到，在Set对象构造完成后没法对其进行修改。stooges是一个final类型的引用变量，所以全部的对象状态都经过一个final域来访问。最后一个要求是“正确地构造对象”，这个要求很容易知足，由于构造函数能使该引用由除了构造函数及其调用者以外的代码来访问。

因为程序的状态总在不断地变化，你可能会认为须要使用不可变对象的地方很少，但实际状况并不是如此。在“不可变的对象”与“不可变的对象引用”之间存在着差别。保存在不可变对象中的程序状态仍然能够更新，即经过将一个保存新状态的实例来“替换”原有的不可变对象。

Final 域

关键字 final 能够视为 C++ 中 const 机制的一种受限版本，用于构造不可变对象。final 类型的域是不能修改的（但若是 final 域所引用的对象时可变的，那么这些被引用的对象是能够修改的）。然而，在 Java 内存模型中，final 域还有着特殊的语义。final 域能确保初始化过程的安全性，从而能够不受限制的访问不可变对象，并在共享这些对象时无需同步。

注： 我的理解为，final 字段一旦被初始化完成，而且构造器没有把 this 引用传递出去，那么在其余线程中就能看到 final 字段的值（域内变量可见性，和 volatile 相似），并且其外部可见状态永远也不会改变。它所带来的安全性是最简单最纯粹的。

注： 即便对象是可变的，经过将对象的某些域声明为final类型，仍然能够 简化对状态的判断 ，所以限制对象的可变性也就至关于限制了该对象可能的状态集合。仅包含一个或两个可变状态的“基本不可变”对象仍然比包含多个可变状态的对象简单。经过将域声明为final类型，也至关于告诉维护人员这些域是不会变化的。

正如“除非须要更高的可见性，不然应将全部的饿域都声明为私有域”[EJ Item 12]是一个良好的变成习惯，“除非须要某个域是可变的，不然应将其声明为final域”也是一个良好的变成习惯。

示例：使用 Volatile 类型来发布不可变对象

以前咱们讲过， volatile 能够用来保证域的可见性而不能保证变量操做的原子性，更为准确的讲，只能保证读写操做具备原子性，而不能保证自增 i++ 等运算操做的原子性。

在前面的UnsafeCachingFactorizer类中，咱们尝试用两个AtomicReferences变量来保存最新的数值及其因数分解结果，但这种方式并不是是线程安全的，由于咱们没法以原子方式来同时读取或更新这两个相关的值。一样，用volatile类型的变量来保存这些值也不是线程安全的。然而，在某些状况下，不可变对象能提供一种弱形式的原子性。

因式分解Servlet将执行两个原子操做：更新缓存的结果，以及经过判断缓存中的数值是否等于请求的数值来决定是否直接读取缓存中的因数分解结果。每当须要对一组相关数据以原子方式执行某个操做时，就能够考虑建立一个不可变的类来包含这些数据，例如 OneValueCache。

@Immutable
class OneValueCache {  private final BigInteger lastNumber;  private final BigInteger[] lastFactors;  /**  * 若是在构造函数中没有使用 Arrays.copyOf()方法，那么域内不可变对象 lastFactors却能被域外代码改变  * 那么 OneValueCache 就不是不可变的。  */  public OneValueCache(BigInteger i,       BigInteger[] factors) {   lastNumber = i;   lastFactors = Arrays.copyOf(factors, factors.length);  }  public BigInteger[] getFactors(BigInteger i) {   if (lastNumber == null || !lastNumber.equals(i))    return null;   else    return Arrays.copyOf(lastFactors, lastFactors.length);  } }

        对于在访问和更新多个相关变量时出现的竞争条件问题，能够经过将这些变量所有保存在一个不可变对象中来消除。若是是一个可变的对象，那么就必须使用锁来确保原子性。若是是一个不可变对象，那么当线程得到了对该对象的引用后，就  没必要担忧另外一个线程会修改对象的状态

。若是要更新这些变量，那么能够建立一个新的容器对象，但其余使用原有对象的线程仍然会看到对象处于一致的状态。

在 VolatileCachedFactorizer使用了OneValueCache来保存缓存的数值及其因数。咱们将 OneValueCache 声明为 volatile，这样当一个线程将cache设置为引用一个新的OneValueCache时，其余线程就会当即看到新缓存的数据。

@ThreadSafe
public class VolatileCachedFactorizer implements Servlet {  private volatile OneValueCache cache =   new OneValueCache(null, null);  public void service(ServletRequest req, ServletResponse resp) {   BigInteger i = extractFromRequest(req);   BigInteger[] factors = cache.getFactors(i);   if (factors == null) {    factors = factor(i);    cache = new OneValueCache(i, factors);//声明为 volatile ，防止指令重排序，保证可见性   }   encodeIntoResponse(resp, factors);  } }

与cache相关的操做不会相互干扰，由于OneValueCache是不可变的，而且在每条相应的代码路径中只会访问它一次。经过使用包含多个状态变量的容器对象来维持不变性条件，并使用一个volatile类型的引用来确保可见性，使得Volatile Cached Factorizer在没有显式地使用锁的状况下仍然是线程安全的。

2、安全发布

到目前为止，咱们重点讨论的是如何确保对象不被发布，例如让对象封闭在线程或另外一个对象的内部。固然，在某些状况下咱们但愿在多个线程间共享对象，此时必须确保安全地进行共享。然而，若是只是像下面程序那样将对象引用保存到公有域中，那么还不足以安全地发布这个对象。

//不安全的发布
public Holder holder; public void initialize() { holder = new Holder(42); }

你可能会奇怪，这个看似没有问题的示例何以会运行失败。因为存在可见性问题，其余线程看到的Holder对象将处于不一致的状态，即使在该对象的构造函数中已经正确地构建了不变性条件。这种不正确的发布致使其余线程看到还没有建立完成的对象。

不正确的发布：正确的对象被破坏

你不能期望一个还没有被彻底建立的对象拥有完整性。某个观察该对象的线程将看到对象处于不一致的状态，而后看到对象的状态忽然发生变化，即便线程在对象发布后尚未修改过它。事实上，若是下面程序中的Holder使用前面程序中的不安全发布方式，那么另外一个线程在调用assertSanity时将抛出AssertionError。

public class Holder {  private int n;  public Holder(int n) { this.n = n; }  public void assertSanity() {   if (n != n)    throw new AssertionError("This statement is false.");  } }

因为没有使用同步来确保Holder对象对其余线程可见，所以将Holder称为“未被正确发布”。在未被正确发布的对象中存在两个问题。

首先 ，除了发布对象的线程外，其余线程能够看到的 Holder域是一个失效值 ，所以将看到一个空引用或者以前的旧值。

 然而 ，更糟糕的状况是，线程看到Holder引用的值是最新的，但Holder状态的值倒是失效的。状况变得更加不可预测的是，某个线程在第一次读取域时获得失效值，而再次读取这个域时会获得一个更新值，这也是assertSainty抛出AssertionError的缘由。

若是没有足够的同步，那么当在多个线程间共享数据时将发生一些很是奇怪的事情。

不可变对象与初始化安全性

因为不可变对象是一种很是重要的对象，所以 Java内存模型为不可变对象的共享提供了一种特殊的初始化安全性保证 。咱们已经知道，即便某个对象的引用对其余线程是可见的，也并不意味着对象状态对于使用该对象的线程来讲必定是可见的。为了确保对象状态能呈现出一致的视图，就必须使用同步。

另外一方面，即便在发布不可变对象的引用时没有使用同步，也仍然能够安全地访问该对象。为了维持这种初始化安全性的保证，必须知足不可变性的全部需求：状态不可修改，全部域都是final类型，以及正确的构造过程。（ 若是Holder对象是不可变的，那么即便Holder没有被正确地发布，在assertSanity中也不会抛出AssertionError。）

任何线程均可以在不须要额外同步的状况下安全地访问不可改变对象，即便在发布这些对象时没有使用同步。

这种保证还将延伸到被正确建立对象中全部final类型的域。在没有额外同步的状况下，也能够安全地访问final类型的域。然而，若是final类型的域所指向的是可变对象，那么在访问这些域所指向的对象的状态时仍然须要同步。

安全发布的经常使用模式

可变对象必须经过安全的方式来发布，这一般意味着在发布和使用该对象的线程时都必须使用同步。如今，咱们将重点介绍如何确保使用对象的线程可以看到该对象处于已发布的状态，并稍后介绍如何在对象发布后对其可见性进行修改。

安全地发布一个对象，对象的应用以及对象的状态必须同时对其余线程可见。一个正确构造的对象能够经过如下方式来安全地发布：

• 在静态初始化函数中初始化一个对象引用
• 将对象的应用保存到volatile类型的域或者AtomicReferance对象中
• 将对象的引用保存到某个正确构造对象的final类型域中
• 将对象的引用保存到一个由锁保护的域中。

在线程安全容器内部的同步意味着，在将对象放入到某个容器，例如Vector或synchronizedList时，将知足上述最后一条需求。若是线程A将对象X放入一个线程安全的容器，随后线程B读取这个对象，那么能够确保B看到A设置的X状态，即使在这段读/写X的应用程序代码中没有包含显式的同步。尽管Javadoc在这个主题上没有给出很清晰的说明，但线程安全库中的容器类提供了如下的安全发布保证：

• 经过将一个键或者值放入Hashtable、synchronizedMap或者ConcurrentMap中，能够安全地将它发布给任何从这些容器中访问它的线程（不管是直接访问仍是经过迭代器访问）
• 经过将某个元素放入Vector、CopyOnWriteArrayList、CopyOnWriteArraySet、synchronizedList或synchronizedSet中，能够将该元素安全地发布到任何从这些容器中访问该元素的线程
• 经过将某个元素放入BlockingQueue或者ConcurrentLinkedQueue中，能够将该元素安全地发布到任何从这些队列中访问该元素的线程。

类库中的其余数据传递机制（例如Future和Exchanger）一样能实现安全发布，在介绍这些机制时将讨论它们的安全发布功能。

一般，要发布一个静态构造的对象，最简单和最安全的方式是使用静态的初始化器： public static Holder holder = new Holder(42);

静态初始化器由JVM在类的初始化阶段执行。因为在JVM内部存在着同步机制，所以经过这种方式初始化的任何对象均可以被安全地发布[JLS 12.4.2]。

事实不可变对象

若是对象在发布后不会被修改，那么对于其余在没有额外同步的状况下安全地访问这些对象的线程来讲，安全发布是足够的。全部的安全发布机制都能确保，当对象的引用对全部访问该对象的线程可见时，对象发布时的状态对于全部线程也将是可见的，而且若是对象状态不会再改变，那么就足以确保任何访问都是安全的。

若是对象从技术上来看是可变的，但其状态在发布后不会再改变，那么把这种对象称为“ 事实不可变对象 （Effectively Immutable Object）”。这些对象不须要知足以前提出的不可变性的严格定义。在这些对象发布后，程序只需将它们视为不可变对象便可。经过使用事实不可变对象，不只能够简化开发过程，并且还能因为减小了同步而提升性能。

在没有额外的同步的状况下，任何线程均可以安全地使用被安全发布的事实不可变对象。

例如，Date自己是可变的，但若是将它做为不可变对象来使用，那么在多个线程之间共享Date对象时，就能够省去对锁的使用。假设须要维护一个Map对象，其中保存了每位用户的最近登陆时间： public Map<String, Date> lastLogin =Collections.synchronizedMap(new HashMap<String, Date>());

若是Date对象的值在被放入Map后就不会改变，那么synchronizedMap中的同步机制就足以使Date值被安全地发布，而且在访问这些Date值时不须要额外的同步。

可变对象

若是对象在构造后能够修改，那么安全发布只能确保“发布当时”状态的可见性。对于可变对象，不只在发布对象时须要使用同步，并且在每次对象访问时一样须要使用同步来确保后续修改操做的可见性。要安全地共享可变对象，这些对象就必须被安全地发布，而且必须是线程安全的或者由某个锁保护起来。

对象的发布需求取决于它的可变性：

• 不可变对象能够经过任意机制来发布
• 事实不可改变必须经过安全方式发布
• 可变对象必须经过安全方式发布，而且必须是线程安全的或者由某个锁保护起来

安全的共享对象

当得到对象的一个引用时，你须要知道在这个引用上能够执行哪些操做。在使用它以前是否须要得到一个锁？是否能够修改它的状态，或者只能读取它？许多并发错误都是因为没有理解共享对象的这些“既定规则”而致使的。当发布一个对象时，必须明确地说明对象的访问方式。