深入理解Java虚拟机(2)之十五-Java内存模型与线程

Java内存模型

1、主内存和工作内存

Java内存模型的主要目标是定义程序中各个程序的访问规则，即在虚拟机中将变量存储到内存和从内存中取出变量这样的底层细节。此处的变量与Java编程的变量有所区别，它包括实例字段、静态字段和构成数组对象的元素，但不包含局部变量和方法参数，因为后者是线程私有，不会存在共享，自然也不会存在竞争问题。

Java内存模型规定所有变量都存储在主内存(Main Memory)中，每条线程还有自己的工作内存(Working Memory)，线程的工作内存中保存了被该线程使用到的变量的主内存副本拷贝，线程对变量的所有操作(读取、赋值等)都必须在工作内存中进行，而不能直接读写主内存的变量。不同线程之间也不能访问对方线程的变量，线程之间变量值的传递需要通过主内存来完成。如下图所示：

2、内存间交互操作

关于主内存和工作内存之间具体的交互协议，即一个变量是如何从主内存拷贝到工作内存、如何从工作内存同步到主内存之类的实现细节，Java定义了8种操作来完成，虚拟机实现时必须保证每种操作都是原子的、不可再分的。

• lock(锁定)：作用于主内存的变量，它把一个变量标识成一条线程独占的状态。
• unlock(解锁)：作用于主内存的变量，它把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定。
• read(读取)：作用于主内存的变量，它把一个变量的值从主内存传输到线程的工作内存中，以便随后的load动作使用。
• load(载入)：作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的变量副本中。
• use(使用)：作用于工作内存的变量，它把工作内存的一个变量的值传递给执行引擎，每当虚拟机遇到一个需要使用到变量的值的字节码指令时将会执行这个操作。
• assign(赋值)：作用于工作内存的变量，它把一个从执行引擎接受到的值赋给工作内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令时都会执行这个操作。
• store(存储)：作用于工作内存的变量，它把工作内存中的一个变量的值传送到主内存中，以便所有的write工作使用。
• write(写入)：作用于主内存的变量，它把store操作从工作内存得到的变量的值放到主内存的变量中。

Java内存模型还规定在执行上述8种操作时必须满足以下规则：

• 不允许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操作)。

3、对于volatile型变量的特殊规则

关键词volatile可以说是Java虚拟机提供的最轻量级的同步机制。

当一个变量定义为volatile之后，具备两个特性：

• 第一是保证该变量对所有线程的可见性。这里的“可见性”是指当一条线程修改了这个变量的值，新值对于其他线程来说是可以立即得知的。而普通变量不能做到这一点，普通变量在线程之间传递都需要通过主内存来完成，例如，线程A修改了一个普通变量的值，然后向主内存回写，另一条线程B在线程A回写完成之后再从主内存进行读取，新值才对线程B可见。

  由于volatile只保证可见性，在不符合以下两条规则的运算场景下，仍然要通过加锁(使用synchronized或java.util.concurrent中的原子类)来保证原子性。

  • 运算结果不依赖变量的当前值，或者保证只有单一的线程能够修改变量的值。
  • 变量不需要与其他的状态变量共同参与不变约束。

• 第二个语义是禁止指令重排优化，普通的变量仅仅会保证在该方法的执行过程中所有依赖赋值结果的地方都能获取正确的结果，而不能保证变量赋值操作的顺序与程序代码中执行顺序一致。因为一个线程的方法执行过程中无法感知到这点，这也是Java内存模型中描述的所谓“线程内表现为串行的语义”(Within Thread As-If-Serial Semantics)。

Java内存模型对volatile变量定义的特殊规则。假定T代表一个线程，V和W分别代表两个volatile型变量，那么在进行read、load、use、assign、store和write操作时需要满足如下规则：

• 只有当线程T对变量执行的前一个动作是load的时候，线程T才能对变量V执行use动作，并且，只有当线程T对变量V执行的后一个动作是use的时候，线程T才能对变量V执行load操作。线程T对变量V的use操作可以认为是和线程T对变量V的load、read动作相关联，必须连续一起出现。
• 只有当线程T对变量执行的前一个动作是assign的时候，线程T才能对变量V执行store动作，并且，只有当线程T对变量V执行的后一个动作是store的时候，线程T才能对变量V执行assign操作。线程T对变量V的assign操作可以认为是和线程T对变量V的store、write动作相关联，必须连续一起出现。
• 假定动作A是线程T对变量V实施的use或assign动作，假定动作F是和动作A相关联的load或store操作，假定动作P是和动作F相应的对变量V的read或write动作；类似的，假定动作B是线程T对变量W实施的use或assign动作，假定动作G是和动作B相关联的load或store操作，假定动作Q是和动作G相应的对变量V的read或write动作。如果A先于B，那么P先于Q。

4、对于long个double型变量的特殊规则

