对volatile的理解--从JMM以及单例模式剖析

最新推荐文章于 2024-08-03 23:57:22 发布

2401_84046545

最新推荐文章于 2024-08-03 23:57:22 发布

阅读量753

点赞数 11

分类专栏：程序员文章标签：单例模式 java jvm

本文链接：https://blog.csdn.net/2401_84046545/article/details/138019551

版权

程序员专栏收录该内容

477 篇文章 0 订阅

订阅专栏

MyTest myTest = new MyTest();

//第一个线程

new Thread(() -> {

try {

System.out.println(Thread.currentThread().getName() + “\t come in”);

Thread.sleep(3000);

myTest.numTo60();

System.out.println(Thread.currentThread().getName() + “\t update value:” + myTest.num);

} catch (InterruptedException e) {

e.printStackTrace();

}

} ,“thread1”).start();;

//主线程判断num值

while (myTest.num == 0){

//如果myData的num一直为零，main线程一直在这里循环

}

System.out.println(Thread.currentThread().getName() + "\t mission is over, num value is " + myTest.num);

}

如上代码是没有保证可见性的，可见性存在于JMM当中即java内存模型当中的，可见性主要是指当一个线程改变其内部的工作内存当中的变量后，其他线程是否可以观察到，因为不同的线程件无法访问对方的工作内存，线程间的通信（传值）必须通过主内存来完成，因为此处没有添加volatile指令，导致其中thread1对num值变量进行更改时，main线程无法感知到num值发生更改，导致在while处无限循环，读不到新的num值，会发生死循环

此时修改类中代码为

/**

* volatile可以保证可见性，及时通知其他线程，主物理内存的值已经被修改

public static class MyTest{

//类的内部成员变量num

public volatile int num = 0;

//numTo60 方法，让num值为60

public void numTo60(){

num = 60;

}

此时volatile就可以保证内存的可见性，此时运行代码就可以发现

1.2 不保证原子性

原子性概念：不可分割、完整性，即某个线程正在做某个具体业务时，中间不可以被加塞或者被分割，需要整体完整，要么同时成功，要么同时失败

类代码为：

//自定义的类

public static class MyTest {

//类的内部成员变量num

public volatile int num = 0;

public void numPlusPlus() {

num++;

}

主方法为

public static void main(String[] args) {

MyTest myTest = new MyTest();

/**

* 10个线程创建出来，每个线程执行2000次num++操作

* 我们知道，在字节码及底层，i++被抽象为三个操作

* 即先取值，再自加，再赋值操作

for (int i = 1; i <= 10; i++) {

new Thread(() -> {

for (int j = 0; j < 2000; j++) {

myTest.numPlusPlus();

}

}, “Thread” + i).start();

}

//这里规定线程数大于2，一般有GC线程以及main主线程

while (Thread.activeCount() > 2) {

Thread.yield();

}

System.out.println(Thread.currentThread().getName() + "\t finally num value is " + myTest.num);

}

代码如上所示，如果volatile保证原子性，那么10个线程分别执行自加2000次操作，那么最终结果一定是20000，但是执行三次结果如下

//第一次

main finally num value is 19003

//第二次

main finally num value is 18694

//第三次

main finally num value is 19552

可以发现，我们num的值每次都不相同，且最后的值都没有达到20000，这是为什么呢？

为什么会出现这种情况？

首先，我们要考虑到这种情况，假如线程A执行到第11行即myTest.numPlusPlus();方法时

线程进入方法执行numPlusPlus方法后，num的值不管是多少，线程A将num的值首先初始化为0（假如主存中num的值为0），之后num的值自增为1，之后线程A挂起，线程B此时也将主存中的num值读到自己的工作内存中值为0，之后num的值自增1，之后线程B挂起，线程A继续运行将num的值写回主存，但是因为volatile关键字保证可见性，但是在很短的时间内，线程B也将num的值写回主存，此时num的值就少加了一次，所以最后总数基本上少于20000

如何解决？

但是JUC有线程的原子类为AtomicInteger类，此时，将类代码更改为

public static class MyTest {

//类的内部成员变量num

public volatile int num = 0;

AtomicInteger atomicInteger = new AtomicInteger();

//numTo60 方法，让num值为60

public void numTo60() {

num = 60;

}

public void numPlusPlus() {

num++;

}

public void myAtomPlus(){

atomicInteger.getAndIncrement();

}

共同测试num和atomicInteger，此时执行主函数，三次结果为

//第一次

main finally num value is 19217

main finally atomicInteger value is 20000

//第二次

main finally num value is 19605

main finally atomicInteger value is 20000

//第三次

main finally num value is 18614

main finally atomicInteger value is 20000

我们发现volatile关键字并没有保证我们的变量的原子性，但是JUC内部的AtomicInteger类保证了我们变量相关的原子性，AtomicInteger底层用到了CAS。

1.3 禁止指令重排

有序性的概念：在计算机执行程序时，为了提高性能，编译器和处理器常常会对指令做重排，一般分以下三种

单线程环境里面确保程序最终执行结果和代码顺序执行的结果一致。

处理器在进行重排顺序是必须要考虑指令之间的数据依赖性

多线程环境中线程交替执行，由于编译器优化重排的存在，两个线程中使用的变量能否保证一致性时无法确定的，结果无法预测

重排代码实例：声明变量：int a,b,x,y=0

如果编译器对这段程序代码执行重排优化后，可能出现如下情况：

这个结果说明在多线程环境下，由于编译器优化重排的存在，两个线程中使用的变量能否保证一致性是无法确定的

volatile实现禁止指令重排，从而避免了多线程环境下程序出现乱序执行的现象

内存屏障（Memory Barrier）又称内存栅栏，是一个CPU指令，他的作用有两个：

保证特定操作的执行顺序
保证某些变量的内存可见性（利用该特性实现volatile的内存可见性）

由于编译器和处理器都能执行指令重排优化。如果在之间插入一条Memory Barrier则会告诉编译器和CPU，不管什么指令都不能和这条Memory Barrier指令重排顺序，也就是说通过插入内存屏障禁止在内存屏障前后的指令执行重排序优化。内存屏障另外一个作用是强制刷出各种CPU的缓存数据，因此任何CPU上的线程都能读取到这些数据的最新版本

2.JMM（java内存模型）

为什么提到JMM？JMM当中规定了可见性、原子性、以及有序性的问题，在多线程中只要保证了以上问题的正确性，那么基本上不会发生多线程当中存在数据安全问题

JMM（Java Memory Model）本身是一种抽象的概念，并不真实存在，他描述的时一组规则或规范，通过这组规范定义了程序中各个变量（包括实例字段，静态字段和构成数组对象的元素）的访问方式。

JMM关于同步的规定：

线程解锁前，必须把共享变量的值刷新回主内存
线程加锁前，必须读取主内存的最新值到自己的工作内存
加锁解锁时同一把锁

由于JVM运行程序的实体是线程，而每个线程创建时JVM都会为其创建一个工作内存（有的成为栈空间），工作内存是每个线程的私有数据区域，而java内存模型中规定所有变量都存储在主内存，主内存是贡献内存区域，所有线程都可以访问，但线程对变量的操作（读取赋值等）必须在工作内存中进行，首先概要将变量从主内存拷贝到自己的工作内存空间，然后对变量进行操作，操作完成后再将变量写回主内存，不能直接操作主内存中的变量，各个线程中的工作内存中存储着主内存的变量副本拷贝，因此不同的线程件无法访问对方的工作内存，线程间的通信（传值）必须通过主内存来完成，期间要访问过程如下图：