深入理解Java虚拟机——Java内存模型与线程

1：Java内存模型

• Java虚拟机试图定义一种Java内存模型（JMM）来屏蔽掉各种硬件和操作系统的内存访问差异，以实现让Java程序在各种平台下都可以达到一致内存访问效果。

之前的主流C/C++直接使用物理硬件和操作系统的内存模型，会由于不同平台上内存模型差异，导致出现问题

• 定义Java内存模型并非一件容易的事情，必须足够严谨，才可以让Java的并发内存访问操作不会有歧义；但是，也要定义的足够宽松，使得虚拟机可以有空间去利用硬件的各种特性来获取更好的执行速度

经过长时间的验证和修补，JDK1.5以后Java内存模型已经成熟和完善起来

1.1 主内存与工作内存

• Java内存模型的主要目标是定义程序中各个变量的访问规则，即在虚拟机中将变量存储到内存和从内存中取出变量。

此处的变量与Java编程中所说的变量有所区别，它包括了实例字段，静态字段和构成数组对象元素，但是不包括局部变量与方法参数，因为他们都是线程私有，不会被共享

• Java内存模型规定了所有的变量都存储在主内存中（虚拟机内存的一部分）。每条线程还有自己的工作内存，线程的工作内存中保存了被该线程使用到的变量的主内存副本拷贝，线程对变量的所有操作（读取，赋值等）都必须在工作内存中进行，而不可以直接读写主内存中的变量。不同的线程之间也无法直接访问对方工作内存的中的变量，线程间变量值的传递均需要通过主内存来完成。如下图
  
  注意：这里的主内存，工作内存与Java内存区域中的Java堆，栈，方法区等并不是同一个层次的内存划分，如果一定要对比，主内存对应与Java堆中的对象实例数据部分，而工作内存则对应与虚拟机栈中的部分区域。

1.2 内存间交互操作

关于主内存与工作内存之间具体的交互协议，即一个变量如何从主内存拷贝到工作内存，如何从工作内存同步回主内存之类的实现细节，Java内存模型定义了以下8种操作来完成（虚拟机实现时必须保证下面提及的每一种操作都是原子的，不可再分的））
1：lock(锁定)：作用于主内存，它把一个变量标记为一条线程独占状态；
2：unlock(解锁)：作用于主内存，它将一个处于锁定状态的变量释放出来，释放后的变量才能够被其他线程锁定；
3：read(读取)：作用于主内存，它把变量值从主内存传送到线程的工作内存中，以便随后的load动作使用；
4：load(载入)：作用于工作内存，它把read操作的值放入工作内存中的变量副本中；
5：use(使用)：作用于工作内存，它把工作内存中的值传递给执行引擎，每当虚拟机遇到一个需要使用这个变量的指令时候，将会执行这个动作；
6：assign(赋值)：作用于工作内存，它把从执行引擎获取的值赋值给工作内存中的变量，每当虚拟机遇到一个给变量赋值的指令时候，执行该操作；
7：store(存储)：作用于工作内存，它把工作内存中的一个变量传送给主内存中，以备随后的write操作使用；
8：write(写入)：作用于主内存，它把store传送值放到主内存中的变量中。

1、不允许read和load、store和write操作之一单独出现（即不允许一个变量从主存读取了但是工作内存不接受，或者从工作内存发起会写了但是主存不接受的情况），以上两个操作必须按顺序执行，但没有保证必须连续执行，也就是说，read与load之间、store与write之间是可插入其他指令的。
2、不允许一个线程丢弃它的最近的assign操作，即变量在工作内存中改变了之后必须把该变化同步回主内存。
3、不允许一个线程无原因地（没有发生过任何assign操作）把数据从线程的工作内存同步回主内存中。
4、一个新的变量只能从主内存中“诞生”，不允许在工作内存中直接使用一个未被初始化（load或assign）的变量，换句话说就是对一个变量实施use和store操作之前，必须先执行过了assign和load操作。
5、一个变量在同一个时刻只允许一条线程对其执行lock操作，但lock操作可以被同一个条线程重复执行多次，多次执行lock后，只有执行相同次数的unlock操作，变量才会被解锁。
6、如果对一个变量执行lock操作，将会清空工作内存中此变量的值，在执行引擎使用这个变量前，需要重新执行load或assign操作初始化变量的值。
7、如果一个变量实现没有被lock操作锁定，则不允许对它执行unlock操作，也不允许去unlock一个被其他线程锁定的变量。
8、对一个变量执行unlock操作之前，必须先把此变量同步回主内存（执行store和write操作）。
如上8种内存访问操作及上述规则限定，再加对volatile的一些特殊规定，就已经完全确定了Java程序中那些内存访问操作在并发下是安全的

