JSR133—Java Memory Model

JSR：https://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html
很早的译文：http://snake1987.iteye.com/blog/983254

What is a memory model, anyway?

• 在处理器的层次，一个存储模型定义必要的并且足够的条件，让当前的处理器可以看到另外的处理器写进一个储存（memory，如一个变量），并且当前的处理器的写进memory能被别的处理器看到。一些处理器展示了一个强壮（Strong）的存储模型，他可以让所有的处理器看到储存在一个memory的正确的相同的值。其他的处理器展示了一个较弱的存储模型，它提供一些特殊的指令，叫做存储屏障，这些指令可以flush或者invalidate这个本地寄存器的高速缓存，以便可以看到别的寄存器的写memory操作和让本寄存器的写memory被别的寄存器看到。当执行lock或者unlock动作的时候，这些存储屏障通常会表现出来，他们在一个高层语言是对编程人员是不可见的
• 有时，用强健（Strong）的存储模型写程序更加容易，因为可以减少存储屏障的试用。然而，即使是一些最强健的存储模型，存储屏障经常也是有必要的：quite frequently their placement is counterintuitive。现代的趋势是，处理器的设计上，较弱的内存模型更被支持，因为他们缓和了高速缓存的一致性问题，允许了更大的吞吐率通过多处理器和大容量内存。

Do other languages, like C++, have a memory model?

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

What is JSR 133 about?

• 自从1997年以来，一些关于jmm的严重的缺陷（像定义在Java Language Specification chapter 17的）已经被发现。这些缺陷允许一些迷惑的举止（像final fields被观察到改变了他们的值）和破坏编译器表现一些通常的优化措施的能力
• Jmm是一个有野心的承诺（ambitious undertaking）。这是第一次一个程序语言定义尝试去包含一个存储模型，这个存储模型可以为穿过一系列结构的并发提供一致的语意。很不幸，定义一个一致的和直觉的（intuitive）存储模型被证明是比想象中还要困难。JSR133为java语言定义了一个新的存储模型，修复了早期存储模型的缺陷。为了做到这点，final和volatile的语义将被改变。

JSR133的目标包括：

• 保留已存在的安全保证，像type-safety，并且强化其他的。举个例子，变量的值不是凭空创造的：线程观察到的每个变量的值必须是某个线程有原因地设置的
• 关于synchronized程序的的正确的语义应该尽可能地简单和intuitive
• 不完整，不正确的synchronized程序的语义应该被定义，这样能够让潜在的安全隐患最小化
• 编程人员对于多线程程序与内存的交互应该要有有原因的信心。（也就是说不能盲目的自信这个代码是正确的）
• 正确地设计高性能的jvm实现，并且能跨越大范围的流行硬件结构是有可能的
• 一个新的保障initialization safety应该被提供。如果一个对象被合适的constructed（这就意味着该对象的引用在构造（construction）期间没有逃逸escape），这样所有看到该对象的引用的线程也能看到他的设置在构造函数中的final域的值，而不需要synchronization。
  A new guarantee of initialization safety should be provided. If an object is properly constructed (which means that references to it do not escape during construction), then all threads which see a reference to that object will also see the values for its final fields that were set in the constructor, without the need for synchronization.
• 要将对已有代码的影响最小化

What is meant by reordering?

• 有很多的例子：访问一个程序变量（object instance fields，class static fields，and array elements）时可能碰到被以不同的顺序执行，而不是被定义在程序中的顺序。编译器是允许以优化的名义来改变指令的顺序的。处理器可能在一个确切的环境中执行改变了顺序的指令。数据可能在寄存器，处理器告诉缓存，和主存之间以不同的顺序移动，而不是定义在程序中的顺序。
• 举个例子，如果一个线程写一个field a，并且然后写一个field b，并且b的值不依赖于a的值，这样编译器是允许去重新排序这些操作的，并且告诉缓存也是允许去flush b的值在a之前到主存上。有一系列潜在的重排序的原因，像编译器，JIT，和高速缓存。
• 编译器，runtime和硬件是提供一个协作去创建一个“似乎是顺序的”的语义的幻想的，这就意味着，在一个单线程的程序，程序应该不能观察到重排序。然而，重排序会出现在不正确的synchronized多线程程序，在那里一个线程是能观察到别的线程的影响的，并且能够检测到变量的访问对其他的线程变得可见，在一个不同的顺序，而不是定义在程序中的顺序。
  大部分的时间，一个线程不关心其他的线程正在做什么。如果需要关心了，那就需要synchronization了

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，首先保证了第二个操作对第一个操作是可见的。这些顺序的规则在以下：

• Each action in a thread happens before every action in that thread that comes later in the program's order.

• An unlock on a monitor happens before every subsequent lock on that same monitor.

• A write to a volatile field happens before every subsequent read of that same volatile.

• A call to start() on a thread happens before any actions in the started thread.

• 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是很重要的。