0%

JVM11-Java内存模型与线程

「内存模型」可以理解为在特定的操作协议下,对特定的内存或高速缓存进行读写访问的过程抽象。

Java内存模型

Java虚拟机规范中试图定义一种Java内存模型来屏蔽掉各种硬件和操作系统内存访问差异,以实现让Java程序在各种平台下都能达到一致的内存访问效果。在此之前,主流程序语言(如C/C++等)直接使用物理硬件和操作系统的内存模型,因此,会由于不同平台上内存模型的差异,有可能导致程序在一套平台上并发完全正常,而在另外一台平台上并发访问却经常出错,因此在某些场景就必须针对不同的平台来编写程序。

主内存与工作内存

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

Java内存模型规定了所有的变量都存储在主内存中,每条线程还有自己的私有工作内存,线程的工作内存中保存了被该线程使用到的变量的主内存副本拷贝,线程对变量的所有操作都必须在工作内存中进行。不同的线程之间也无法直接访问对方工作内存中的变量,线程间变量值的传递均需要通过主内存来完成。(这很好的诠释了volatile关键字的作用和原理)

内存间交互操作

Java内存模型中定义了以下8种操作来完成,虚拟机实现时必须保证下面提及的每一种操作都是原子的、不可再分的

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

如果要把变量从主内存复制到工作内存,那就要顺序执行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操作之前,必须先把此变量同步回主内存中(执行store、write操作)。

这8种内存访问操作以及上述规则的限定,再加上下面讲的对volatile的一些特殊规定,就已经完全确定了Java程序中哪些内存访问操作在并发下是安全的。

对于volatile型变量的特殊规则

关键字volatile可以说是Java虚拟机提供的最轻量级的同步机制,我们需要正确的理解并使用它。

当一个变量定义为volatile之后,它将具备两种特性:

1.保证此变量对所有线程的可见性,这里的「可见性」是指当一条线程修改了这个变量的值,,新值对于其他线程来说是可以立即得知的。而普通变量做不到这一点,普通变量的值在线程间传递均需要通过主内存来完成,例如线程A修改一个普通变量的值,然后向主内存进行回写,另外一条线程B在线程A回写完成了之后再从主内存进行读取操作,新变量值才会对线程B可见。
Java里面的运算并非原子操作,导致volatile变量在并发下一样是不安全的,看一段例子:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