Java内存模型要求lock、unlock、read、load、use、assign、store、write这8个操作都具有原子性，但对于64位的数据类型(long和double)，虚拟机允许将没有被volatile修饰的64位数据的读写操作划分为两次32位的操作来进行，即允许虚拟机实现选择可以不保证64位数据类型的load、store、read和write这4个操作的原子性，这点就是所谓long和double的非原子性协定。

5、原子性、可见性与有序性

• 原子性(Atomicity)：由Java内存模型来直接保证的原子性变量操作包括read、load、use、assign、store、write，我们大致可以认为基本数据尅性的访问读写是具备原子性的。

  如果应用场景需要一个更大范围的原子性保证，Java内存模型还提供了lock和unlock操作来满足这种需求，尽管虚拟机未把lock和unlock直接开放给用户使用，但是却提供了更高层次的字节码指令monitorenter和monitorexit来隐式地使用这两个操作，这两个字节码指令反映到Java代码中就是同步块——synchronized关键字，因此在synchronized块之间的操作也具备原子性。

• 可见性(Visibility)：可见性是指当一个线程修改了共享变量的值，其他线程能够立刻得知这个修改。Java内存模型是通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介的方式实现可见性的，无论是普通变量还是volatile变量都是如此，普通变量和volatile变量的区别是，colatile特殊规则保证了新值能够立即同步回主内存，以及每次使用前立即从主内存刷新。因此，可以说volatile保证了多线程操作时变量的可见性，而普通变量不能保证这一点。

  除了volatile，Java还有两个关键字可以实现可见性，即synchronized和final。

• 有序性(Ordering)：Java程序中的有序性可以总结为一句话：如果在本线程内观察，所有操作都是有序的；如果在一个线程观察另一个线程，所有的操作都是无序的。前半句是指“线程内表现为串行的语义”，后半句是指“指令重排序”现象和“工作内存和主内存同步延迟的现象”。

  Java提供volatile和synchronized来保证两个线程之间操作的有序性。

6、先行发生原则

Java语言中的“先行发生”(happen-before)原则是判断数据是否存在竞争、线程是否安全的主要依据。

先行发生是Java内存模型中定义的两项操作之间的偏序关系，如果说操作A先行发生于操作B，其实就是说在发生操作B之前，操作A产生的影响能被操作B观察到，“影响”包括修改了内存找那个共享变量的值、发送了消息。调用了方法等。

// 以下操作在线程A中执行
i = 1;

// 以下操作在线程B中执行
j = 1;

// 以下操作在线程C中执行
i = 2;

假设线程A的操作i = 1;先行发生于线程B的j = 1;的操作，那么可以确定，在线程B的操作执行完成之后，变量j的值一定是1，得出这个结论的依据有两个：一是根据先行发生原则，i = 1;的结果可以被观察到；二是线程C还没“登场”，线程A操作之后没有其他线程修改i的值。现在再来考虑线程C，依然保持线程A和线程B之间的先行发生关系，而线程C出现在线程A和线程B的操作之间，但是线程C与线程B没有先行发生关系，那i的值会是多少？答案是不确定的！1和2都有可能，因为线程C对变量i的影响可能会被线程B观察到，也可能不会，这时候线程B就存在读到过期数据的风险，不具备多线程安全性。

下面是Java内存模型“天然的”先行发生关系：

• 程序次序规则(Program Order Rule)：在一个线程内，按照程序代码顺序，书写在前面的操作先行发生于书写在后面的操作。准确地说，应该是控制流顺序而不是程序代码顺序，因为要考虑循环、分支等结构。
• 管程锁定规则(Monitor Lock Rule)：一个unlock操作先行发生于后面对同一个锁的lock操作。这里必须强调同一个锁，而“后面”是指时间上的顺序。
• volatile变量规则(Volatile Variable Rule)：对一个volatile变量的写操作先行发生于后面对这个变量的读操作，这里的“后面”是指时间上的顺序。
• 线程启动规则(Thread Start Rule)：Thread对象的start()方法先行发生于此线程的每一个动作。
• 线程终止规则(Thread Termination Rule)：线程中的所有操作都先行发生于对此线程的终止检测，我们可以通过Thread.join()方法结束、Thread.isAlive()的返回值等手段检测到线程已终止执行。
• 线程中断规则(Thread Interruption Rule)：对线程interrupt()方法的调用先行发生于被中断线程被中断线程的代码检测到中断事件的发生，可以通过Thread.interrupted()方法检测到是否中断。
• 对象终结规则(Finalizer Rule)：一个对象的初始化完成(构造函数执行结束)先行发生于finalize()方法的开始。
• 传递性(Transitivity)：如果操作A先行发生于操作B，操作B先行发生于操作C，那就可以得出操作A先行发生于操作C。

Java与线程

1、线程的实现

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

线程实现主要有3种方式：

1.1、使用内核线程实现

内核线程(Kernel-Level Thread,KLT)就是直接用操作系统内核支持的线程，这种线程由内核来完成线程切换，内核通过操纵调度器(Scheduler)对线程进行调度，并负责将线程任务映射到各个处理器上。每个内核线程课时视为内核的一个分身，这样操作系统就有能力同时处理多件事情，支持多线程的内核叫做多线程内核(Multi-Threads Kernel)。

