java并发学习之四：JSR 133 (Java Memory Model) FAQ【译】

 

Jsr133地址：http://www.cs.umd.edu/~pugh/java/memoryModel/jsr133.pdf

原文的地址：http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html

JSR 133 (Java Memory Model) FAQ
Jeremy Manson and Brian Goetz, February 2004

1.到底什么是存储模型？

在多处理器系统，处理器通常有一个或者更多层高速缓存（像hibernate的二级缓存），通过提高访问数据的速度（因为数据更靠近处理器）和通过减少共享内存总线的使用（因为很多内存的操作可以通过本地的高速缓存来实现）提高了很大的性能。很多缓存可以极大地提高性能，然而他们面临着一个新的挑战。举个例子：当两个处理器在同一时间检查同一个内存地址时，会发生什么事？在什么条件下我们能看到相同的值？

 

在处理器的层次，一个存储模型定义必要的并且足够的条件，让当前的处理器可以看到另外的处理器写进一个储存（memory，如一个变量），并且当前的处理器的写进memory能被别的处理器看到。一些处理器展示了一个强壮（Strong）的存储模型，他可以让所有的处理器看到储存在一个memory的正确的相同的值。其他的处理器展示了一个较弱的存储模型，它提供一些特殊的指令，叫做存储屏障，这些指令可以flush或者invalidate这个本地寄存器的高速缓存，以便可以看到别的寄存器的写memory操作和让本寄存器的写memory被别的寄存器看到。当执行lock或者unlock动作的时候，这些存储屏障通常会表现出来，他们在一个高层语言是对编程人员是不可见的

有时，用强健（Strong）的存储模型写程序更加容易，因为可以减少存储屏障的试用。然而，即使是一些最强健的存储模型，存储屏障经常也是有必要的：quite frequently their placement is counterintuitive。现代的趋势是，处理器的设计上，较弱的内存模型更被支持，因为他们缓和了高速缓存的一致性问题，允许了更大的吞吐率通过多处理器和大容量内存。

这个事件：一个写操作对其他的线程变得可见，通过编译器的reordering的代码实现是很复杂的。举个例子，编译器可能认为在某个程序里面将一个写操作推迟会更有效率，只要这个代码动作不会影响程序的语义，他是被允许的。如果一个编译器推迟了一个操作，另一个线程将不会看到直到该操作发生。这也反应了缓存的一个后果。

而且，写memory在程序中可以很轻易地被移位。这样一来，在程序中其他的线程可能会看到一个写操作发生在真正的“occurs”之前。所有这些可以被灵活地设计，让编译器，runtime，或者硬件有更大的灵活性去用一个优化的顺序运行操作，在一个内存模型的限制，我们能得到更高的性能

下面的代码是一个简单的例子

