Java内存模型

主内存与工作内存

Java内存模型规定了所有的变量都存储在主内存中,每条线程还有自己的工作内存,线程的工作内存中保存了被该线程使用到的变量的主内存副本拷贝,线程对变量的所有操作都必须在工作内存中进行,而不能直接读写主内存中的变量。

内存间交互操作

一个变量如何从主内存拷贝到工作内存,如何从工作内存同步回主内存,Java内存模型定义了以下八种操作来完成,虚拟机实现时必须保证下面提及的每一种操作都是原子的、不可再分的:

lock(锁定)作用于主内存的变量,它把一个变量标识为一条线程独占的状态。

unlock(解锁)作用于主内存的变量,它把一个处于锁定状态的变量释放出来,释放后的变量才可以被其他线程锁定。

read(读取)作用于主内存的变量,它把一个变量的值从主内存传输到线程的工作内存中,以便随后的load动作使用。

load(载入)作用于工作内存中的变量,它把read操作从主内存中得到的变量值放入工作内存的变量副本中。

use(使用)作用于工作内存的变量,它把工作内存中一个变量的值传递给执行引擎,每当虚拟机遇到一个需要使用到变量的值的字节码指令时将会执行这个操作。

assign(赋值)作用于工作内存的变量,它把一个从执行引擎接受到的值赋给工作内存的变量,每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作。

store(存储)作用于工作内存的变量,它把工作内存中一个变量的值传送到主内存中,以便随后的write操作使用。

write(写入)作用于主内存的变量,它把store操作从工作内存中得到的变量的值放入主内存的变量中。

volatile型变量的特殊规则

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

第一是保证变量对所有线程的可见性,这里的“可见性”是指一条线程修改了这个变量的值,新值对于其他线程来说是可以立即得知的。而普通变量的值在线程间传递需要通过主内存来完成。

由于volatile变量只能保证可见性,在不符合以下两条规则的运算场景中,我们仍然要通过加锁来保证原子性。
1. 运算结果并不依赖变量的当前值,或者能够确保只有单一的线程修改变量的值。
2. 变量不需要与其他的状态变量共同参与不变约束。

如下面的场景很适合用volatile变量来控制并发:

volatile boolean shutdownRequested;

public void shutdown(){
    shutdownRequested = true;
}

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

使用volatile变量的第二个语义是禁止指令重排序优化。

long和double型变量的特殊规则

Java内存模型要求lock、unlock、read、load、assign、use、store、write这8个操作都具有原子性,但是对于64位的数据类型(long和double),在模型中特别定义了一条相对宽松的规定:允许虚拟机将没有被volatile修饰的64位数据的读写操作划分为两次32位的操作来进行。

如果多个线程共享一个并未声明为volatile的long或double类型的变量,并且同时对它们进行读取和修改操作,那么某些线程可能会读取到一个既非原值,也不是其他线程修改值的代表了“半个变量”的数值。

原子性、可见性与有序性

Java内存模型是围绕着在并发过程中如何处理原子性、可见性和有序性3个特征来建立的,我们逐个来看一下哪些操作实现了这3个特性。

原子性

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

可见性

可见性是指当一个线程修改了共享变量的值,其他线程能够立即得知这个修改。普通变量和volatile变量的区别是,volatile的特殊规则保证了新值能立即同步到主内存,以及每次使用前立即从主内存刷新。

除volatile之外,Java还有两个关键字能实现可见性,即synchronized和final。同步块的可见性是由“对一个变量执行unlock操作之前,必须先把此变量同步回主内存中(执行store、write操作)”这条规则获取的。

final关键字的可见性是指:被final修饰的字段在构造器中一旦初始化完成,并且构造器没有把“this”的引用传递出去(即this引用逃逸),那么其他线程中就能看见final字段的值。

有序性

Java语言提供了volatile和synchronized两个关键字来保证线程之间操作的有序性,volatile关键字本身就包含了禁止指令重排序的语义,而synchronized则是由“一个变量在同一个时刻只允许一条线程对其进行lock操作”这条规则获得的,这条规则决定了持有同一个锁的两个同步块只能串行地进入。