程序一般不会直接去使用内核线程，而是去使用内核线程的一个高级接口——轻量级进程(Light Weight Process,LWP)，轻量级进程就是通常意义上的线程，由于每个轻量级进程都由一个内核线程支持，因此只有先支持内核线程，才有轻量级进程。这种轻量级进程与内核线程之间1:1的关系称为一对一的线程模型。如图。

由于内核线程的支持，每个轻量级进程都能称为一个独立的调度单位，即使有一个轻量级进程在系统调用中阻塞，也不会影响整个进程继续工作，但是轻量级进程具有它的局限性：首先，由于基于内核线程实现的，所以各种线程操作，如创建、析构及同步，都需要进行系统调用。而系统调用的代价相对较高，需要在用户态(User Mode)和内核态(Kernel Mode)中来回切换。其次，每个轻量级进程都需要一个内核线程支持，因此轻量级进程需要消耗一定的内核资源，因此一个系统支持的轻量级进程的数量是有限的。

1.2、使用用户线程实现

从广义上来说，一个线程只要不是内核线程，就可以认为是用户线程(User Thread,UT)，因此，从这个定义上来说，轻量级进程也属于用户线程，但轻量级进程的实现始终是建立在内核之上的，许多操作需要系统调度，效率会受到一些限制。

狭义上的用户线程是指完全建立在用户空间的线程库上，系统内核不能感知线程的存在。用户线程的创建、同步、销毁和调度完全在用户态中完成，不需要内核的帮助，如果程序实现得当，这种线程不需要切换到内核态，因此操作可以非常快速且低消耗，也可以支持更大规模的线程数量，部分高性能数据库的多线程就是用户线程实现的。这种进程和用户线程之间1:N的关系称为一对多的线程模型。如图。

使用用户线程的优势在于不需要内核的支持，劣势也在于没有内核的支持。所有线程操作都需要用户程序自己处理。

1.3、使用用户线程加轻量级进程混合实现

在这种混合模式下，用户线程还是完全建立在用户空间，操作系统提供支持的轻量级进程则作为用户线程，和内核线程之间的桥梁，这样可以使用内核提供的线程调度功能及处理器映射，并且用户线程的系统调用要通过轻量级线程来完成，大大降低了整个进程被完全阻塞的风险。这种混合模式中，用户线程和轻量级进程的数量比是不确定的，即为N:M的关系。如图。

1.4、Java线程的实现

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

2、Java线程调度

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

• 抢占式线程调度(Preemptive Threads-Scheduling)：每个线程由系统来分配执行时间，线程的切换不由线程本身决定(在Java中，Thread.yield()可以让出执行时间，但是要获得执行时间的话，线程本身是没有什么办法的)。在这种实现线程调度的方式下，线程的执行时间是系统可控的，也不会有一个线程导致整个进程阻塞的问题，Java使用的线程调度方式就是抢占式调度。

  虽然Java线程调度是系统自动完成的，但是我们还是可以“建议”系统给某些线程多分配一些时间，另外一些线程则可以少分配一些——这项操作可以通过设置线程优先级来完成。Java语言一共设置了10个级别的线程优先级(Thread.MIN_PROPRITY至Thread.MAX_PROPRITY)，在两个线程同时处于Ready状态时，优先级越高的线程越容易被系统选择执行。

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

3、状态转换

Java语言定义了5种线程状态：

• 新建(New)：创建后尚未启动的线程处于这种状态。

• 运行(Runable)：Runable包括了操作系统线程状态中的Running和Ready，也就是处于此状态的线程有可能正在执行，也有可能正在等待CPU为它分配执行时间。

• 无限期等待(Waiting)：处于这种状态的线程不会被分配CPU执行时间，他们要等待被其他线程显式地唤醒。以下方法会让线程陷入无限期的等待状态：

  • 没有设置Timeout参数的Object.wait()方法。
  • 没有设置Timeout参数的Object.join()方法。
  • LockSupport.park()方法。

• 限期等待(Timed Waiting)：处于这种状态的线程也不会被分配CPU执行时间，不过无须等待被其他线程显式地唤醒，在一定时间之后他们会由系统自动唤醒。以下方法会让线程进入限期等待状态：

  • Thread.sleep()方法。

    • 设置了Timeout参数的Object.wait()方法。
    • 设置了Timeout参数的Object.join()方法。
    • LockSupport.parkNanos()方法。
    • LockSupport.parkUntil()方法。

• 阻塞(Blocked)：线程被阻塞，“阻塞状态”与“等待状态”的区别是：“阻塞状态”在等待着获取到一个排它锁，这个事件将在另外一个线程放弃这个锁的时候发送；而“等待状态”则是在等待一段时间，或者唤醒动作的发生。在程序等待进入同步区域的时候，线程将进入这种状态。

• 结束(Terminated)：已终止线程的线程状态，线程已经结束执行。

---

该文章来源《深入理解Java虚拟机》

---

以上