jdk源码解析(十一)——Java内存模型与线程

前面我们了解了Java的编译和运行,这里在讲解一下高效并发(Java内存模型与线程)在了解内存模型与线程之前,我们先要了解一些东西。

1 硬件效率与一致性 

计算并发运行的运行和充分利用计算机处理器的效能两者看来是互为因果的,而在大多数的时候,计算机的处理速度不止是在处理器进行的,大多数是在内存和处理器进行的,但是这种I/O操作是很难消除的。为了提升计算速度,在内存和处理器之间加上一个高速缓存来作为内存和处理器之间的缓冲。基于高速缓存的方法很好的解决了处理器和缓存的矛盾,但是也引入了一个新的问题:缓存一致性。每个处理器都有自己的高速缓存,而他们又共享一个主内存。当处理多个处理器的运算任务都涉及同一个主内存区域时,将可能导致各自的缓存数据不一致,如果真发生这种情况,将同步到主内存的数据到底以谁的缓存数据为准。为了解决一致性问题,需要各个处理器访问缓存时都遵循一些协议,在读写时根据协议进行操作,这类协议有MSI 、MESI(Illionis Protocol)、MOSI、Synapse、Firefly及Dragon Protocol等。在本章中将会多次提到“内存模型”一词,可以理解为在特定的操作协议下,对特定的内存或高速缓存进行读写访问的过程抽象。

《jdk源码解析(十一)——Java内存模型与线程》

  除了增加高速缓存之外,为了使得处理器内部的运算单元尽可能被充分利用,处理器可能会对输入代码进行乱序执行优化,处理器会在计算之后将乱序执行的结果重组,保证该结果与顺序执行的结果是一致的,但并不保证程序中各个语句计算的先后顺序与代码中的顺序一致。因此,如果某个人物依赖另外一个人物的中间结果,但执行顺序出现了问题,所以结果会出现了问题。Java虚拟机的即时编译器中也有类似的指令重排序优化。

2. Java内存模型

Jvava虚拟机规范中试图定义一种Java内存模型来屏蔽掉各种硬件和操作系统的内存差异,来实现Java程序在各种平台下都能达到一致的内存访问效果。

2.1 主内存与工作内存

Java内存模型的主要目标:定义程序中各个变量的访问规则,即在虚拟机中将变量存储到内存和从内存中取出变量这样的底层细节。注意,此处的变量与Java编程语言中所说的变量有所区别,它包括实例字段、静态字段和构成数组对象的元素,但不包括局部变量与方法参数,因为后者是线程私有的,不会被共享,自然就不会存在竞争问题。
为了获取较好的执行效能,Java内存模型并没有限制执行引擎使用处理器的特定寄存器或缓存来和主内存进行交互,也没有限制即时编译器进行调整代码执行顺序这类优化操作。
Java内存模型规定了所有的变量都存储在主内存中,此处的主内存仅仅是虚拟机内存的一部分,而虚拟机内存也仅仅是计算机物理内存的一部分(为虚拟机进程分配的那一部分)。
每条线程还有自己的工作内存,线程的工作内存中保存了被该线程使用到的变量的主内存副本拷贝。线程对变量的所有操作(读取、赋值),都必须在工作内存中进行,而不能直接读写主内存中的变量。不同线程之间也无法直接访问对方工作内存中的变量,线程间变量值的传递均需要通过主内存来完成,线程、主内存、工作内存三者之间的交互关系如下图:

《jdk源码解析(十一)——Java内存模型与线程》

注:这里所讲的主内存、工作内存与Java内存区域中的Java堆、栈、方法区等并不是同一个层次的内存划分。
主内存主要对应java堆中的对象实例数据部分,而工作内存则对应于虚拟机栈中的部分数据。从更低层次上说,主内存就直接对应于物理硬件的内存。
为了获取更好的运行速度,虚拟机可能会让工作内存优先存储于寄存器和高速缓存中,因为程序运行时主要访问读写的是工作内存。

2.2 内存间的交互操作

关于主内存与工作内存之间具体的交互协议,即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步回主内存等的细节,Java内存模型定义了8种操作来完成,虚拟机实现时必须保证下面提及的每一种操作都是原子操作(不可在分的)。

lock(锁定):作用于主内存的变量,它把一个变量标志为一条线程独占的状态。
unlock(解锁):作用于主内存中的变量,它把一个处于锁定状态的变量释放出来,释放后的变量才可以被其他线程锁定。
read(读取):作用于主内存的变量,它把一个变量的值从主内存传输到线程的工作内存中,以便随后的load动作使用。
load(载入):作用于工作内存的变量,它把read操作从主内存中得到的变量值放入工作内存的变量副本中。
use(使用):作用于工作内存的变量,它把工作内存中一个变量的值传递给执行引擎。
assign(赋值):作用于工作内存的变量,它把一个从执行引擎接受到的值赋给工作内存的变量。
store(存储):作用于工作内存的变量,它把工作内存中一个变量的值传送到主内存中,以便随后的write操作使用。
write(写入):作用于主内存中的变量,它把store操作从主内存中得到的变量值放入主内存的变量中。

