【Java并发编程】：深刻Java内存模型—内存操做规则总结

主内存与工做内存

    java内存模型的主要目标是定义程序中各个变量的访问规则，即在虚拟机中将变量存储到内存和从内存中取出变量这样的底层细节。此处的变量主要是指共享变量，存在竞争问题的变量。Java内存模型规定全部的变量都存储在主内存中，而每条线程还有本身的工做内存，线程的工做内存中保存了该线程使用到的变量的主内存副本拷贝，线程对变量的全部操做（读取、赋值等）都必须在工做内存中进行，而不能直接读写主内存中的变量（根据Java虚拟机规范的规定，volatile变量依然有共享内存的拷贝，可是因为它特殊的操做顺序性规定——从工做内存中读写数据前，必须先将主内存中的数据同步到工做内存中，全部看起来如同直接在主内存中读写访问通常，所以这里的描述对于volatile也不例外）。不一样线程之间也没法直接访问对方工做内存中的变量，线程间变量值得传递均须要经过主内存来完成。

内存间交互操做

    Java内存模型中定义了如下8中操做来完成主内存与工做内存之间交互的实现细节：

    一、luck（锁定）：做用于主内存的变量，它把一个变量标示为一条线程独占的状态。

    二、unlock（解锁）：做用于主内存的变量，它把一个处于锁定状态的变量释放出来，释放后的变量才能够被其余线程锁定。

    三、read（读取）：做用于主内存的变量，它把一个变量的值从主内存传输到工做内存中，以便随后的load动做使用。

    四、load（载入）：做用于工做内存的变量，它把read操做从主内存中获得的变量值放入工做内存的变量副本中。

    五、use（使用）：做用于工做内存的变量，它把工做内存中的一个变量的值传递给执行引擎，每当虚拟机遇到一个须要使用到变量的值得字节码指令时将会执行这个操做。

    六、assign（赋值）：做用于工做内存的变量，它把一个从执行引擎接收到的值赋给工做内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操做。

    七、store（存储）：做用于工做内存的变量，它把工做内存中的一个变量的值传递到主内存中，以便随后的write操做使用。

    八、write（写入）：做用于主内存的变量，它把store操做从工做内存中获得的变量值放入主内存的变量中。

   Java内存模型还规定了执行上述8种基本操做时必须知足以下规则：

    一、不容许read和load、store和write操做之一单独出现，以上两个操做必须按顺序执行，但没有保证必须连续执行，也就是说，read与load之间、store与write之间是可插入其余指令的。

    二、不容许一个线程丢弃它的最近的assign操做，即变量在工做内存中改变了以后必须把该变化同步回主内存。

    三、不容许一个线程无缘由地（没有发生过任何assign操做）把数据从线程的工做内存同步回主内存中。

    四、一个新的变量只能从主内存中“诞生”，不容许在工做内存中直接使用一个未被初始化（load或assign）的变量，换句话说就是对一个变量实施use和store操做以前，必须先执行过了assign和load操做。

    五、一个变量在同一个时刻只容许一条线程对其执行lock操做，但lock操做能够被同一个条线程重复执行屡次，屡次执行lock后，只有执行相同次数的unlock操做，变量才会被解锁。

    六、若是对一个变量执行lock操做，将会清空工做内存中此变量的值，在执行引擎使用这个变量前，须要从新执行load或assign操做初始化变量的值。

    七、若是一个变量实现没有被lock操做锁定，则不容许对它执行unlock操做，也不容许去unlock一个被其余线程锁定的变量。

    八、对一个变量执行unlock操做以前，必须先把此变量同步回主内存（执行store和write操做）。

volatile型变量的特殊规则

    Java内存模型对volatile专门定义了一些特殊的访问规则，当一个变量被定义成volatile以后，他将具有两种特性：

    一、保证此变量对全部线程的可见性。这里不具体解释了。须要注意，volatile变量的写操做除了对它自己的读操做可见外，volatile写操做以前的全部共享变量均对volatile读操做以后的操做可见，另外注意其适用场景，详见http://blog.csdn.net/ns_code/article/details/17290021和http://blog.csdn.net/ns_code/article/details/17101369这两篇博文。

    二、禁止指令重排序优化。普通的变量仅仅会保证在该方法的执行过程当中全部依赖赋值结果的地方都能得到正确的结果，而不能保证变量赋值操做的顺序与程序中的执行顺序一致，在单线程中，咱们是没法感知这一点的。

    补充：Java语言规范规定了JVM线程内部维持顺序化语义，也就是说只要程序的最终结果等同于它在严格的顺序化环境下的结果，那么指令的执行顺序就可能与代码的顺序不一致，这个过程经过叫作指令的重排序。指令重排序存在的意义在于：JVM可以根据处理器的特性（CPU的多级缓存系统、多核处理器等）适当的从新排序机器指令，使机器指令更符合CPU的执行特色，最大限度的发挥机器的性能。在没有同步的状况下，编译器、处理器以及运行时等均可能对操做的执行顺序进行一些意想不到的调整

final域

    final类型的域是不能修改的，除了这一点外，在Java内存模型中，final域还有着特殊的语义，final域能确保初始化过程的安全性，从而能够不受限制地访问不可变对象，并在共享这些对象时无须同步。具体而言，就是被final修饰的字段在构造器中一旦被初始化完成，而且构造器没有把“this”的引用传递出去（this引用逃逸是一件很危险的事情，其余线程有可能经过这个引用访问到“初始化了一半”的对象），那么在其余线程中就能看到final字段的值，并且其外、外部可见状态永远也不会改变。它所带来的安全性是最简单最纯粹的。

long和double型变量的特殊规则

    Java内存模型要求lock、unlock、read、load、assign、use、store和write这8个操做都具备原子性，可是对于64位的数据类型long和double，在模型中特别定义了一条宽松的规定：容许虚拟机将没有被volatile修饰的64位数据的读写操做划分为两次32位的操做来进行。这样，若是有多个线程共享一个未被声明为volatile的long或double类型的变量，而且同时对它们进行读取和修改操做，那么某些线程可能会读到一个既非原值，也非其余线程修改值得表明了“半个变量”的数值。不过这种读取到“半个变量”的状况很是罕见，由于Java内存模型虽然容许虚拟机不把long和double变量的读写实现成原子操做，但容许迅疾选择把这些操做实现为具备原子性的操做，并且还“强烈建议”虚拟机这样实现。目前各类平台下的商用虚拟机几乎都选择吧64位数据的读写操做做为原子操做来对待，所以在编码时，不须要将long和double变量专门声明为volatile。

转载：http://blog.csdn.net/ns_code/article/details/17377197