并发专题 ----（JMM）java内存模型

Java 内存模型
--------------
内存模型描述的是程序中各变量（实例域、静态域和数组元素）之间的关系，以及在实际计算机系统中将变量存储到内存和从内存取出变量这样的低层细节。对象最终存储在内存中，但编译器、运行库、处理器或缓存可以有特权定时地在变量的指定内存位置存入或取出变量值。
------------------------
可见性
- - - - - - -
1. 同步与可见性（visibility）
synchronized 关键字强制实施一个互斥锁（互相排斥），这个互斥锁防止每次有多个线程进入一个给定监控器所保护的同步语句块。但是同步还有另一个方面：正如 JMM 所指定，它强制实施某些"内存可见性规则"。它确保了当存在一个同步块时缓存被更新，当输入一个同步块时缓存失效。
因此，在一个由给定监控器保护的同步块期间，一个线程所写入的值对于其余所有的执行由同一监控器所保护的同步块的线程来说是可见的。它也确保了编译器不会把指令从一个同步块的内部移到外部（虽然在某些情况下它会把指令从同步块的外部移到内部）。JMM 在缺乏同步的情况下不会做这种保证 —— 这就是只要有多个线程访问相同的变量时必须使用同步（或者它的同胞，易失性）的原因。 

2. Volatile 与可见性

特别是，内存模型定义了保证内存操作跨线程的可见性的 volatile 、 synchronized 和 final 的语义。 

volatile 语义保证 volatile 字段的读写直接在主存而不是寄存器或者本地处理器缓存中进行，并且代表线程
对 volatile 变量进行的这些操作是按线程要求的顺序进行的。
-----------------


发生前关系（happen-before）
-----------
像对变量的读写这样的操作，在线程中是根据所谓的“程序顺序”——程序的语义声明它们应当发生的顺序——排序的。在不同线程中的操作完全不一定要彼此排序——如果启动两个线程并且它们对任何公共监视器都不用同步执行、或者不涉及任何公共 volatile 变量，则完全无法准确地预言一个线程中的操作（或者对第三个线程可见）相对于另一个线程中操作的顺序。 

排序保证是在线程启动、一个线程参与另一个线程、一个线程获得或者释放一个监视器（进入或者退出一个同步块）、或者一个线程访问一个 volatile 变量时创建的。JMM 描述了程序使用同步或者 volatile 变量以协调多个线程中的活动时所进行的顺序保证。新的JMM 非正式地定义了一个名为 happens-before 的排序，它是程序中所有操作的部分顺序。
1)  一个线程中的每个操作“发生之前”于这个线程程序规定的其他后续出现的操作。
2)  对监视器的解锁“发生之前”于同一监视器上的所有后续锁定。
3)  对 volatile 变量的写“发生之前”于同一 volatile 变量 的每一个后续读。
4)  一个线程的 Thread.start()调用“发生之前”于这个启动后的线程的其他操作。
5)  线程中的所有操作“发生之前” 从这个线程的 Thread.join() 成功返回的所有其他线程。
-----------------------------

初始化安全性
--------------
JMM 还寻求提供一种新的初始化安全性保证——只要对象是正确构造的，然后所有线程都会看到在构造函数中设置的final 字段的值，不管是否使用同步在线程之间传递这个引用。

而且，所有可以通过正确构造的对象的 final 字段可及的变量，如用一个 final 字段引用的对象的 final 字段，也保证对其他线程是可见的。

这意味着如果 final 字段包含，比如说对一个 LinkedList 的引用，除了引用的正确的值对于其他线程是可见的外，这个 LinkedList 在构造时的内容在不同步的情况下，对于其他线程也是可见的。 可以不用同步安全地访问这个 final 字段，编译器可以假定 final 字段将不会改变，因而可以优化多次提取。

在构造函数的 final 字段的写与在另一个线程中对这个对象的共享引用的初次装载之间有一个类似于 happens-before 的关系。当构造函数完成任务时，对 final 字段的所有写（以及通过这些 final 字段间接可及的变量）变为“冻结”，所有在冻结之后获得对这个对象的引用的线程都会保证看到所有冻结字段的冻结值。初始化 final 字段的写将不会与构造函数关联的冻结后面的操作一起重新排序。

初始化安全性保证了在多线程共享情况下不可变对象的正确构造。