《jdk源码解析(十一)——Java内存模型与线程》

除了保证上述8种操作的原子性,Java内存模型还规定了在执行上述8种基本操作时必须遵循的规范,从而完全确定Java程序中那些内存访问操作在并发下是安全的。

如果要把一个变量从主内存复制到工作内存,那就要顺序地执行read和load操作,如果要把变量从工作内存同步回主内存,就要顺序地执行store和write操作。这两组操作都只需要顺序执行而不必连续。除此之外,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操作之前,必须先把此变量同步回主内存中(只是sotore、write操作)。

2.3  对于volatile(关键字)型变量的特殊规则

关键字volatile是Java虚拟机提供的最轻量级的同步机制,了解volatile变量的语义对后面了解多线程操作的其它特性很有意义。首先,我们来了解一下这个关键字的作用。
当一个变量定义为volatile之后,它将具备两种属性,第一种是保证此变量对所有线程的可见性,这里的“可见性”是指当一条线程修改了这个变量的值,新值对于其它线程来说是可以立即得知的。不过,因为Java里面的运算并不是原子操作,所以volatile变量的运算在并发条件下并不是绝对安全的。以下为示例代码:

package com.overridere.twelve;
/**
 * volatile变量自增运算测试
 */
public class VolatileTest {

    public static volatile int race = 0;

    public static void increase() {
        race++;
    }

    private static final int THREADS_COUNT = 20;

    public static void main(String[] args) {
        Thread[] threads = new Thread[THREADS_COUNT];
        for (int i = 0; i < THREADS_COUNT; i++) {
            threads[i] = new Thread(new Runnable() {
                @Override
                public void run() {
                    for (int i = 0; i < 10000; i++) {
                        increase();
                    }
                }
            });
            threads[i].start();
        }

        // 等待所有累加线程都结束
        while (Thread.activeCount() > 1)
            Thread.yield();

        System.out.println(race);
    }
}

这段代码发起了20个线程,每个线程都对变量race进行10000次自增操作,如果race是线程安全的,最后输出结果应该是200000,但真实结果都是一个小于200000的值,这是问为什么呢?

 public static void increase();
    descriptor: ()V
    flags: ACC_PUBLIC, ACC_STATIC
    Code:
      stack=2, locals=0, args_size=0
         0: getstatic     #13                 // Field race:I
         3: iconst_1
         4: iadd
         5: putstatic     #13                 // Field race:I
         8: return
      LineNumberTable:
        line 10: 0
        line 11: 8
      LocalVariableTable:
        Start  Length  Slot  Name   Signature

问题就在“race++”中,用javap命令得到上面的字节码命令,发现只有一行代码的increase()方法在Class文件中是由4条字节码指令构成的,从这上面分析就很容易分析出线程不安全的原因了:当getstatic指令把race的值取到操作数栈顶的时候,volatile关键字保证了race的值在此时是正确的,但是在执行iconst_1、iadd这些指令的时候,其它线程可能已经把race加大了,而操作栈顶的值就变成了过期的数据。意思是说,在这个例子当中,volatile关键字只保证getstatic指令从常量池中将值取出放到操作数栈顶这个动作是线程安全的(从主内存到工作内存),作用范围就是这个,之后就会失去作用,后面的增加操作就不是线程安全的了。

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

第一句话的意思是:不管我以前是什么样的,都不影响现在的我。
第二句话的意思是:不管别人是什么样的,只要跟我没关系,就不会影响到我。
如下面的示例代码:

volatile boolean isVolatile;
public void shutdown(){
    isVolatile = true;
}
public void doWork(){
    while(!isVolatile){
        //do stuff
    }
}

上面代码中的isVolatile变量,无论之前是什么,都不妨碍当前线程赋值,也没有与其它变量绑起来共同参与不变约束。

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

指令重排序意思就是不按程序规定的顺序执行指令,但并不是说指令任意重排。比如说,指令1把地址A中的值加10,指令2把地址A中的值乘以2,指令3把地址B中的值减去3,这时指令1和指令2是有依赖的,它们之间的顺序不能重排——(A+10)*2与A*2+10显然不相等,但是指令3可以重排到指令1、2之前或者中间。

而valotile关键字是如何实现禁止指令重排序呢?

有volatile关键字修饰的变量,赋值后会多执行一个操作,这个操作会把修改同步到内存,意味着所有之前的操作都执行完毕了,这个操作相当于内存屏障(Memory Barrier),这样一来指令重排序的时候就不能把后面的指令重排序到内存屏障之前的位置。只有一个CPU访问内存时,不需要内存屏障。

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

原子性(Atomicity):由Java内存模型来直接保证的原子性变量操作包括read、load、assign、use、和write。

可见性(Visibility):可见性是指当一个线程修改了共享变量的值,其它线程能够立即得知这个修改。Java内存模型是通过在变量修改后将新值同步回主内存,在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介的方式来实现可见性的。volatile变量与普通变量的区别是,volatile的特殊规则保证新值能立即同步到主内存,每次使用前立即从主内存刷新。

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