等效判断原则——先行发生原则，可以用来确定一个访问在并发环境下是否安全

1.3 对于volatile型变量的特殊规则

• 关键字volatile是Java虚拟机提供的最轻量级的同步机制（但是它不容易完全被正确，完整的理解，遇到许多线程数据竞争问题都是使用synchronized进行同步）

了解volatile语义对后面了解多线程操作的其他特性很有意义

Java内存模型对volatile专门定义了一些特殊访问规则，在介绍这个规则定义前，我们先来讲解一下volatile关键字的作用

当一个变量定义为volatile之后，它将具备两个特性
第一个特性是保证此变量对所有线程的可见性，这里的可见性是指当一条线程修改了这个变量的值，新值对于其他线程来说是可以立即得知的。（普通变量做不到，它的值在线程间传递均需要通过主内存来完成）

volatile变量在各个线程的工作内存中不存在不一致性问题（在各个线程的工作内存中，volatile变量也可以存在不一致性情况，但是由于每次使用之前都要刷新，执行引擎看不到不一致性的情况，因此可以认为不存在一致性问题），但是Java里面的运算并非原子性操作，导致volatile变量的运算在并发情况下一样是不安全

例子演示：参考volatile变量自增测试
由于volatile变量只可以保证可见性，在以下两种情况下能保证线程的安全性，其余情况我们仍要通过加锁来保证原子性：
1：运行结果并不依赖变量的当前值，或者能够确保只有单一的线程修改变量的值
2：变量不需要与其他状态变量共同参与不变约束

第二个特性是禁止指令重排序优化
普通的变量仅仅会保证在该方法的执行过程中所有依赖赋值结果的地方都能获得正确的结果，而不能保证变量赋值操作的顺序与程序代码的执行顺序一致（线程的方法执行过程中无法感知到这一点，也就是Java内存模型中描述的“线程内表现为串行的语义”）

在本节的最后，我们回头看一下Java内存模型中对volatile变量定义的特殊规则。假定T表示一个线程，V和W分别表示两个volatile型变量那么在进行read， load，assign,store和write操作时需要满足如下规则：

规则一：只有当线程T对变量v执行的前一个动作是load的时候，线程T才能对变量V执行use动作，并且，只有当线程工对变量V执行的后一个动作是use的时候，线程T才能对变量V执行load动作。线程T对变量v的use动作可以认为是和线程T对变量V的load、reaed 动作相关联，必须连续一起出现(这条规则要求在工作内存中，每次使用v前都必须先从主内存刷新最新的值，用于保证能看见其他线程对变量v所做的修改后的值)。

规则二：只有当线程T对变量V执行的前一个动作是asxign的时候，线程T才能对变量V执行store动作，并且，只有当线程T对变量V执行的后一个动作是store的时候，线程T才能对变量v执行assisgn动作。线程T对变量V的assign 动作可以认为是和线程T对变量V的store、write 动作相关联，必须连续一起出现( 这条规则要求在工作内存中，每次修改V后都必须立刻同步回主内存中，用于保证其他线程可以看到自己对变量V所做的修改)。

规则三：假定动作A是线程T对变量V实施的use或assign动作，假定动作F是和动作A相关联的load或store动作，假定动作P是和动作F相应的对变量v的read或write动作(这条规则要求volatile修饰的变量不会被指令重排序优化，保证代码的执行顺序与程序的顺序相同)。

1.4 对long和double型变量的特殊规则

Java内存模型将没有被volatile修饰的64位的数据的读写操作划分为两次32为的操作来进行，这样的话，多线程并发，就会存在线程可能读取到“半个变量”的值，不过，这种情况非常罕见，目前各平台的商用虚拟机几乎都选择把64位的读写作为原子操作来实现规范的。

1.5 原子性，可见性，有序性

Java内存模型就是围绕着再并发过程中如何处理原子性，可见性，和有序性来建立的
1、原子性（Atomicity）
由Java内存模型来直接保证的原子性变量包括read、load、assign、use、store和write，我们大致可以认为基本数据类型的访问读写是具备原子性的。如果应用场景需要一个更大方位的原子性保证，Java内存模型还提供了lock和unlock操作来满足这种需求，尽管虚拟机未把lock和unlock操作直接开放给用户使用，但是却提供了更高层次的字节码指令monitorenter和monitorexit来隐式的使用这两个操作，这两个字节码指令反应到Java代码中就是同步块——synchronized关键字，因此在synchronized块之间的操作也具备原子性。