Class Reordering {

  int x = 0, y = 0;

  public void writer() {

    x = 1;

    y = 2;

  }

 

  public void reader() {

    int r1 = y;

    int r2 = x;

  }

让我们认为这些代码被两个线程并发地执行，并且y的读操作看到了值2。因为这个写操作发生在x的写操作之后，这些编程人员可以假设这个对x的读一定能看到值1。然而，这些写操作可能会被reordered。如果这发生了，这样一个对y的写操作会发生，然后对两个变量的读操作发生了，然后才对x的写操作发生，结果会是r1=2，r2=0

这java内存模型描述了什么举止是合法的，在多线程的代码中，并且线程怎么通过memory进行交互。他描述了变量在程序之间的关系和一些关于存储和检索的低层次的内容。他通过一种方式实现正确地使用一个多种多样的硬件和一个多种多样的编译优化。

Java包含一些语言的cnstructs，包括volatile，final，和synchronized，他们是试图帮助编程人员去描述一个并发的需求给编译器。这jmm定义volatile和synchronized这些举止，更重要的是，保证了java程序正确的运行在所有的处理器结果能够正确的同步

2.其他的语言，像c++，有没有一个存储模型呢？

大部分其他的程序语言，像c和c++，都不是设计为直接支持多线程的。这些语言提供的保护抵抗（against）一些种类的reorderings：像发生在编译器的和结构的reorder，是严重依赖由threading libraries（像pthreads）的使用提供的保障（没翻译好~），和编译器使用，和平台代码运行

3.什么是JSR133？

自从1997年以来，一些关于jmm的严重的缺陷（像定义在Java Language Specification chapter 17的）已经被发现。这些缺陷允许一些迷惑的举止（像final fields被观察到改变了他们的值）和破坏编译器表现一些通常的优化措施的能力

Jmm是一个有野心的承诺（ambitious undertaking）。这是第一次一个程序语言定义尝试去包含一个存储模型，这个存储模型可以为穿过一系列结构的并发提供一致的语意。很不幸，定义一个一致的和直觉的（intuitive）存储模型被证明是比想象中还要困难。JSR133为java语言定义了一个新的存储模型，修复了早期存储模型的缺陷。为了做到这点，final和volatile的语义将被改变

全部的语义都包含在http://www.cs.umd.edu/users/pugh/java/memoryModel，但是正式的语义不是胆怯的（？the formal semantics are not for the timid），很让人惊讶，很让人冷静，发现一个简单的概念像synchronization是如此的复杂。很幸运的，你不必明白正式语义的内容---JSR133的目的是创造一系列的正式的语义，为volatile，synchronized和final是如何工作的提供一个直觉（intuitive）的框架

 

JSR133的目标包括：

<!--[if !supportLists]-->l  <!--[endif]-->保留已存在的安全保证，像type-safety，并且强化其他的。举个例子，变量的值不是凭空创造的：线程观察到的每个变量的值必须是某个线程有原因地设置的

<!--[if !supportLists]-->l  <!--[endif]-->关于synchronized程序的的正确的语义应该尽可能地简单和intuitive

<!--[if !supportLists]-->l  <!--[endif]-->不完整，不正确的synchronized程序的语义应该被定义，这样能够让潜在的安全隐患最小化

<!--[if !supportLists]-->l  <!--[endif]-->编程人员对于多线程程序与内存的交互应该要有有原因的信心。（也就是说不能盲目的自信这个代码是正确的）

<!--[if !supportLists]-->l  <!--[endif]-->正确地设计高性能的jvm实现，并且能跨越大范围的流行硬件结构是有可能的

<!--[if !supportLists]-->l  <!--[endif]-->一个新的保障initialization safety应该被提供。如果一个对象被合适的constructed（这就意味着该对象的引用在构造（construction）期间没有逃逸escape），这样所有看到该对象的引用的线程也能看到他的设置在构造函数中的final域的值，而不需要synchronization。

<!--[if !supportLists]-->l  <!--[endif]-->要将对已有代码的影响最小化

 

4.Reordering意味着什么？

有很多的例子：访问一个程序变量（object instance fields，class static fields，and array elements）时可能碰到被以不同的顺序执行，而不是被定义在程序中的顺序。编译器是允许以优化的名义来改变指令的顺序的。处理器可能在一个确切的环境中执行改变了顺序的指令。数据可能在寄存器，处理器告诉缓存，和主存之间以不同的顺序移动，而不是定义在程序中的顺序。

举个例子，如果一个线程写一个field a，并且然后写一个field b，并且b的值不依赖于a的值，这样编译器是允许去重新排序这些操作的，并且告诉缓存也是允许去flush b的值在a之前到主存上。有一系列潜在的重排序的原因，像编译器，JIT，和高速缓存。

编译器，runtime和硬件是提供一个协作去创建一个“似乎是顺序的”的语义的幻想的，这就意味着，在一个单线程的程序，程序应该不能观察到重排序。然而，重排序会出现在不正确的synchronized多线程程序，在那里一个线程是能观察到别的线程的影响的，并且能够检测到变量的访问对其他的线程变得可见，在一个不同的顺序，而不是定义在程序中的顺序。

大部分的时间，一个线程不关心其他的线程正在做什么。如果需要关心了，那就需要synchronization了

5.旧的存储模型有什么问题？

旧的存储模型有一些严重的问题。他很难被了解，因此广泛被违反。举个例子，很多的问题上，旧的模型在不会允许其实已经发生在每个jvm上的某些类型的reorderings。对这个旧的存储模型的迷惑导致了JSR133的形成。

一个被广泛认识的概念，举个例子：如果一个变量用final修饰，那么多个线程synchronization这个变量就没必要了。虽然这是一个有理由的概念，也是一个明智的举动，然而事实上我们真正想要这些东西生效，就不是这么一回事了。在旧的存储模型下，他很简单不是正确的。在旧的存储模型针对final fields的处理和其他的field是完全相同的：这就意味着synchronization是保证所有线程看到被构造函数设置的final的值的唯一办法。结果，有可能会出现这样的现象，一个线程看到了一个field的默认值，在之后的时间才看到他在构造时期设置的值。这就意味着，一个不变的的对象像String会显示出他们的值被改变了，这就确实是一件让人郁闷的事情。

旧的存储模型允许volatile的写和非volatile读和写的重排序，这样就不能保证大部分开发者对volatile变量的使用意图的与事实状况的一致性，因此就造成了迷惑。

最后，我们可以看到，编程人员的自以为是正确的意图其实会变得错误了。JSR133的一个目的就是要引起这方面的注意。

6.什么叫不正确的synchronized？

不正确的synchronized代码对于不同的人有不同的含义。当我们谈论到在jmm的内容中不正确的synchronized代码，这些代码有以下特征：

<!--[if !supportLists]-->l  <!--[endif]-->一个线程正在写一个变量

<!--[if !supportLists]-->l  <!--[endif]-->另一个线程在读这个变量

<!--[if !supportLists]-->l  <!--[endif]-->读和写没有orderd by synchronization

当这些条件都符合了，我们说我们在这个变量上有一个数据竞争（data race）。一个存在数据竞争的程序是不正确的synchronized程序（这说法总觉得怪怪的）

 

7.Synchronization做了什么？

Synchronization有很多方面的内容，最被广泛知道的一个是互斥：一次只有一个线程可以持有控制权（monitor），这样，这就意味着一次一个线程进入了一个由一个monitor监控的synchronized块，其他的线程不能进入这个代码块中，知道第一个线程退出

但是除了互斥之外，synchronization还有更多的内容。Synchronization保证了一个线程的发生在同步块之中或者之前的memory写，可以被其他synchronize在同样的monitor的线程看到。在我们退出了一个synchronized块，我们释放monitor，这样会flushing高速缓存到主存，这样，这个线程的写memory对其他线程而言就是可见的。我们能够进入同步块之前，我们需要获得monitor，这个操作会让本地处理器的高速缓存变得无效，这样变量将会从主存中重新加载。我们然后就能够看到之前的释放中的所有的memory写。

讨论到高速缓存相关联的，听起来像这些事件只会影响多处理器的机器。然而，重排序的影响在但处理器机器也很容易被看见。举个例子：编译器移动你的代码在到一个acquire之前或者一个release之后是不可能的。当我们说acquires和releases在高速缓存起作用，我们是使用了一个数字的可能结果的速记法（这段不知道啥意思~~）

新的存储模型语义创造了一个偏序的内存操作（读field，写field，lock，unlock）和其他线程操作（start和join）。在那里我们说一些动作happen-before其他的操作。当一个操作happen-before，首先保证了第二个操作对第一个操作是可见的。这些顺序的规则在以下：

<!--[if !supportLists]-->l  <!--[endif]-->Each action in a thread happens before every action in that thread that comes later in the program's order.

<!--[if !supportLists]-->l  <!--[endif]-->An unlock on a monitor happens before every subsequent lock on that same monitor.

<!--[if !supportLists]-->l  <!--[endif]-->A write to a volatile field happens before every subsequent read of that same volatile.

<!--[if !supportLists]-->l  <!--[endif]-->A call to start() on a thread happens before any actions in the started thread.

<!--[if !supportLists]-->l  <!--[endif]-->All actions in a thread happen before any other thread successfully returns from a join() on that thread.

 

这意味着一个线程的任何存储操作对于任何线程，在他进入一个被同一个monitor保护同步块之后并且在退出同步块之前是可见的，因为所有的存储操作happen before这个release，并且release happen before这个acquire。

另一个暗示是：下面的代码是不可用的

synchronized (new Object()) {}

This is actually a no-op，并且你的编译器可以将他完全一出，因为编译器知道不可能有其他的线程会synchronize在这个monitor。你不得不为一个想要看到另一个线程结果的线程建立一个happens before关系

 

注意：如果需要一个合适的happen-before关系，所有的线程synchronize在同一个monitor是很重要的。

 

8.Final fields是怎么改变他们的值的？

关于final fields值能被看到改变最好的例子是String类

         一个String可以用三个fields实现：一个char array，一个关于array的offset，和一个长度。String的实现原理是这样的：他让多个String和StringBuffer对象共享同一个character array，避免额外的对象分配和复制。这样，举个例子，String.subString()方法可以用创建一个新的String对象，这个String与原始的String共享同样的char array，知识长度和offset fields不同。对于一个String，这些fileds不是全部都是Final Fileds

String s1 = "/usr/tmp";

String s2 = s1.substring(4); 

         String s2将有一个offset=4和length=4。但是，在旧的模型下，有可能发生这样的事：另一个线程看到offset是一个默认值0，在之后，才看到正确的值4，这将让人感觉String s2由“/usr”编程了”/tmp”。

         原始的JMM允许这样的行为。一些JVM已经显示出这样的行为了，新的JMM认为它是非法的。

 

9.Final fields在新的模型下是怎么工作的？

一个对象的final fiels在它的构造器中被设置。假设一个对象被“正确地”构造，一但一个对象构造成功，他的在构造器中分配在final fields的值不需要synchronization也能被其他线程看到。另外，这对任何其他对象或者数组的引用的值，只要它被final修饰，他最少也胡被像final fields一样被更新。（这一点很重要，暂时不知道这样理解是正确的不，英文原文：In addition, the visible values for any other object or array referenced by those final fields will be at least as up-to-date as the final fields.）

         一个对象被合适的构造意味着什么？可以简单地表示为：所有的该对象的引用在构造期间，没有逃逸（escape）。(See Safe Construction Techniques for examples.) 。用另一种说法，不要放置一个正在被构造的对象的引用到任何其他线程可能看到他的地方。也不要分配它到static field，不要作为一个侦听器注册到其他的对象上，等等。这些任务应该在构造器完成之后才去做，而不是在构造器中。

class FinalFieldExample {

  final int x;

  int y;

  static FinalFieldExample f;

  public FinalFieldExample() {

    x = 3;

    y = 4;

  }

  static void writer() {

    f = new FinalFieldExample();

  }

  static void reader() {

    if (f != null) {

      int i = f.x;

      int j = f.y;

    }

  }

}

         上面例子中的类展示了final field是应该怎么使用。一个线程执行reader是确信能看到f.x=3的，因为他是final，没有保证能看到f.y=4，因为他不是final的，如果FinalFieldExample's 的构造器看起来像这样：

public FinalFieldExample() { // bad!

  x = 3;

  y = 4;

  // bad construction - allowing this to escape

  global.obj = this;

}

         然后线程就会通过global.obj读到this，这就不能保证读到f.x=3的

         能够看到正确构造的值是很不错的，但是如果field他自己就是一个引用，而你又想在你的代码中看到它指向的对象（或数组）的最新的值（？）。如果你的fileds是final field，这也是有保证的。这样，你可以有一个final指针，指向一个array而不用担忧其他的线程看到对array的正确的引用，却看到array内容是不正确的值。（？）再一次，这里说的正确，我们意味着对象构造器的结尾的最新的值，不是现有的最新的值

         现在，已经说完这个的全部内容，如果，一个线程构造一个不变的对象之后（这是，一个对象只含有final fields），你像保证他被所有线程看到都是正确的，你仍然代表性得需要使用synchronization。没有其他的办法来保证，举个例子，这对immutable对象的引用将会被第二个线程看到。一个程序从final获得值的保证应该被仔细深入地考虑理解你的代码是怎么concurrency的。

         读完这里有一个疑问：难道在构造函数中创建的对象和对对象的改变也保证了同步吗？这个还需要进一步的尝试

         如果你想要使用JNI来改变final fields的值，这是没有定义的举止的。

 

10.Volatile是怎么做的？

Volatile field是一个用于与其他线程状态通信的特殊的field。每个volatile的读将看到任何线程最新的读这个volatile的写；编程人员用volatile作为一个fileds，当他不能容忍看到由于caching或者reordering造成的就数据时。编译器和runtime被进制分配volatile fields到寄存器。他们必须保证：在他们写之后，他们flush out这个cache到主存，这样他们马上对其他线程变得可见了。同样的，在volatile filed读之前，必须invalidate cache的值，这样，看到的是主存里面的，而不是本地处理高速缓存的。对于volatile还有一些关于reordering的附加的限制

在旧的存储模型下，进入volatile变量不可以被reorder与其他的volatile变量，但是他们可以与其他的非 volatile变量的访问一起被reorder。这就破坏了从一个线程到另一个线程，volatile变量作为一个发信号的条件。

在新的存储模型中，volatile变量仍然是不能与其他的volatile变量被reorder。区别在于，现在不再允许在volatile filed变量附近的normal field访问与volatile field变量这么容易地被reorder。（？是否还存在几率性？特殊状况是？原话是这样的The difference is that it is now no longer so easy to reorder normal field accesses around them.）对volatile field的读与monitor的获得也有相同的memory effect。由于新的存储模型放置了更严格的限制在reorder一个volatile field访问和其他的field访问。

这是一个volatile fields怎么使用的的一个简单的例子：

class VolatileExample {

  int x = 0;

  volatile boolean v = false;

  public void writer() {

    x = 42;

    v = true;

  }

  public void reader() {

    if (v == true) {

      //uses x - guaranteed to see 42.

    }

  }

}

         假设一个线程正在调用writer，另一个在调用reader。对v的写在writer中release这个写到x到memory中，然后这个对v的读从memory获得这个值。因此，如果reader看到v是true，他也保证了他看到发生在它之前的对42的写。如果在旧的存储模型，这将不是正确的。如果v不是volatile，编译器就可以reorder了，然后reader的读就可能看到的是0。

         其实volatile的语义实质上是很有力量的，差不多是一个等级的synchronization。每个对volatile field的读或者写动作像“半个”synchronization，在以可见性为目的上。

 

注意：对线程来说，顺序地访问同一个volatile变量合理地建立happen-before的关系是很重要的。所有的东西在A对volatile field f的写之前，在B读volatile field g之后，是否对B可见，是不能保证的。（废话~）获取和释放必须匹配。

 

11.新的存储模型是否修复了DCL的问题？

（略）是可以修复的。

 

12 .为什么我们要关注它？

并发的bugs是非常难调试的。他们在测试中很难出现，等待直到你的程序运行在高负荷下，并且很难被重现和跟踪。你最好在之前花额外的时间去保证你的程序被合理的同步了。虽然这不容易，但至少他比尝试去调试一个差劲地同步程序容易。