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
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的发生，y又依赖x，绕回来了，总之，如果不发生竞争写入，则F不可能发生。如此一来，上述情景被禁止了。为了更好理解，我们再来看一个例子：
初始条件：x = y = 0
Example Source Code
[http://www.cnblogs.com/tomsheep/]
Thread 1: a = x; //A y = 1; //B Thread 2: b = y; //C x = 1; //D
看上去跟刚才那个例子差不多，但如果我告诉你在这个例子中，a = 1， b =1 就是可以被JMM接受的，你会不会感到惊讶？让我们再来检查我们的规则：同样，D和A没有HB关系，B和C没有HB关系，而且，对于附加规则，B、D动作 的发生不依赖与任何data race， 即是说，有没有data race，我都可以发生，那么，所有限制性规则再次全军覆没，a = 1， b = 1 可以接受。
最后一个例子：
初始条件：x = y = 0
Example Source Code
[http://www.cnblogs.com/tomsheep/]
Thread 1: a = x; //A b = a | 1; //B y = b; //C Thread 2: c = y; //D x = c; //E
这个例子就没有刚才那么直观了，现在的问题是a = b = c = 1是JMM可以接受的结果吗？直觉上说，你可能脱口而出，不可能，因为违反了附加规则：操作B依赖于x的data race，x依赖y……B不能提前commit。你很聪明，但是，遗憾的是，编译器比你还聪明。我们看，在B执行的时候，a的取值可能有哪些？没错，无非 是0或者1，那么，作为一个比你还聪明的编译器，看出“B操作的本质无非是b = 1，这个操作不依赖于data race发生与否”这一事实，应该是情理之中吧。那么它就会做出优化，把上述代码变为：
Example Source Code
[http://www.cnblogs.com/tomsheep/]
Thread 1: a = x; //A b = 1; //B y = 1; //C Thread 2: c = y; //D x = c; //E
现在，你还说他违反附加原则吗？因此这个情景是被JMM接受的。
上述是我对JMM一点皮毛的理解，主要参考资料：
1. JSR133
2. Addison Wesley, Java Concurrency in Practice ,Brian Goetz
3. 各路网文
Java Memory Model(JMM)
内存模型 (memory model)内存模型描述的是程序中各变量（实例域、静态域和数组元素）之间的关系，以及在实际计算机系统中将变量存储到内存和从内存取出变量这样的低层细节.
不同平台间的处理器架构将直接影响内存模型的结构.
在C或C++中, 可以利用不同操作平台下的内存模型来编写并发程序. 但是, 这带给开发人员的是, 更高的学习成本.
相比之下, java利用了自身虚拟机的优势, 使内存模型不束缚于具体的处理器架构, 真正实现了跨平台.
(针对hotspot jvm, jrockit等不同的jvm, 内存模型也会不相同)
内存模型的特征:
a, Visibility 可视性 (多核,多线程间数据的共享)
b, Ordering 有序性 (对内存进行的操作应该是有序的)
Java 内存模型 (java memory model)
根据Java Language Specification中的说明, jvm系统中存在一个主内存(Main Memory或Java Heap Memory)，Java中所有变量都储存在主存中，对于所有线程都是共享的。
每条线程都有自己的工作内存(Working Memory)，工作内存中保存的是主存中某些变量的拷贝，线程对所有变量的操作都是在工作内存中进行，线程之间无法相互直接访问，变量传递均需要通过主存完成。
其中, 工作内存里的变量, 在多核处理器下, 将大部分储存于处理器高速缓存中, 高速缓存在不经过内存时, 也是不可见的.
jmm怎么体现 可视性(Visibility) ?
在jmm中, 通过并发线程修改变量值, 必须将线程变量同步回主存后, 其他线程才能访问到.
jmm怎么体现 有序性(Ordering) ?
通过java提供的同步机制或volatile关键字, 来保证内存的访问顺序.
缓存一致性（cache coherency）
什么是缓存一致性?
它是一种管理多处理器系统的高速缓存区结构，其可以保证数据在高速缓存区到内存的传输中不会丢失或重复。(来自wikipedia)
举例理解:
假如有一个处理器有一个更新了的变量值位于其缓存中，但还没有被写入主内存，这样别的处理器就可能会看不到这个更新的值.
解决缓存一致性的方法?
a, 顺序一致性模型:
要求某处理器对所改变的变量值立即进行传播, 并确保该值被所有处理器接受后, 才能继续执行其他指令.
b, 释放一致性模型: (类似jmm cache coherency)
允许处理器将改变的变量值延迟到释放锁时才进行传播.
jmm缓存一致性模型 - "happens-before ordering(先行发生排序)"
一般情况下的示例程序:
x = 0;
y = 0;
i = 0;
j = 0;
// thread A
y = 1;
x = 1;
// thread B
i = x;
j = y;
在如上程序中, 如果线程A,B在无保障情况下运行, 那么i,j各会是什么值呢?
答案是, 不确定. (00,01,10,11都有可能出现)
这里没有使用java同步机制, 所以 jmm 有序性和可视性 都无法得到保障.
happens-before ordering(先行发生排序)如何避免这种情况?
排序原则已经做到:
a, 在程序顺序中, 线程中的每一个操作, 发生在当前操作后面将要出现的每一个操作之前.
b, 对象监视器的解锁发生在等待获取对象锁的线程之前.
c, 对volitile关键字修饰的变量写入操作, 发生在对该变量的读取之前.
d, 对一个线程的 Thread.start() 调用 发生在启动的线程中的所有操作之前.
e, 线程中的所有操作 发生在从这个线程的 Thread.join()成功返回的所有其他线程之前.
为了实现happends-before ordering原则, java及jdk提供的工具:
a, synchronized关键字
b, volatile关键字
c, final变量
d, java.util.concurrent.locks包(since jdk 1.5)
e, java.util.concurrent.atmoic包(since jdk 1.5)
...
使用了happens-before ordering的例子:
(1) 获取对象监视器的锁(lock)
(2) 清空工作内存数据, 从主存复制变量到当前工作内存, 即同步数据 (read and load)
(3) 执行代码，改变共享变量值 (use and assign)
(4) 将工作内存数据刷回主存 (store and write)
(5) 释放对象监视器的锁 (unlock)
注意: 其中4,5两步是同时进行的.
这边最核心的就是第二步, 他同步了主内存,即前一个线程对变量改动的结果,可以被当前线程获知!(利用了happens-before ordering原则)
对比之前的例子
如果多个线程同时执行一段未经锁保护的代码段，很有可能某条线程已经改动了变量的值，但是其他线程却无法看到这个改动，依然在旧的变量值上进行运算，最终导致不可预料的运算结果。
内存模型描述的是程序中各变量（实例域、静态域和数组元素）之间的关系，以及在实际计算机系统中将变量存储到内存和从内存取出变量这样的低层细节.
不同平台间的处理器架构将直接影响内存模型的结构.
在C或C++中, 可以利用不同操作平台下的内存模型来编写并发程序. 但是, 这带给开发人员的是, 更高的学习成本.
相比之下, java利用了自身虚拟机的优势, 使内存模型不束缚于具体的处理器架构, 真正实现了跨平台.
(针对hotspot jvm, jrockit等不同的jvm, 内存模型也会不相同)
内存模型的特征:
a, Visibility 可视性 (多核,多线程间数据的共享)
b, Ordering 有序性 (对内存进行的操作应该是有序的)
java 内存模型 ( java memory model )
根据Java Language Specification中的说明, jvm系统中存在一个主内存(Main Memory或Java Heap Memory)，Java中所有变量都储存在主存中，对于所有线程都是共享的。
每条线程都有自己的工作内存(Working Memory)，工作内存中保存的是主存中某些变量的拷贝，线程对所有变量的操作都是在工作内存中进行，线程之间无法相互直接访问，变量传递均需要通过主存完成。
其中, 工作内存里的变量, 在多核处理器下, 将大部分储存于处理器高速缓存中, 高速缓存在不经过内存时, 也是不可见的.
jmm怎么体现 可视性(Visibility) ?
在jmm中, 通过并发线程修改变量值, 必须将线程变量同步回主存后, 其他线程才能访问到.
jmm怎么体现 有序性(Ordering) ?
通过java提供的同步机制或volatile关键字, 来保证内存的访问顺序.
缓存一致性（cache coherency）
什么是缓存一致性?
它是一种管理多处理器系统的高速缓存区结构，其可以保证数据在高速缓存区到内存的传输中不会丢失或重复。(来自wikipedia)
举例理解:
假如有一个处理器有一个更新了的变量值位于其缓存中，但还没有被写入主内存，这样别的处理器就可能会看不到这个更新的值.
解决缓存一致性的方法?
a, 顺序一致性模型:
要求某处理器对所改变的变量值立即进行传播, 并确保该值被所有处理器接受后, 才能继续执行其他指令.
b, 释放一致性模型: (类似jmm cache coherency)
允许处理器将改变的变量值延迟到释放锁时才进行传播.
jmm缓存一致性模型 – “happens-before ordering(先行发生排序)”
一般情况下的示例程序:
x = 0;
y = 0;
i = 0;
j = 0;
// thread A
y = 1;
x = 1;
// thread B
i = x;
j = y;
在如上程序中, 如果线程A,B在无保障情况下运行, 那么i,j各会是什么值呢?
答案是, 不确定. (00,01,10,11都有可能出现)
这里没有使用java同步机制, 所以 jmm 有序性和可视性 都无法得到保障.
happens-before ordering( 先行发生排序)
如何避免这种情况?
排序原则已经做到:
a, 在程序顺序中, 线程中的每一个操作, 发生在当前操作后面将要出现的每一个操作之前.
b, 对象监视器的解锁发生在等待获取对象锁的线程之前.
c, 对volitile关键字修饰的变量写入操作, 发生在对该变量的读取之前.
d, 对一个线程的 Thread.start() 调用 发生在启动的线程中的所有操作之前.
e, 线程中的所有操作 发生在从这个线程的 Thread.join()成功返回的所有其他线程之前.
为了实现 happends-before ordering原则, java及jdk提供的工具:
a, synchronized关键字
b, volatile关键字
c, final变量
d, java.util.concurrent.locks包(since jdk 1.5)
e, java.util.concurrent.atmoic包(since jdk 1.5)
…
使用了happens-before ordering的例子:
(1) 获取对象监视器的锁(lock)
(2) 清空工作内存数据, 从主存复制变量到当前工作内存, 即同步数据 (read and load)
(3) 执行代码，改变共享变量值 (use and assign)
(4) 将工作内存数据刷回主存 (store and write)
(5) 释放对象监视器的锁 (unlock)
注意: 其中4,5两步是同时进行的.
这边最核心的就是第二步, 他同步了主内存,即前一个线程对变量改动的结果,可以被当前线程获知!(利用了happens-before ordering原则)
对比之前的例子
如果多个线程同时执行一段未经锁保护的代码段，很有可能某条线程已经改动了变量的值，但是其他线程却无法看到这个改动，依然在旧的变量值上进行运算，最终导致不可预料的运算结果。
经典j2ee设计模式Double-Checked Locking失效问题
双重检查锁定失效问题,一直是JMM无法避免的缺陷之一.了解DCL失效问题, 可以帮助我们深入JMM运行原理.
要展示DCL失效问题, 首先要理解一个重要概念- 延迟加载(lazy loading).
非单例的单线程延迟加载示例:
- class Foo
- {
- private Resource res = null;
- public Resource getResource()
- {
- // 普通的延迟加载
- if (res == null)
- res = new Resource();
- return res;
- }
- }
非单例的 多线程延迟加载示例:
- Class Foo
- {
- Private Resource res = null;
- Public synchronized Resource getResource()
- {
- // 获取实例操作使用同步方式, 性能不高
- If (res == null) res = new Resource();
- return res;
- }
- }
非单例的 DCL多线程延迟加载示例:
- Class Foo
- {
- Private Resource res = null;
- Public Resource getResource()
- {
- If (res == null)
- {
- //只有在第一次初始化时,才使用同步方式.
- synchronized(this)
- {
- if(res == null)
- {
- res = new Resource();
- }
- }
- }
- return res;
- }
- }
Double-Checked Locking看起来是非常完美的。但是很遗憾，根据Java的语言规范，上面的代码是不可靠的。
出现上述问题, 最重要的2个原因如下:
1, 编译器优化了程序指令, 以加快cpu处理速度.
2, 多核cpu动态调整指令顺序, 以加快并行运算能力.
问题出现的顺序:
1, 线程A, 发现对象未实例化, 准备开始实例化
2, 由于编译器优化了程序指令, 允许对象在构造函数未调用完前, 将 共享变量的引用指向 部分构造的对象, 虽然对象未完全实例化, 但已经不为null了.
3, 线程B, 发现部分构造的对象已不是null, 则直接返回了该对象.
不过, 一些著名的开源框架, 包括jive,lenya等也都在使用DCL模式, 且未见一些极端异常.
说明, DCL失效问题的出现率还是比较低的.
接下来就是性能与稳定之间的选择了?
DCL的替代 Initialize-On-Demand :
- public class Foo {
- // 似有静态内部类, 只有当有引用时, 该类才会被装载
- private static class LazyFoo {
- public static Foo foo = new Foo();
- }
- public static Foo getInstance() {
- return LazyFoo.foo;
- }
- }
维基百科的DCL解释:
http://en.wikipedia.org/wiki/Double-checked_locking
DCL的完美解决方案:
http://www.theserverside.com/patterns/thread.tss?thread_id=39606
总结:
多线程编程, 针对有写操作的变量, 必须 保证其所有引用点与主存中数据一致(考虑采用同步或volatile)
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