2、可见性（Visibility）
可见性是指当一个线程修改了共享变量的值，其他线程能够立即得知这个修改。volatile变量可以做到这一点。Java内存模型是通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介的方式来实现可见性的，无论是普通变量还是volatile变量都是如此，普通变量与volatile变量的区别是，volatile的特殊规则保证了新值能立即同步到主内存，以及每次使用前立即从主内存刷新。因此，可以说volatile保证了多线程操作时变量的可见性，而普通变量则不能保证这一点。除了volatile之外，Java还有两个关键字能实现可见性，即synchronized和final。同步块的可见性是由“对一个变量执行unlock操作前，必须先把此变量同步回主内存”这条规则获得的，而final关键字的可见性是指：被final修饰的字段在构造器中一旦初始化完成，并且构造器没有把"this"的引用传递出去，那么在其他线程中就能看见final字段的值。

3、有序性（Ordering）
Java程序中天然的有序性可以总结为一句话：如果在本线程内观察，所有的操作都是有序的：如果在一个线程中观察另外一个线程，所有的线程操作都是无序的。前半句是指“线程内表现为串行的语义”，后半句是指“指令重排序”现象和“工作内存与主内存同步延迟”现象。Java语言提供了volatile和synchronized两个关键字来保证线程之间操作的有序性，volatile关键字本身就包含了禁止指令重排序的语义，而synchronized则是由“一个变量在同一个时刻只允许一条线程对其进行lock操作”这条规则获得的，这条规则决定了持有同一个锁的两个同步块只能串行的进入。

2：Java与线程

2.1 线程的实现

• 线程是比进程更轻量级的调度执行单位，线程的引人，可以把一个进程的资源分配和执行调度分开，各个线程既可以共享进程资源(内存地址、文件IO等)，又可以独立调度(线程是CPU调度的基本单位)。

• 主流的操作系统都提供了线程实现，Java 语言则提供了在不同硬件和操作系统平台下对线程操作的统一处理， 每个已经执行start()且还未结束的java.lang.Thread类的实例就代表了一个线程。我们注意到Thread类与大部分的Java API有显著的差别，它的所有关键方法都是声明为Native的。在Java API中，一个Native方法往往意味着这个方法没有使用或无法使用平台无关的手段来实现(当然也可能是为了执行效率而使用Native方法，不过，通常最高效率的手段也就是平台相关的手段)

• 实现线程主要有3种方式：1：使用内核线程实现2：使用用户线程实现3：使用用户线程加轻量级进程混合实现。

• Java线程在JDK 1.2之前，是基于称为“绿色线程’(Green Threads) 的用户线程实现的，而在JDK 1.2之后线程模型替换为基于操做系统原生线程模型来实现。因此，在目前的JDK版本中，操作系统持怎样的线程模型，在很大程度上决定了Java虚拟机的线程是怎样映射的，这点在不同的平台上没有才有办法达成一 致，虚拟机规范中也并未限定Java线程需要使用哪种线程模型来实现。线程模型只对线程的并发规模和操作成本产生影响，对Jave 程序的编码和运行过程来说，这些差异都是透明的。

2.2 Java 线程调度

• 线程调度是指系统为线程分配处理器使用权的过程，主要调度方式有两种，分别是
  同步式线程调度（Cooperative Theadscheduling )和抢占式线程调度（Premptive Threads Scheduling)。

• 如果使用协同式调度的多线程系统，线程的执行时间由线程本身来控制，线程把自己的工作执行完了之后，要主动通知系统切换到另外个线程上。协同式多线程的最大好处是实现简单，而且由于线程要把自己的事情干完后才会进行线程切换，切换操作 对线程自己是可知的。所以没有什么线程同步的问题。它的坏处就是线程执行时间不可控制，甚至如果一个线程编写有问题，一直不告知系统进行线程切换，那么程序就会一直阻塞在那里

• 如果使用抢占式调度的多线程系统，那么每个线程将由系统类分配执行时间，线程的切换不由线程本身来决定(在Java中，Threadyield() 可以让出执行时间，但是要获取执行时间的话，线程本身是没有什么办法的)。在这种实现线程调度的方式下，线程的执行时间是系统可控的，也不会有一个线程导致整个进程阻塞的问题，Java使用的线程调度方式就是抢占式调度。
  虽然Java线程调度是系统自动完成的，但是我们还是可以“建议”系统给某些线程多分配一点执行时间，另外的一些线程则可以少分配一点这项操作可以通过设置线程优先级来完成。Java 语言一共设置了 10个级别的线程优先级(Thread.MIN PRIORITY 至Thread.MAX_PRIORITY);在两个线程同时处于Ready状态时，优先级越高的线程越容易被系统选择执行。

不过， 线程优先级并不是太靠谱，原因是Lava的线程是通过映射到系统的原生线程上来实现的，所以线程调度最终还是取决于操作系统，虽然现在很多操作系统都提供线程优先级的概念，但是并不见得能与Java线程的优先级一一对应

2.3 状态转化

Java线程的5种状态及切换