JMM描述的是一组规范, 它类似于cpu和内存的架构. 这套模型是为了适配不同的操作系统, 不同的硬件结构, 屏蔽掉底层的微小的差异. jvm为什么可以跨平台呢? 有一方面就是JMM内存模型的设计. 尤其是多线程, 再调底层操作系统的时候, 为了屏蔽底层细节的差异, java抽象出来的一个概念, 叫做java线程的工作模型, 也叫java的内存模型
下面来感受一下: 工作内存和主内存的概念.
现在有这样一段代码:
public class Main {
private static boolean initFlag = false;
public static void refresh() {
System.out.println("refresh data.....");
initFlag = true;
System.out.println("refresh data success");
}
public static void main(String[] args) {
// 线程A
Thread threadA = new Thread(() ->{
while (!initFlag) {
}
System.out.println("线程:" + Thread.currentThread().getName() + "当前线程秀谈到initFlag的状态已经改变");
}, "threadA");
threadA.start();
// 中间休眠500hs
try {
Thread.sleep(500);
} catch (InterruptedException e) {
e.printStackTrace();
}
// 线程B
Thread threadB = new Thread(() ->{
while (!initFlag) {
refresh();
}
}, "threadB");
threadB.start();
}
}
这样一段代码, 当程序启动以后, 其内存模型是什么样的呢?
如下图所示.
在明白了Java内存区域划分、硬件内存架构、Java多线程的实现原理与Java内存模型 的具体关系后,接着来谈谈Java内存模型存在的必要性。
假设现在A线程想要修改x的值为2,而B线 程却想要读取x的值,那么B线程读取到的值是A线程更新后的值2还是更新前的值1呢?
答案是,不确定,即B线程有可能读取到A线程更新前的值1,也有可能读取到A线程更新后的值2,
这是因为工作内存是每个线程私有的数据区域,而线程A变量x时,首先是将变量从主内 存拷贝到A线程的工作内存中,然后对变量进行操作,操作完成后再将变量x写回主内,
而对于B线程的也是类似的,这样就有可能造成主内存与工作内存间数据存在一致性问题,假 如A线程修改完后正在将数据写回主内存,而B线程此时正在读取主内存,即将x=1拷贝到 自己的工作内存中,这样B线程读取到的值就是x=1,但如果A线程已将x=2写回主内存后, B线程才开始读取的话,那么此时B线程读取到的就是x=2,但到底是哪种情况先发生呢?
如以下示例图所示案例:
还是上面的例子, 线程A是如何把变量initFlag读取到工作内存的? 他在工作内存是怎么工作的呢? 下面我们就来分析这个例子在内存模型中的使用.
public class Main {
private static boolean initFlag = false;
public static void refresh() {
System.out.println("refresh data.....");
initFlag = true;
System.out.println("refresh data success");
}
public static void main(String[] args) {
// 线程A
Thread threadA = new Thread(() ->{
while (!initFlag) {
}
System.out.println("线程:" + Thread.currentThread().getName() + "当前线程秀谈到initFlag的状态已经改变");
}, "threadA");
threadA.start();
// 中间休眠500hs
try {
Thread.sleep(500);
} catch (InterruptedException e) {
e.printStackTrace();
}
// 线程B
Thread threadB = new Thread(() ->{
while (!initFlag) {
refresh();
}
}, "threadB");
threadB.start();
}
}
这里是先执行线程A, 然后休眠5秒, 执行线程B.
运行结果:
以上是关于主内存与工作内存之间的具体交互协议,即一个变量如何从主内存拷贝到工作 内存、如何从工作内存同步到主内存之间的实现细节,
如果要把一个变量从主内存中复制到工作内存中,就需要按顺序地执行read和load操作,如果把变量从工作内存中同步到主内存中,就需要按顺序地执行store和write操作。但
Java内存模型只要求上述操作必须按顺序执行,而没有保证必须是连续执行。
java的内存模型定义了8大原子操作, 所谓的原子操作, 就是执行的过程中, 不可以被终端, 要么都成功, 要么都失败. 这8个操作, 其中有六个是用来做数据交互的(3-8), 有两个是做数据安全操作的(1-2).
首先. 执行read操作, 作用于主内存, 将变量initFlag从主内存拷贝一份, 这时候还没有放到工作内存中. 而是放在了总线里. 如下图.
第二步: 执行load操作, 作用于工作内存, 将上一步拷贝的变量, 放入工作内存中.
第三步: 执行use(使用)操作, 作用于工作内存, 把工作内存中的变量传递给执行引擎. 对于线程A来说, 执行引擎会判断initFlag=true么? 不等于, 循环一直进行.
首先: 执行read操作, 作用于主内存, 从主内存拷贝initFlag变量, 这时候拷贝的变量还没有放到工作内存中, 这一步是为了load做准备
第二步:执行load操作, 作用于工作内存, 将拷贝的变量放入到工作内存中,
第三步: 执行use操作, 作用于工作内存, 将工作内存中的变量传递给执行引擎, 执行引擎判断while==false, 那么执行循环体.
第四步: 执行assign操作, 作用于工作内存, 他把从执行引擎接收的值赋值给工作内存的变量, 即设置initFlag = true
第五步: 执行store操作, 作用于工作内存, 将工作内存中的变量initFlag=true传给主内存
第六步: 执行write操作, 作用于工作内存, 将变量写入到主内存中
原子性指的是一个操作是不可中断的,即使是在多线程环境下,一个操作一旦开始就不会被其他线程影响。
在java中,对基本数据类型的变量的读取和赋值操作是原子性操作有点要注意的是,对 于32位系统的来说,long类型数据和double类型数据(对于基本数据类型,
byte,short,int,float,boolean,char读写是原子操作),它们的读写并非原子性的,也就是说 如果存在两条线程同时对long类型或者double类型的数据进行读写是存在相互干扰的,因 为对于32位虚拟机来说,每次原子读写是32位的,而long和double则是64位的存储单元, 这样会导致一个线程在写时,操作完前32位的原子操作后,轮到B线程读取时,恰好只读取 到了后32位的数据,这样可能会读取到一个既非原值又不是线程修改值的变量,它可能 是“半个变量”的数值,即64位数据被两个线程分成了两次读取。但也不必太担心,因为 读取到“半个变量”的情况比较少见,至少在目前的商用的虚拟机中,几乎都把64位的数 据的读写操作作为原子操作来执行,因此对于这个问题不必太在意,知道这么回事即可。
理解了指令重排现象后,可见性容易了,可见性指的是当一个线程修改了某个共享变量的值,其他线程是否能够马上得知这个修改的值。
对于串行程序来说,可见性是不存在的, 因为我们在任何一个操作中修改了某个变量的值,后续的操作中都能读取这个变量值,并且是修改过的新值。
但在多线程环境中可就不一定了,前面我们分析过,由于线程对共享变量的操作都是线程拷贝到各自的工作内存进行操作后才写回到主内存中的,这就可能存在一个线程A修改了共享变量x的值,还未写回主内存时,另外一个线程B又对主内存中同一个共享变量x进行操作,但此时A线程工作内存中共享变量x对线程B来说并不可见,这种工作内存与主内存同步 延迟现象就造成了可见性问题,另外指令重排以及编译器优化也可能导致可见性问题,通过前面的分析,我们知道无论是编译器优化还是处理器优化的重排现象,在多线程环境下,确实会导致程序轮序执行的问题,从而也就导致可见性问题。
有序性是指对于单线程的执行代码,我们总是认为代码的执行是按顺序依次执行的,这
样的理解并没有毛病,毕竟对于单线程而言确实如此,但对于多线程环境,则可能出现乱序 现象,因为程序编译成机器码指令后可能会出现指令重排现象,重排后的指令与原指令的顺 序未必一致,要明白的是,在Java程序中,倘若在本线程内,所有操作都视为有序行为,如 果是多线程环境下,一个线程中观察另外一个线程,所有操作都是无序的,前半句指的是单 线程内保证串行语义执行的一致性,后半句则指指令重排现象和工作内存与主内存同步延迟 现象。
volatile关键字保证可见性。
当一个共享变量被volatile修饰时,它会保证修改的值立即被其他的线程看到,即修改的值立即更新到主存中,当其他线程需要读取时,它会去内存中读取新值。
synchronized和Lock也可以保证可见性,因为它们可以保证任一时刻只有一个线程能访问共享资源,并在其释放锁之前将修改的变量刷新到内存中。
public class Main {
private volatile static boolean initFlag = false;
public static void refresh() {
System.out.println("refresh data.....");
initFlag = true;
System.out.println("refresh data success");
}
public static void main(String[] args) {
// 线程A
Thread threadA = new Thread(() ->{
while (!initFlag) {
}
System.out.println("线程:" + Thread.currentThread().getName() + "当前线程秀谈到initFlag的状态已经改变");
}, "threadA");
threadA.start();
// 中间休眠500hs
try {
Thread.sleep(500);
} catch (InterruptedException e) {
e.printStackTrace();
}
// 线程B
Thread threadB = new Thread(() ->{
while (!initFlag) {
refresh();
}
}, "threadB");
threadB.start();
}
}
测试:
public class Main {
private static boolean initFlag = false;
private static int counter = 0;
public static void refresh() {
System.out.println("refresh data.....");
initFlag = true;
System.out.println("refresh data success");
}
public static void main(String[] args) {
// 线程A
Thread threadA = new Thread(() ->{
while (!initFlag) {
counter ++;
}
System.out.println("线程:" + Thread.currentThread().getName() + "当前线程秀谈到initFlag的状态已经改变");
}, "threadA");
threadA.start();
// 中间休眠500hs
try {
Thread.sleep(500);
} catch (InterruptedException e) {
e.printStackTrace();
}
// 线程B
Thread threadB = new Thread(() ->{
while (!initFlag) {
refresh();
}
}, "threadB");
threadB.start();
}
}
private static Integer counter = 0;
我们发现, 线程B修改了共享变量, 线程A是可以看到了.
有的时候, 线程A的修改, 线程B是能看到的,有时候是看不到的. 其实, 线程A的修改, 线程B是可以看到的, 只是不能及时看到.
而我们加上volatile关键字以后, 可以及时看到变量的修改
volatile可以保证可见性, 他能保证原子性么?
volatile不能保证原子性. 看下面的例子
public class VolatileTest {
private static int counter = 0;
public static void main(String[] args) {
for (int i = 0; i < 10; i++) {
Thread threadA = new Thread(new Runnable() {
@Override
public void run() {
for (int j = 0; j < 1000; j++) {
counter ++;
}
}
});
threadA.start();
}
try {
Thread.sleep(1000l);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("统计:" + counter);
}
}
起了10个线程, 每个线程加到1000, 10个线程, 一共是10000.
而实际结果,不到10000, 原因是: 有并发操作.
这时候, 如果我在counter上加关键字volatile, 可以保证原子性么?
private volatile static int counter = 0;
我们发现, 依然不是10000, 这说明volatile不能保证原子性.
每个线程, 只有一个操作, counter++, 为什么不能保证原子性呢?
其实counter++不是一步完成的. 他是分为多步完成的. 我们用下面的图来解释
线程A通过read,, load将变量加载到工作内存, 通过user将变量发送到执行引擎, 执行引擎执行counter++
这是线程B启动了, 通过read,, load将变量加载到工作内存, 通过user将变量发送到执行引擎, 然后执行复制操作assign, stroe, write操作. 我们看到这是经过了n个步骤. 虽然看起来就是简单的一句话.
当线程B执行store将数据回传到主内存的时候, 同时会通知线程A, 丢弃counter++, 而这时counter已经自加了1, 将自加后的counter丢掉, 就导致总数据少1.
如何能保证原子性呢? 加上Synchronize关键字
除了JVM自身提供的对基本数据类型读写操作的原子性外,可以通过 synchronized和Lock实现原子性。因为synchronized和Lock能够保证任一时刻只有一个线程访问该代码 块。
在Java里面,可以通过volatile关键字来保证一定的“有序性”(具体原理在下一节讲述volatile关键字)。
另外可以通过synchronized和Lock来保证有序性,很显然, synchronized和Lock保证每个时刻是有一个线程执行同步代码,相当于是让线程顺序执行同步代码,自然就保证了有序性。