/**
* Created by YangFan on 2016/11/25 上午11:05.
* <p/>
* 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 j = 0; j < 10000; j++) {
increase();
}
}
});
threads[i].start();
}

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

System.out.println(race);


}
}

这个结果每次可能都不一样,因为“race++”在虚拟机内部被分解成了很多指令,不同线程在自增的时候,这个值拿到的可能是过期的数据。

由于volatile变量值能保证可见性,在不符合以下两条规则的运算场景中,我们仍然要通过加锁来保证原子性。

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

下面的场景就很适用:

1
2
3
4
5
6
7
8
9
10
11
volatile boolean shutdownRequested;

public void shutdown() {
shutdownRequested = true;
}

public void doWork() {
while(!shutdownRequested) {
// do stuff
}
}

2.使用volatile变量的第二个语义是禁止指令重排序优化,普通变量仅仅会保证在该方法的执行过程中所有依赖赋值结果的地方都能获取到正确的结果,而不能保证变量赋值操作的顺序与程序代码中的执行顺序一致。我们通过一个例子来看看为何指令重排序会干扰程序的并发执行。

指令重排序优化是指为了使得处理内部的运算单元能尽量被充分利用,处理器可能会对输入代码进行乱序执行优化,处理器会再计算之后将乱序执行的结果重组,保证该结果与顺序执行的结果是一致的,因此如果存在一个计算任务依赖另外一个计算任务的中间结果,那么其顺序性并不能靠代码的先后顺序来保证。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Map condigOptions;
char[] configText;
// 此变量必须定义为volatile
volatile boolean initialized = false;
// 假设以下代码在线程A中执行
// 模拟读取信息配置,当读取完成后将initialized设置为true以通知其他线程配置可用
configOptions = new HashMap();
configText = readConfigFile(fileName);
processConfigOptions(configText, configOptions);
initialized = true;

// 假设以下代码在线程B中执行
// 等待initialized为true,代表线程A已经把配置信息初始化完成
while (!initialized) {
sleep();
}

// 使用线程A中初始化好的配置信息
doSomethingWihtConfig();

上面的代码如果有定义initialized变量时没有使用volatile修饰,就可能会由于指令重排序的优化,导致位于线程A中最后一句的代码“initialized = true;”被提前执行(重排序优化是机器级的优化操作,提前执行是说这句话对应的汇编代码被提前),这样在线程B中的代码可能就会出错。

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

因为double和long是64位数据,内存模型允许虚拟机将没有被volatile修饰的64位数据的读写操作划分为两次32为的操作来进行,即允许虚拟机实现选择可以不保证64位数据类型的load、store、read和write这4个操作的原子性。

如果有多个线程共享一个并未声明为volatile的long或double类型的变量,并且同时对它们进行读取和修改操作,那么某些线程可能会读取到一个既非原值,也不是其他线程修改的值代表了「半个变量」的数值。不过这很罕见,因为目前的商用虚拟机几乎都还是选择把64位数据的读写作为原子操作来对待,所以我们写代码一般也不需要对long和double变量专门声明为volatile。

原子性、可见性与有序性

Java内存模型是围绕着在并发过程中如何处理原子性、可见性和有序性这3个特征来建立的。

  • 原子性
    由Java内存模型来直接保证的原子性变量操作包括read、load、assign、use、store和write,我们大致可以认为基本数据类型的访问读写是具备原子性的(例外就是long和double的非原子性协定,不过也无须太在意这几乎不会发生的例外情况。)
    如果还需要更大范围的原子性保证,Java内存模型还提供了lock和unlock操作,也就是synchronized关键字。
  • 可见性
    可见性是指当一个线程修改了共享变量的值,其他线程能够立即得知这个修改。Java内存模型是通过在变量修改后将新值同步回主内存,在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介来实现可见性的,无论是普通变量还是volatile变量都是如此,普通变量与volatile变量的区别是,volatile的特殊规则保证了新值能立即同步到主内存,以及每次使用前立即从主内存刷新。因此,可以说volatile保证了多线程时操作变量的可见性,而普通变量则不能保证这一点。
    synchronized和final关键字也能实现可见性,synchronized的可见性是由「对一个变量执行unlock操作之前,必须先把此变量同步回主内存中」这条规则获得的。另外,final关键字也可以实现可见性,因为被final修饰的字段在构造器中一旦初始化完成,并且构造器没有把this传递出去,那在其他线程中就能看见final字段的值。
  • 有序性
    Java内存模型的有序性可以总结为一句话,如果在本线程内观察,所有的操作都是有序的;如果在一个线程中观察另一个线程,所有的操作都是无序的。前半句是指「线程内表现为串行的语义」,后半句是指「指令重排序」现象和「工作内存与主内存同步延迟」现象。
    Java语言提供了volatile和synchronized两个关键字来保证线程之间操作的有序性,volatile关键字本身就包含了禁止指令重排序的语义,而synchronized则是由”一个变量在同一时刻只允许一条线程对其进行lock操作”这条规则获得的,这条规则规定了持有同一个锁的两个同步块只能串行地进入。

先行发生原则

如果Java内存模型中所有的有序性都仅仅靠volatile和synchronized来完成,那么好像有一些操作将会变得很繁琐,但是我们在编写Java并发代码的时候并没有感觉到这一点,这是因为Java语言中有一个「先行发生」的原则。这个原则非常重要,它是判断数据是否存在竞争、线程是否安全的主要依据,依靠这个原则,我们可以通过几条规则一揽子地解决并发环境下两个操作之间是否可能存在冲突的所有问题。

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

Java内存模型有有些天然的先行发生关系,这些先行发生关系无须任何同步器协助就已经存在,可以在编码中直接使用。如果两个操作之间的关系不在此列,并且无法从下列规则推导出来的话,它们就没有顺序行保障,虚拟机可以对它们随意地进行重排序。

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

Java语言无须任何同步手段保障就能成立的先行发生规则就只有上面这些。下面演示如何用这些规则来判定操作间是否具备顺序性

1
2
3
4
5
6
7
8
9
10
11
private int value = 0;

public void setValue(int value)
{
this.value = value;
}

public int getValue()
{
return value;
}

这是很普通的getter/setter方法,假设存在线程A和B,线程A先(时间上的先后)调用了“setValue(1)”,然后线程B调用了同一个对象的“getValue()”,那么线程B的返回值是什么?
我们根据规则来分析一下:由于两个方法分别由线程A和线程B调用,不在一个线程中,所以程序次序规则不适用;由于没有同步块,就没有lock和unlock操作,所以管程锁定规则不适用;由于value变量没有被volatile关键字修饰,所以volatile变量规则不适用;后面的线程启动、终止、中断规则和对象终结规则也和这里完全没有关系。因为没有一个使用的先行发生规则,所以最后一条传递性也无从谈起。因此可以判定尽管线程A在操作时间上先于线程B,但是无法确定线程B中的“getValue()”方法的返回结果,换句话说,这里面的操作不是线程安全的

那如何修复这个问题?至少有两种比较简单的方案:

  1. setter/getter都定义成synchronized的,这样可以套用管程锁定规则
  2. value定义为volatile变量,由于setter方法对value的修改不依赖于value的原值,满足volatile关键字的使用场景,这样可以套用volatile变量规则

我们也得出一个结论:时间先后顺序与先行发生原则之间基本没有太大的关系,所以我们衡量并发安全问题的时候不要受到时间顺序的干扰,一切必须以先行发生原则为准。

Java与线程

线程的实现

Java的线程API基本都是Native方法,意味着这个方法没有使用或无法使用平台无关的手段来实现。实现线程有3种方式:使用内核线程实现、使用用户线程实现和使用用户线程加轻量级进程混合实现。

  1. 使用内核线程实现
    内核线程就是直接由操作系统支持的线程,这种线程由内核来完成线程切换,内核通过操纵调度器对线程进行调度,并负责将线程的任务映射到各个处理器上。不过程序一般不会直接去使用内核线程,而是使用内核线程的一种高级接口–轻量级进程。这种方式系统调用代价较高,并且因为消耗内核资源,所以轻量级进程数量有限。轻量级进程与内核线程之间是1:1的关系。

  2. 使用用户线程实现
    从广义上来讲,一个线程只要不是内核线程,就可以认为是用户线程。而狭义上的用户线程指的是完全建立在用户空间的线程库上,系统内核不能感知线程存在的实现。用户线程的建立、同步、销毁和调度完全在用户态中完成,不需要内核的帮助。这种方式的操作可以是非常快速且低消耗的,劣势在于没有系统内核支持,实现起来非常的复杂。Java和Ruby都曾经使用过用户线程,最终又都放弃使用它。进程与用户线程之间是1:N的关系。

  3. 使用用户线程加轻量级进程混合实现
    线程除了依赖内核线程实现和完全由用户程序自己实现之外,还有一种将内核线程与用户线程一起使用的实现方式。在这种混合实现下,既存在用户线程,也存在轻量级进程。因此用户线程的创建、切换、析构等操作依然廉价,并且可以支持大规模的用户线程并发。而轻量级进程则作为用户线程和内核线程之间的桥梁,这样可以使用内核提供的线程调度功能及处理器映射,并且用户线程的系统调用要通过轻量级进程来完成,大大降低了整个进城被完全阻塞的风险。用户线程与轻量级进程之间是N:M的关系。

  4. Java线程的实现
    1.2之前是用户线程实现的,1.2开始替换为基于操作系统原生线程模型来实现。因此在目前的JDK版本中,操作系统支持怎样的线程模型,很大程度上决定了Java虚拟机的线程是怎样映射的。对Sun JDK来说,它的Windows版和linux版都是使用一对一的线程模型实现的,一条Java线程就映射到一条轻量级进程之中,因为windows和Linux系统提供的线程模型就是一对一的。

Java线程调度

线程调度是指系统为线程分配处理器使用权的过程,主要调度方式有两种,分别是协同式线程调度和抢占式线程调度。

协同式调度,线程的执行时间由线程本身来控制,线程把自己的工作执行完了之后,要主动通知切换到另外一个线程上。好处是实现简单,干完自己的事情后进行线程切换,没有什么同步问题,坏处是一旦程序出问题,将会阻塞下去。

抢占式调度的多线程系统,每个线程将由系统来分配执行时间,线程的切换不由线程本身来决定。这种实现线程调度的方式下,线程的执行时间是系统可控的,不会出现什么阻塞问题。

线程状态

线程有5种状态

  • 新建:创建后尚未启动的线程处于这种状态
  • 运行:Runable包括了操作系统线程状态中的Running和Ready,也就是处于此状态的线程有可能正在执行,也有可能正在等待着CPU为他分配执行时间。
  • 无限期等待:处于这种状态的线程不宜被分配CPU执行时间,她们要等待被其他线程显式的唤醒。以下方法会让线程陷入无限期的等待状态:
    • 没有设置Timeout参数的Object.wait()方法
    • 没有设置Timeout参数的Thread.join()方法
    • LockSupport.park()方法
  • 限期等待:处于这种状态的线程也不会被分配CPU执行时间,不过无须等待被其他线程显式地唤醒,在已定时间之后它们会由系统自动唤醒。以下方法会让线程进入限期等待状态:
    • Thread.sleep()方法。
    • 设置了Timeout参数的Object.wait()方法。
    • 设置了Timeout参数的Thread.join()方法。
    • LockSupport.parkNanos()方法。
    • LockSupport.parkUntil()方法
  • 阻塞:线程被阻塞了,「阻塞状态」与「等待状态」的区别是:「阻塞状态」在等待着获取一个到一个排他锁,这个时间将在另外一个线程放弃这个锁的时候发生;而「等待状态」则是等待一段时间,或者唤醒动作的发生。在程序等待进入同步区域的时候,线程将进入这种状态。
  • 结束:已终止线程的线程状态,线程已经结束执行。