Java 内存模型

happen-before 规则介绍

Java 语言中有一个“先行发生”(happen-before)的规则,它是Java内存模型中定义的两项操作之间的关系,如果操作A先行发生于B,其意思就是说,在发生操作B之前,操作A产生的影响都能被操作B观察到,“影响”包括修改了内存中的共享变量的值、发送了消息、调用了方法等,它与时间的先后发生基本没有太大关系。z合格原则特别重要,它是判断数据是否存在竞争、线程是否安全的重要以及。

举个栗子,假设存在如下三个线程,分别执行对应的操作:

  • 线程A中执行如下操作:i=1
  • 线程B中执行如下操作:j=i
  • 线程C中执行如下操作:i=2

假设线程A中的操作“i=1”happen-before线程B中的操作“j=i”,那么久可以保证线程B的操作执行后,变量j的值一定为1,即线程B观察到了线程A中的操作“i=1”所产生的影响;现在,我们依然保持线程A和线程B之间的happen-before关系,同时线程C出现在了线程A和线程B的操作之间,但是C和B并没有happen-before关系,那么j的值就不确定了,线程C对变量i的影响可能会被线程B观察到,也可能不会,这时线程B就存在读取到不是最新数据的风险,不具备线程安全性。

下面是Java内存模型中的八条可保证happen-before的规则,它们无需任何同步器协助就已经存在,可以在编码中直接使用。如果两个操作之间的关系不在此列,并且无法从下列规则推导出来的话,它们就没有顺序性保障,虚拟机可以对它们进行随机的重排序。

  • 程序次序规则:在一个单独的线程中,按照程序代码的执行流顺序,(时间上)先执行的操作happen-before(时间上)后执行的操作。
  • 管理锁定规则:一个unlock操作happen-before后面(时间上的先后顺序,下同)对同一个锁的lock操作。
  • volatile变量规则:对一个volatile变量的写操作happen-before后面对改变量的读操作。
  • 线程启动规则:Thread对象的start()方法happen-before此线程的每一个动作。
  • 线程终止规则:线程所有的操作都happen-before对此线程的终止检测,可以通过Thread.join()方法结束Thread.isAlive()的返回值等手段检测到线程已经终止执行。
  • 线程中断规则:对线程interrupt()方法调用happen-before发生于被中断线程的代码检测到中断时事件的发生。
  • 对象终结规则:一个对象的初始化完成(构造函数执行结束)happen-before它的finalize()方法的开始。
  • 传递性:如果操作A happen-before 操作B,操作B happen-before 操作C,那么可以得出A happen-before 操作C

时间上先后顺序和happen-before原则

“时间上执行的先后顺序”与“happen-before”之间有何不同呢?
首先来看操作A在时间上先于操作B发生,是否意味着操作A happen-before 操作B?
一个常用来分析的例子如下:

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

public int get(){
return value;
}

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

假设存在线程A和线程B,线程A先(时间上的先)调用了setValue(3)操作,然后(时间上的后)线程B调用了同一对象的getValue()方法,那么线程B得到的返回值一定是3吗?

对照以上八条happen-before规则,发现没有一条规则适合这里的value变量,从而我们可以判断线程A中的setValue(3)操作与线程B中的getValue()操作不存在happen-before关系。因此,尽管线程A的setValue(3)在操作时间上预先于操作B的getValue(),但无法保证线程B的getValue()操作一定观察到了线程A的setValue(3)操作所产生的结果,也就是getValue()的返回值不一定为3(有可能是之前setValue所设置的值)。这里的操作不是线程安全的。

因此,“一个操作时间上先发生于另一个操作”并不代表“一个操作happen-before另一个操作”。

解决方法:可以将setValue(int)方法和getValue()方法均定义为synchronized方法,也可以把value定义为volatile变量(value的修改并不依赖value的原始值,符合volatile的使用场景),分别对应happen-before规则的第2和第3条。注意,只将setValue(int)方法和getValue方法中的一个定义为synchronized方法是不行,必须对同一个变量的所有读写同步,才能保证不读取到陈旧的数据,仅仅同步读或写是不够的。