3 Java与线程

并发不一定依赖多线程(php很常见多进程并发),但是在Java中谈到并发,大多数都与线程脱不开关系,那讲到java线程,我们就从Java线程在虚拟机中的实现开始讲起。

3.1 线程的实现

我们知道,线程是比进程更轻量级的调度执行单位,线程的引入,可以把一个进程的资源分配和执行调度分开,各个线程既可以共享进程资源(内存地址、文件I/O等),又可以独立调度(线程是CPU调度的基本单位)。
主流的操作系统都提供了线程实现,Java语言则提供了在不同硬件和操作系统平台下对线程操作的统一处理,每个已经执行了start()且还未结束的java.lang.Thread类的实例就代表了一个线程。Thread类中所有关键方法都是声明为Native的,在Java API中,本地方法往往意味着这个方法没有使用或无法使用平台无关的手段来实现(当然也有可能是为了执行效率而使用Native方法)。正因如此,本节标题为“线程的实现”而不是“Java线程的实现”
线程的实现主要有3种方式:使用内核线程实现、使用用户线程实现和使用用户线程加轻量级进程混合实现。

1、使用内核线程实现

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

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

《jdk源码解析(十一)——Java内存模型与线程》

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

2、使用用户线程实现

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

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

《jdk源码解析(十一)——Java内存模型与线程》

使用用户线程的优势在于不需要系统内核的支援。劣势也在于没有系统内核的支援,所有的线程操作都需要用户程序自己处理。
线程的创建、切换和调度都是需要考虑的问题,而且由于操作系统只把处理器资源分配到进程,那诸如“阻塞如何处理”、“多处理器系统中如何将线程映射到其他处理器上”这类问题解决起来将会异常困难,甚至不可能完成。因此,使用用户线程实现的程序一般都异常复杂,除了特定环境外,现在使用用户线程的程序越来越少。

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

在这种混合模式下,即存在用户线程,也存在轻量级进程。用户线程还是完全建立在用户空间中,因此用户线程的创建、切换、析构等操作依然廉价,并且可以支持大规模的用户线程并发。而操作系统提供支持的轻量级进程则作为用户线程和内核线程之间的桥梁,这样可以使用内核线程提供的线程调度功能及处理器映射,并且用户线程的系统调用要通过轻量级进程来完成,大大降低了整个进程被完全阻塞的风险。这种混合模式,用户线程与轻量级进程的数量比是不定的,即N:M的关系,也称为多对多的线程模型。

《jdk源码解析(十一)——Java内存模型与线程》

4 Java线程的实现

Java线程在JDK 1.2之前是基于用户线程实现的,而JDK 1.2中,线程模型替换为基于操作系统原生线程来实现。

因此,在目前的JDK版本中,操作系统支持怎样的线程模型,很大程度上决定了Java虚拟机的线程是怎样映射的,这点在不同的平台上没有达成一致,虚拟机规范中也没有限定Java线程需要使用哪种线程模型来实现。

线程模型只是对线程的并发规模和操作成本产生影响,对Java程序的编码和运行来说,这些差异都是透明的。

对于Sun JDK来说,它的Windows版与Linux版都是使用一对一的线程模型实现的,一条Java线程就映射到一条轻量级进程之中,因为Windows和Linux系统提供的线程模型就是一对一的。

3.2 Java线程调度

Java的线程调度方式是抢占式调度,虽然Java线程的调度是系统自动完成的,但是我们还是可以“建议”系统给某些线程多分配一点执行时间,另外的一些线程则可以少分配一点——这项操作可以通过设置优先级来完成。
不过,线程的优先级并不是太靠谱,因为Java线程是通过映射到原生线程上来实现的,所以线程调度最终还是取决于操作系统,虽然现在很多操作系统都提供了优先级的概念,但是并不见得与Java线程的优先级一一对应。例如Windows中就只有7种线程优先级,而Java语言一共设置了10个级别的线程优先级。

《jdk源码解析(十一)——Java内存模型与线程》

3.3 Java线程的状态转化

新建(New):创建后尚未启动的线程处于这种状态。
运行(Runable):Runable包括了操作系统线程状态中的Running和Ready,也就是说处于此种状态的线程可能正在执行,也可能正在等待CPU为它分配执行时间。
无限期等待(Waiting):处于这种状态下的线程不会被分配CPU执行时间,他们要等待被其他线程显示唤醒。
限期等待(Timed Waiting):处于这种状态下的线程也不会被分配CPU执行时间,不过无须等待被其他线程显示唤醒,在一定时间之后它们由系统自动唤醒。
阻塞(Blocked):线程被阻塞了,“阻塞状态”与“等待状态”的区别是:“阻塞状态”在等待着获取一个排他锁,这个事件将在另外一个线程放弃这个锁的时候发生。
结束(Terminate):已经终止的线程的线程状态,线程已经结束执行。

《jdk源码解析(十一)——Java内存模型与线程》

不足之处以后填补。

    原文作者:java内存模型
    原文地址: https://blog.csdn.net/sinat_38259539/article/details/78325805
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