zz Java并行(1):JMM
zz Java并行(1):JMM

1.什么是JMM？

    JMM即Java Memory Model，设想有这样一条赋值语句：int a = 1;而a为诸多线程所共享， JMM所关注的问题就是：“读取a的线程在何时会看到值为1的这个写入？”

2. 为什么关注JMM？

    在多数情况下，即使是并发程序的程序员，也并不特别关心JMM，因为Java语言与JVM用更高抽象的“同步”语义隐藏了JMM的语义，使得程序员即便对JMM一无所知，也可以写出优雅的并发程序。许多介绍Java同步机制的资料也并不对JMM做过多的介绍。那么你可能会问，“那一上来就讨论JMM有毛用啊？”相信我，是有毛用的。虽然我对Java并不是十分精通，Java下的并发编程更是新上手的菜鸟，但近一段时间的学习经验告诉我，所谓同步，无非关注于两点，一是互斥性，二是可见性。结合自己过去的认识，对并发的理解过多侧重于“互斥性”，而对“可见性”一知半解，影响了对同步更精细的理解。JMM则对此有十分清晰的阐述。

3.JMM从何而来？

    这就要从盘古开天辟地开始说起了……话说冯诺依曼童鞋当年提出经典的体系结构时，打死他想不到现代的计算机体系结构会发展到这个鸟样子。冯诺依曼模型是一个顺序化的计算模型，可见性不是什么问题，而今天的多处理器架构已经很少再使用顺序一致化模型，而且处理器和编译器的一些优化都会对内存的可见性产生影响：

a. 处理器乱序执行

b. 存储在处理器本地的缓存，对其他处理器不可见

c. 作为优化，编译器可能把变量存在寄存器而非内存

d. 聪明的编译器可能改变生成指令的顺序

    更棘手的是，江湖之大，各门各派对这些行为并没有达成统一的共识，不同架构的处理器提供了不同级别的cache coherence，而所谓一种架构的Memroy Model，即是说在该架构中，Memory的行为对应用程序做出怎样的担保。而不同架构中memory barrier这样特殊的指令，正是为了获得memory协调性而引入的。而JMM则隐藏了这些不同架构MM的差异性，千秋万载一统江湖斯密达。

4. Happens-before关系

    在介绍JMM之前，我们先来了解一些比较重要的概念：

a. 如果我们把程序看成一个“动作”的集合U，在一个程序的一次执行中，所有这些动作都会在时间上（注意是时间上）有一个次序关系，我们记做“tb”(time-before)关系，显然tb是一个“全序关系”（反对称，传递，并且任意两个动作可比）

b. 在这个“动作”集合中，有一些动作被称作“同步动作”，包括上锁/解锁，读写volitile变量，线程开始/结束等。在这个同步动作子集S上，有一个全序“sw”（synchronize-with）关系。详细的SW定义：

    对同一个锁，有上锁动作A，解锁动作B，如果B tb A， 则B sw A
    对同一个volatile变量，有写动作A，读动作B，如果B tb A，则B sw A
    对于一个线程，start动作记做A，B为任一该线程中的动作，则A sw B
    对于一个线程，检测到线程终结的动作记做A（包括join返回，isAlive返回false等），B为任一该线程中的动作，则B sw A
    线程t1调用线程t2的interrupt动作记做A，t2检测到中断（抛出InterruptedException，或者检测到interrupt状态更改）记做B，则 A sw B
    对一个变量默认值赋值（0，false，null）动作记做A，对它的任意操作记做B，则A sw B
    一个对象的构造函数结束动作记做A，该对象的finalizer开始记做B，则A sw B

SW一致性含义：在全序SW中，任一个读操作读到的值是在它之前最后一个写操作写入的值。



c. 在动作集合U上，有一个偏序（自反，反对称，传递，但不是任意两个元素可比）“hb”(happens-before)关系，而他和sw关系有着千丝万缕的关系：那就是如果把sw关系从S集合拿到他的超集U中，求传递闭包，再加上“intra thread原则”——单一线程中，如果动作B在程序中出现在动作A之后，那么A hb B（这很好理解，相当于顺序模型运用在了每个线程内部）。

即有：  HB = t(SW) + IntraThread.

    OK，现在我们已经对HB关系做出了定义。之所以要把它用离散数学的语言写出来，不单单是为了装逼，而是我深感在一些概念性的解释中，数学语言的描述是最简洁、歧义最小、最易于理解的。

HB一致性的含义：对于一个变量，有读操作R，写操作W，如果不存在R hb W，并且也不存在另一个写操作W’，使得W hb W‘，并且W’ hb R，那么，W所写的值对于R来说，是“可能”看见的。（这好像法律条文——凡是没有禁止的，都是可能做的）



注意1：这里需要提出的一点是，HB关系和TB关系是没有必然联系的，也就是，如果A hb B， A不一定tb B， 反过来也一样， 如果A tb B， 不一定就有 A hb B， 这是通常容易混淆的。

注意2：从我们的定义中就可以发现，tb、sw的某些规则（前两条）、hb的某些规则（从sw演化而来的）都是依赖于某次特定的执行（execution）的，在这些情景下，脱离了这个前提，单纯的提A hb B还是C sw D都是没有意义的。



5. JMM现身

    做了这么多铺垫，主角到现在还没有出现，作为导演鸭梨很大。前面已经介绍了HB关系模型，您可能认为这就是JMM了，其实是有微小差别的——JMM是一种更严格的HB模型。严格在哪里呢？JSR133中有一大段形式化描述，看得犯晕，即使我个人再喜欢装逼也万难再描述一遍，我用我的理解来做出简单的解释，请大牛们检查。我们看一个例子：

初始条件：x = y = 0
div css xhtml xml Example Source Code Example Source Code [http://www.cnblogs.com/tomsheep/]

Thread 1:
a = x; //A
if(a == 1)  //B
  y = 1;  //C

Thread 2:
b = y;  //D
if(b == 1)  //E
  x = 1; //F

看上去有点paradox的意思，你可能认为最终a = 0， b = 0是唯一的结果。但是，在HB模型中，不是这样的。让我们来看上面这个例子：我们没有对两个线程做任何同步，对于a，b，x，y的读写都是可能存在data race的。

插播一条data race的定义：对同一变量的两个操作A、B，如果至少有一个写操作，并且A、B不存在HB关系，则我们说两操作存在data race。

    这里，我们把六个操作分别编号（其实6个操作可以再细分为很多个小操作，但这里不需要），我们从HB的定义中可知，同一线程中，A hb B，B hb C，D hb E， E hb F，但是，这个例子中，F和A并没有HB关系，根据HB一致性原则，那么A可以读到F的写入；同理，D可以读到C的写入——这是违背直觉的，但我们并没有违反HB的法律。所以在HB模型中，这是被允许的。

    在JMM中，上述情景是被禁止的。而JMM是通过什么新的条文做到这一点的？我的理解是，只用了下面一条规则：

JMM附加规则：如果某一动作的发生与否不取决于任何data race的发生与否，那么，这个动作是可以被early committed的。

    带着这条规则，我们再来看上述例子，显然，这样一来，F不能在A之前commit，因为他依赖于对y读写data race的发生