其次来看,操作A happen-before 操作B,是否意味着操作A在时间上先与操作B发生?

看有如下代码:

1
2
x=1;
y=2;

假设同一个线程执行上面的两个操作:操作A:x=1 和操作B:y=2。根据happen-before 规则的第1条,操作A happen-before 操作B,但是由于编译器的指令重新排序(Java 语言规范规定了JVM线程内部维持顺序化语义,也就是说只要程序最终结果等同于它在严格的顺序化环境下的结果,那么指令的执行顺序就可能与代码的顺序不一致。这个过程通过叫做指令的重排序.指令重排序存在的意义在于:JVM能够根据处理器的特性“CPU的多级缓存系统,多核处理器等”适当的重新排序机器指令,使机器指令更符合CPU的执行特点,最大限度的发挥机器的性能。在没有同步的情况下编译器、处理器以及运行时等都可能对操作的执行顺序进行一些意想不到的调整)等原因,操作A在时间上有可能后与操作B被处理器执行,但这并不影响happen-before原则的正确性。

因此,“一个操作happen-before另一个操作”并不代表“一个操作时间上先发生于另一个操作”。

最后,一个操作和另一个操作必定存在某个顺序,要么一个操作或者是先于后一个操作,或者与两个操作同时发生。同时发生时完全有可能存在的,特别是在多CPU的情况下。而两个操作之间却可能没有happen-before关系,也就是说有可能发生这样的情况,操作A不happen-before操作B,操作B也不happen-before操作A,用数学上的术语happen-before关系是个偏序关系。两个存在happen-before关系的操作不可能同时发生,一个操作A happen-before操作B,它们必定在时间上市完全错开的,这实际上也是同步语义之一(独占访问)。

利用happen-before 规则分析 DCL

DCL 即双重检查加锁,下面是一个典型额单例模式中使用DCL的例子:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
public class LazySingleton {  
private int someField;

private static LazySingleton instance;

private LazySingleton() {
this.someField = new Random().nextInt(200)+1; // (1)
}

public static LazySingleton getInstance() {
if (instance == null) { // (2)
synchronized(LazySingleton.class) { // (3)
if (instance == null) { // (4)
instance = new LazySingleton(); // (5)
}
}
}
return instance; // (6)
}

public int getSomeField() {
return this.someField; // (7)
}
}

这里得到单一的instance实例是没有问题的。问题的关键在于尽管得了Singleton的正确引用,但是却有可能访问到其成员变量的不正确值。具体来说Singleton.getInstance().getSomeField()有可能返回someField的默认值0。如果程序行为正确的话,这应当时不可能发生的事,因为构造函数里设置的someField的值不可能为0。为了说明这种情况理论上有可能发生,我们只需要说明语句(1)和语句(7)并不存在happen-before关系。

假设线程A是初次调用getInstance()方法,紧接着线程B也调用了getInstance()方法和getSomeField()方法,我们要说明的是线程A的语句(1)并不happen-before线程B的语句(7)。线程B在执行getInstance()方法的语句(2)时,由于对instance的访问并没有处于同步块中,因此线程B可能观察到也可能观察不到线程A在语句(5)时对instance的写入,也就是说instance的值可能为空也可能非空。我们先假设instance的值非空,也就观察到了线程A对instance的写入,这时线程B就会执行语句(6)直接返回这个instance的值,然后对这个instance调用getSomeField()方法,该方法也是在没有任何同步情况下被调用,因此整个线程B操作都是在没有同步的情况下调用,这时我们便无法利用上述8条happen-before规则得到线程A的操作和线程B的操作之间的任何有效的happen-before关系(主要考虑规则的第2条,但由于线程B没有在进入synchronized块,因此不存在lock与unlock锁的问题),这说明线程A的语句(1)和线程B的语句(7)之间不存在happen-before关系,这就意味着线程B在执行语句(7)完全有可能观测不到线程A在语句(1)处对somefield写入的值,这就是DCL的问题所在。很荒谬,是吧?DCL原本是为了逃避同步,他达到了这个目的,也正因为如此,它最终受到了惩罚,这样的程序存在严重的bug,虽然这种bug被发现的概率绝对比中彩票的概率还要低得多,而且瞬间即逝,更可怕的是,即使发生了你也不会想到是DCL所引起的。

