内容导航：
- Java内存模型
- 硬件存储体系结构
- Java内存模型和硬件存储体系之间的桥梁：
- 共享对象的可见性
- 竞争条件
Java内存模型规定了JVM怎样与计算机存储系统（RAM）协调工作。JVM是一个虚拟机模型，因此这个模型自然包含一个内存的模型
理解java内存模型对于设计正确的并发程序非常重要。JVM规定了不同线程何时以及怎样能看到那些被共享变量的读写，怎样同步对共享变量的訪问控制。
最初的java内存模型并不完好。所以他在java1.5中被改动了。以下的内存模型在java1.8中仍然使用。
Java内存模型
JVM中内存模型被划分为栈（stack）和堆（heap）。下图是内存的逻辑图
在JVM中运行的每个线程有自己的栈空间。
每个线程栈包括有线程调用方法当前运行位置的指针。我们把它叫做栈指针。当线程运行他的代码时候，栈指针会改变。共享一块堆空间。
线程栈也包括全部正在被运行的方法的局部变量。一个线程仅仅能訪问他自己的栈。每个线程创建的局部变量对其它线程是不可见的。纵使两个线程正在运行同一段代码，他们也仅仅会创建属于自己栈空间的局部变量。也就是说每个线程有他自己的局部变量，相互之间不影响。
全部的局部基本数据类型（boolean、byte、short、char、int、long、float、double）全然存储在线程栈空间里，而且其它线程不可见。一个线程能够传递自己局部基本数据的拷贝给还有一个线程，可是他们之间并不共享。
堆空间中存放的是应用程序中全部的对象，无论是哪一个线程创建的。
而且包含基本数据对象（eg.Byte，Integer，Long等）。
无论这个对象是作为局部变量被创建，还是作为还有一个对象的成员变量被创建。他都在堆中。即一切对象都在堆空间。
看下图：
一个局部变量可能是基本数据类型。还可能是一个对象的引用。他们都在创建自己的线程栈空间，引用所指向的真正的对象在堆空间。
一个对象的成员方法。而且这些方法中也可能包括局部变量。这些局部变量在所属的线程栈中
一个对象的成员变量，无论是基本类型还是对象的引用。都存在这个堆空间的对象的内部
同一个对象能够被不同的拥有这个对象的引用的线程訪问。而且能够訪问对象的成员变量。
假设两个线程同一时刻调用同样对象的成员方法，他们都能訪问对象的成员变量，可是各自有自己的局部变量的拷贝。
以下的图阐述了上述内容：
硬件存储体系结构：
以下是简单的现代计算机的存储结构：
现代计算机通常有2个甚至很多其它的CPU，这些CPU中的一些还可能是多核的。
关键点就是多CPU的计算机同意多个线程同一时候执行（是真正的并行而非并发）。每个cpu在给定的时间片执行一个线程。假设java程序是多线程的，每个线程就能够在各个cpu上同一时候执行。
每一个cpu都包括有一系列寄存器。
cpu直接从寄存器运行运算比从内存要快非常多倍。
每个cpu还可能有cpu缓存（我们熟称的cache）。实际上大多数现代cpu都有不同容量的cache。Cpu从cache存取又比从内存快，可是比寄存器又慢一些。一些cpu还有多级缓存（L1、L2等）。可是这并不影响理解java内存模型，我们所要知道的就是在内存和cpu之间另一层缓存cache。
通常，cpu訪问主存的时候须要读一部分到cache。还可能把cache的一部分有读到寄存器，然后运行运算。当cpu须要把运算结果写回到主存的时候，会先把值从寄存器更新到cache，cache放满后再写回主存。
存储在cache中的值通常在cpu须要存储其它的东西时一起被写回到内存。
Cache把里面存储的内容一次性写回到主存。这个过程并不一定读写整个cache。通常情况下是更新cache中更小的单位，叫做cache lines 缓存行。一行或多行cache line会从主存读取到cache。或者从cache被写回主存。
Java内存模型和硬件存储体系之间的桥梁
正如已经提及的，java内存模型和硬件存储体系是不同的。
硬件存储体系并不会区分堆和栈。
在硬件层面上，堆和栈都分配在主存中。堆和栈中的一部分还可能在cache和寄存器中。例如以下图：
当对象和变量被存储在计算机不同的存储区域（rejister、cache、main-memory）的时候，就会出现故障了。
有两个问题例如以下：
- 线程对共享变量读写的可见性
- 读写检查共享变量的竞争条件
共享对象的可见性
假设两个或者多个线程共享一个对象而没实用volatile声明或者synchronize同步，某一个线程对共享对象的更新对其它线程可能是不可见的。
设想一下一个開始被存在主内存的共享对象。执行在cpu1上的线程把这个共享对象读入到cache。
然后对这个共享对象做更改。
仅仅要cache还没有被刷新到主存，对象的更改版本号对执行在其它cpu的线程就是不可见的。这样一来，每一个线程就使用的是自己对共享对象的拷贝，这些拷贝存储在各自cpu cache中。
以下这幅图阐述了这样的情况。
一个执行在左側cpu的线程把共享对象复制到自己的cpu cache中，而且把count值改为2.这个改变对执行在右側cpu的线程是不可见的。
由于对count的更新并没有刷新到主存。
要解决问题。我们可以使用java的volatilekeyword。Volatilekeyword可以确保被声明的变量直接从主存读取或者是直接在主存更新而不经过cache中间层。
竞争条件
多个线程对共享变量的更新还会引发竞争。
设想线程A读取共享变量的count字段到他的cache，线程B也是。如今线程A对count加1，线程B也是。
如今var1已经被添加两次，每一个cpu一次。
假设这些添加是被顺序运行（先后次序：即A read increament writeback --> B read increament writeback）的，那么变量count将会顺序加1两次。终于结果是原始值加2写回主存。
可是，假设两次添加被并发运行（交叉次序）而没有适当的同步。那么无论是A还是B写回到主存的结果都是原始值加1。虽然做了两次加。
以下是上述问题的图：
为了解决问题，引入java的synchronized block，让某一系列操作成为原子性的，即不能够被打断（类似数据库中的事务transaction），从而实现不同线程对某一代码块的相互排斥訪问。
翻译原文地址：http://tutorials.jenkov.com/java-concurrency/java-memory-model.html