使用同步

同步不仅可以阻止一个线程看到对象处于不一致的状态之中,它还可以保证进入同步方法或者同步代码块的每个线程,都看到由同一个锁保护的之前所有的修改效果。

为了在线程之间进行可靠的通信,也为了互斥访问,同步是必要的。

public class StopThread {

    public static boolean stopRequested;

    public static void main(String[] args) throws InterruptedException {
        Thread backgroundThread = new Thread(new Runnable() {
            @Override
            public void run() {
                int i = 0;
                while (!stopRequested)
                    i++;
            }
        });
        backgroundThread.start();

        TimeUnit.SECONDS.sleep(1);
        stopRequested = true;
    }

}

上面的后台线程永远在循环。问题在于,由于没有同步,就不能保证后台线程何时“看到”主线程对stopRequested的值所做的改变。没有同步,虚拟机将这个代码:

while(!done)
    i++;

转变为这样:

if(!done)
    while(true)
        i++;

这是可以接受的。这种优化称作提升。正是HopSpot Server VM的工作。

可做如下修正:

public class StopThread {

    public static boolean stopRequested;

    private static synchronized void requestStop(){
        stopRequested = true;
    }

    private static synchronized boolean stopRequested(){
        return stopRequested;
    }

    public static void main(String[] args) throws InterruptedException {
        Thread backgroundThread = new Thread(new Runnable() {
            @Override
            public void run() {
                int i = 0;
                while (!stopRequested())
                    i++;
            }
        });
        backgroundThread.start();

        TimeUnit.SECONDS.sleep(1);
        stopRequested = true;
    }

}

注意写方法和读方法都被同步了。只同步写方法还不够!如果读和写操作没有都被同步,同步就不会起作用。

如果stopRequested被声明为volatile,第二种版本的StopThread中的锁就可以省略。它可以保证任何一个线程在读取该域的时候都将看到最近刚刚被写入的值。

偏序关系(先行发生关系)

JVM为程序中所有的操作定义了一个偏序关系,称之为Happens-Before。如果两个操作之间缺乏Happens-Before关系,那么JVM可以对它们任意地重排序。

Happens-Before的规则包括:

程序顺序规则。如果程序中操作A在操作B之前,那么在线程中A操作将在B操作之前执行。

监视器锁规则。在监视器锁上的解锁操作必须在同一个监视器锁上的加锁操作之前执行。

volatile变量规则。对volatile变量的写入操作必须在对该变量读操作之前执行。

线程启动规则。在线程上对Thread.start的调用必须在该线程中执行任何操作之前执行。

线程结束规则。线程中的任何操作都必须在其他线程检测到该线程已经结束之前执行,或者从Thrad.join中成功返回,或者在调用Thrad.isAlive时返回false。

中断规则。当一个线程在另一个线程上调用interrupt时,必须在被中断线程检测到interrupt调用之前执行。

终结器规则。对象的构造函数必须在启动该对象的终结器之前执行完成。

传递性。如果操作A在操作B之前执行,并且操作B在操作C之前执行,那么操作A必须在操作C之前执行。

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

如下代码:

private int value = 0;

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

public int getValue(){
    return value;
}

假设线程A和B,线程A先调用了“setValue(1)”,然后线程B调用了一个对象的“getValue”,那么线程B收到的返回值是什么?

通过分析上面各项规则,均不满足,因此可以判定尽管线程A在操作时间上先行发生于线程B,但是无法确定线程B中“getValue()”方法的返回结果,也就是说这里的操作不是线程安全的。

总结一下:
1. 物理机遇到的并发问题与虚拟机的情况有不少相似之处,可以对比理解。
2. 同步不仅仅是为了线程安全,也可以保证可见性。
3. volatile关键字有其特殊规则。
4. 理解偏序关系和内存屏障。

原文地址:https://www.cnblogs.com/lucare/p/8679146.html