前面我们说了,线程B在执行语句(2)时也有可能观察到空值,如果是这种情况,那么它需要进入同步块,并执行语句(4)。在语句(4)处线程B还能够读到instance的空值吗?是不可能,这里因为这时对instance的读写都是发生在同一个锁定的同步块中。这时读到的数据是最新数据。为了加深印象,我再用happen-before规则分析一遍。线程B在语句(3)处会执行一个lock操作,而线程A在语句(5)后会执行unlock操作,这两个操作都是针对同一个锁–Singleton.class,因此根据第2条happen-before规则,线程A的unlock操作happen-before线程B的lock操作,在利用单线程规则,线程A的语句(5)->线程A的unlock操作,线程B的lock操作->线程B的语句(4),在根据传递规则,就有线程A的语句(5)->线程B的语句(4),也就是说线程B在执行语句(4)的时候能观察到线程A在语句(5)时对Singleton的写入值。接着对返回的instance调用getSomeField()方法时,我们也能得到线程A的语句(1)->线程B的语句(7)(由于线程B有进入synchronized块,根据规则2可得),这表明这个时getSomeField()能够得到正确的值。但是仅仅是这种情况的正确性并不妨碍DCL的不正确性,一个程序的正确性必须在所有情况下的行为都是正确的,而不能有时正确,有时不正确。

对DCL的分析也告诉我们一条经验原则:对引用(包括对象引用和数组引用)的非同步访问,即使得到该引用的最新值,却并不能保证也能得到其成员变量(对数组而言就是每个数组元素)的最新值。

解决方案

最简单而且安全的解决方法是使用static内部类的思想,它利用的思想是:一个类直到被使用时才被初始化,而类初始化过程是非并行的,这些都有JLS(java语言规范)保证。

如下代码:

public class Singleton {  

  private Singleton() {}  

  // Lazy initialization holder class idiom for static fields  
  private static class InstanceHolder {  
   private static final Singleton instance = new Singleton();  
  }  

  public static Singleton getSingleton() {   
    return InstanceHolder.instance;   
  }  
}

另外,可以将instance声明为volatile,即
private volatile static LazySingleton instance;
这样我们便可以得到,线程A的语句(5)->线程B的语句(2),根据单线程规则,线程A的语句(1)->线程A的语句(5)和线程B的语句(2)->线程B的语句(7),再根据传递规则就有线程A的语句(1)->线程B的语句(7),这表示线程B能观察到线程A在语句(1)时对somefiled的写入值,程序能够得到正确的行为。

注:
1.volatile屏蔽指令重排序的语义在JDK1.5中财被完全修复,此前的JDK中即使变量声明为volatile,也仍然不能完全避免重排序所导致的问题(主要是volatile变量前后的代码仍然存在重排序问题),这点也是在JDK1.5之前的Java中无法安全的使用DCL来实现单例模式的原因。

2.把volatile写和volatile读这两个操作综合起来看,在线程B读一个volatile变量后,写线程A在写这个volatile变量之前,所有可见的共享变量值都将立即变得对读线程B可见。

3.在 java5 之前对 final 字段的同步语义和其它变量没有什么区别,在 java5 中,final 变量一旦在构造函数中设置完成(前提是在构造函数中没有泄露 this 引用),其它线程必定会看到在构造函数中设置的值。而 DCL 的问题正好在于看到对象的成员变量的默认值,因此我们可以将 LazySingleton的someField 变量设置成 final,这样在 java5 中就能够正确运行了。

主内存与工作内存

Java 内存模型主要目的是定义程序中各个变量访问规则,即在虚拟机中变量存储到内存和从内存中取出变量这样的底层细节。此处变量主要是指内存共享变量,存在竞争问题的变量。Java内存模型规定变量都存储在主内存中,而每条线程还有自己的工作内存,线程的工作内存中保存了该线程使用到变量的主内存副本拷贝,线程对变量的所有操作(读取,赋值等)都必须在工作内存中进行,而不能直接读写主内存中变量(根据Java虚拟机规范规定,volatile变量依然有共享内存拷贝,但是由于它特殊的操作顺序规定–从工作内存中读写数据前,必须先将内存中的数据同步到工作内存中,所有看起来如同直接在主内存读写访问一般,因此这里的描述对于volatile也不例外)。不同线程之间也无法直接访问对方工作内存中的变量,线程间变量值得传递均需要通过主内存完成。

内存间交互操作

Java 内存模型中定义了以下8种操作来完成主内存与工作内存之间交互的实现细节:

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

Java 内存模型还规定了执行上述8种基本操作时必须满足如下规则:

  • 不允许(read和load)、(store和write)操作之一单独出现,以上两个操作必须按顺序执行,但没有保证必须连续执行,也就是说,(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操作)。

volatile型变量的特殊规则
Java 内存模型对volatile专门定义了一写特殊的访问规则,当一个变量被定义成volatile之后,他将具备两种特性:

  • 保证此变量对所有线程的可见性。这里不具体解释了。需要注意,volatile变量的写操作除了对它本身读操作可见外,volatile写操作之前的所有共享变量均对volatile读操作之后可见,另外注意其适用场景。
  • 禁止指令重排序优化。普通的变量仅仅会保证在该方法的执行过程中所有依赖赋值结果的地方都能获得正确的结果,而不能保证变量赋值操作的顺序与程序中的执行顺序一致,在单线程中,我们是无法感知这一点的。
  • 补充:Java语言规范规定了JVM线程内部维持顺序化语义,也就是说只要程序的最终结果等同于它在严格顺序化环境下的结果,那么指令的执行顺序就可能与代码的顺序不一致,这个过程通过叫做指令的重排序。指令重排序存在的意义在于:JVM 能够根据处理器的特性(CPU 的多级缓存系统、多核处理器等)适当的重新排序机器指令,使机器指令更符合 CPU 的执行特点,最大限度的发挥机器的性能。在没有同步的情况下,编译器、处理器以及运行时等都可能对操作的执行顺序进行一些意想不到的调整。

final域
final类型的域是不能被修改的,除了这一点外,在Java内存模型中,final域还有着特殊的语义,final域能确保初始化过程的安全性,从而可以不受限制地访问不可变对象,并在共享这些对象时无需同步。具体而言,就是被final修饰的字段在构造器中一旦被初始化完成,并且构造器没有把“this”的引用传递出去(this引用逃逸是一件很危险的事情,其他线程可能通过这个引用访问到“初始化了一半”的对象),那么在其他线程中就能看到final字段的值,而且其外,外部可见状态永远也不会改变。它所带来的安全性是最简单最纯粹的。

long和double型变量的特殊规则
Java 内存模型要求lock、unlock、read、load、assign、use、store和write这8个操作都具有原子性,但是对于64位数据类型long和double,在模型中特别定义了一条宽松的规定:允许虚拟机将没有被volatile修饰的64位数据的读写操作划分为两次32位的操作来进行。这样,如果有多个线程共享一个未被声明为volatile的long或double类型的变量,并且同时对它们进行读取和修改操作,那么某些线程可能会读到一个既非原值,也非其他线程修改的代表了“半个变量”的数值。不过这种读取到“半个变量”的情况非常罕见,因为Java内存模型虽然允许虚拟机不把long和double变量的读写实现原子操作,但允许虚拟机选择把这些操作实现为具有原子性的操作,而且还“强烈建议”虚拟机这样实现。目前各个平台下的商用虚拟机几乎都选择把 64 位数据的读写操作作为原子操作来对待,因此在编码时,不需要将 long 和 double 变量专门声明为 volatile。

文章目录
  1. 1. happen-before 规则介绍
  2. 2. 时间上先后顺序和happen-before原则
  3. 3. 利用happen-before 规则分析 DCL
  4. 4. 解决方案
  5. 5. 主内存与工作内存
  6. 6. 内存间交互操作
|