volatile和CAS

volatile和CAS,第1张

volatile和CAS volatile

volatile 是java虚拟机提供的轻量级的同步机制

  1. 保证可见性
  2. 不保证原子性
  3. 禁止指令重排
JMM(java内存模型)

JMM(java内存模型Java Memory Model,简称JMM)本身是一种抽象的概念并不真实存在,它描述的是一组规则或规范,通过这组规范定义了程序中各个变量(包括实例字段,静态字段和构成数组对象的元素)的访问方式。

JMM关于同步的规定:

1 线程解锁前,必须把共享变量的值刷新回主内存

2 线程加锁前,必须读主内存的最新值到自己的工作内存。

3 加锁解锁是同一把锁

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

一个线程改变变量值并写回主内存,必须通知其他线程,JMM可见性

JMM三大特性

  1. 可见性
  2. 原子性
  3. 有序性
验证volatile 可见性
class MyData {
    int number = 0;
    public void addT060() {
        this.number = 60;
    }
    public void addPlusPlus() {
        number++;
    }
}


public class VolatileDemo {
    public static void main(String[] args) {
        MyData myData = new MyData();
        new Thread(()->{
            System.out.println(Thread.currentThread().getName() +"t come in");
            try {
                TimeUnit.SECONDS.sleep(3);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            myData.addT060();
            System.out.println(Thread.currentThread().getName()+"t updated number value:"+myData.number);
        },"AAA").start();
        //如果主线程的mydata的number没有被修改就一直循环,证明当前变量没有可见性。
        while (myData.number ==  0) {

        }
        //如果走出循环说明主线程number已经改变,证明有可见性
        System.out.println(Thread.currentThread().getName()+"t updated number value:"+myData.number);
    }
}

没有用volatile修饰MyData类的成员变量number,main线程将会卡在while(myData.number == 0) {},不能正常结束。

用volatile修饰number变量后输出结果:

证明volatile 保证了可见性

验证volatile 不保证原子性
import java.util.concurrent.TimeUnit;


class MyData {
    volatile int number = 0;
    public void addT060() {
        this.number = 60;
    }
    public void addPlusPlus() {
        number++;
    }
}


public class VolatileDemo {
    public static void main(String[] args) {
        MyData myData = new MyData();
        for (int i = 1; i <= 20; i++) {
            new Thread(() -> {
                for (int j = 0; j < 1000; j++) {
                    myData.addPlusPlus();
                }
            }, String.valueOf(i)).start();
        }
        while (Thread.activeCount() > 2) {
            Thread.yield();
        }
        System.out.println(Thread.currentThread().getName()+"t finally number value:"+myData.number);
    }
}

输出结果:

main	 finally number value:19202

最终输出结果<20000 说明volatile没有保证原子性

volatile不保证原子性理论解释

number++在多线程下是非线程安全的。

我们可以将代码编译成字节码,可看出number++被编译成3条指令。

3个线程同时拿到主内存变量值,进行自增 *** 作,但写回主内存时,1号线程先写回,2号3号再未收到修改通知前也将自己的值覆盖进主内存,导致丢失写值。

如何解决原子性

  1. 使用synchronized关键字 (太重)
  2. 使用AtomicInteger
class MyData {
    volatile int number = 0;
    public void addT060() {
        this.number = 60;
    }
    public  void addPlusPlus() {
        number++;
    }

     AtomicInteger atomicInteger = new AtomicInteger();
    public void addAtomic() {
        atomicInteger.getAndIncrement();
    }
}


public class VolatileDemo {
    public static void main(String[] args) {
        MyData myData = new MyData();
        for (int i = 1; i <= 20; i++) {
            new Thread(() -> {
                for (int j = 0; j < 1000; j++) {
                    myData.addPlusPlus();
                    myData.addAtomic();
                }
            }, String.valueOf(i)).start();
        }
        while (Thread.activeCount() > 2) {
            Thread.yield();
        }
        System.out.println(Thread.currentThread().getName()+"t finally number value:"+myData.number);
        System.out.println(Thread.currentThread().getName()+"t finally number value:"+myData.atomicInteger);
    }

    
    private static void seeOkByVolatile() {
        MyData myData = new MyData();
        new Thread(()->{
            System.out.println(Thread.currentThread().getName() +"t come in");
            try {
                TimeUnit.SECONDS.sleep(3);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            myData.addT060();
            System.out.println(Thread.currentThread().getName()+"t updated number value:"+myData.number);
        },"AAA").start();
        //如果主线程的mydata的number没有被修改就一直循环,证明当前变量没有可见性。
        while (myData.number ==  0) {

        }
        //如果走出循环说明主线程number已经改变,证明有可见性
        System.out.println(Thread.currentThread().getName()+"t updated number value:"+myData.number);
    }
}

volatile指令重排案例1

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

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

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

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

重排案例1

public void mySort{
	int x = 11;//语句1
    int y = 12;//语句2
    × = × + 5;//语句3
    y = x * x;//语句4
}

可重排序列:

  • 1234
  • 2134
  • 1324

问题:请问语句4可以重排后变成第一个条吗?答:不能。(处理器在进行重排序时必须要考虑指令之间的数据依赖性)

重排案例2

int a,b,x,y = 0

线程1线程2x = a;y = b;b = 1;a = 2;x = 0; y = 0

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

线程1线程2b = 1;a = 2;x = a;y = b;

x = 2; y = 1

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

单例模式在多线程环境下可能存在安全问题

懒汉单例模式

public class SingletonDemo {

    private static SingletonDemo instance = null;

    private SingletonDemo () {
        System.out.println(Thread.currentThread().getName() + "t 我是构造方法SingletonDemo");
    }

    public static SingletonDemo getInstance() {
        if(instance == null) {
            instance = new SingletonDemo();
        }
        return instance;
    }

    public static void main(String[] args) {
        // 这里的 == 是比较内存地址
        System.out.println(SingletonDemo.getInstance() == SingletonDemo.getInstance());
        System.out.println(SingletonDemo.getInstance() == SingletonDemo.getInstance());
        System.out.println(SingletonDemo.getInstance() == SingletonDemo.getInstance());
        System.out.println(SingletonDemo.getInstance() == SingletonDemo.getInstance());
    }
}

输出结果:

main    我是构造方法singletonDemo
true
true
true
true

但是,在多线程环境运行上述代码,能保证单例吗?

public class SingletonDemo {

    private static SingletonDemo instance = null;

    private SingletonDemo () {
        System.out.println(Thread.currentThread().getName() + "t 我是构造方法SingletonDemo");
    }

    public static SingletonDemo getInstance() {
        if(instance == null) {
            instance = new SingletonDemo();
        }
        return instance;
    }

    public static void main(String[] args) {
        for (int i = 0; i < 10; i++) {
            new Thread(() -> {
                SingletonDemo.getInstance();
            }, String.valueOf(i)).start();
        }
    }
}

输出结果:

4	 我是构造方法SingletonDemo
2	 我是构造方法SingletonDemo
5	 我是构造方法SingletonDemo
6	 我是构造方法SingletonDemo
0	 我是构造方法SingletonDemo
3	 我是构造方法SingletonDemo
1	 我是构造方法SingletonDemo

显然不能保证单例。

解决方法之一:用synchronized修饰方法getInstance(),但它属重量级同步机制,使用时慎重。

public synchronized static SingletonDemo getInstance() {
    if(instance == null) {
        instance = new SingletonDemo();
    }
    return instance;
}

解决方法之二:DCL(Double Check Lock双端检锁机制)

public class SingletonDemo{
	private SingletonDemo(){}
    
    private static SingletonDemo instance = null;

    public static SingletonDemo getInstance() {
        if(instance == null) {
            synchronized(SingletonDemo.class){
                if(instance == null){
                    instance = new SingletonDemo();       
                }
            }
        }
        return instance;
    }
}
单例模式volatile分析

DCL中volatile解析

原因在于某一个线程执行到第一次检测,读取到的instance不为null时,instance的引用对象可能没有完成初始化。instance = new SingletonDemo();可以分为以下3步完成(伪代码):

memory = allocate(); //1.分配对象内存空间
instance(memory); //2.初始化对象
instance = memory; //3.设置instance指向刚分配的内存地址,此时instance != null

步骤2和步骤3不存在数据依赖关系,而且无论重排前还是重排后程序的执行结果在单线程中并没有改变,因此这种重排优化是允许的。

memory = allocate(); //1.分配对象内存空间
instance = memory;//3.设置instance指向刚分配的内存地址,此时instance! =null,但是对象还没有初始化完成!
instance(memory);//2.初始化对象

但是指令重排只会保证串行语义的执行的一致性(单线程),但并不会关心多线程间的语义一致性。

所以当一条线程访问instance不为null时,由于instance实例未必已初始化完成,也就造成了线程安全问题。

CAS

CAS 是什么

Compare And Set 比较并set,

如果值与预期值一样则set, 发回true,不一样不set,返回false

示例程序

public class CASDemo{
    public static void main(string[] args){
        AtomicInteger atomicInteger = new AtomicInteger(5);// mian do thing. . . . ..
        System.out.println(atomicInteger.compareAndSet(5, 2019)+"t current data: "+atomicInteger.get());
        System.out.println(atomicInteger.compareAndset(5, 1024)+"t current data: "+atomicInteger.get());
    }
}

输出结果为

true    2019
false   2019
CAS底层原理

Unsafe 类 + 自旋思想。

谈谈你对UnSafe的理解

atomiclnteger.getAndIncrement();源码

public class AtomicInteger extends Number implements java.io.Serializable {
    private static final long serialVersionUID = 6214790243416807050L;

    // setup to use Unsafe.compareAndSwapInt for updates
    private static final Unsafe unsafe = Unsafe.getUnsafe();
    private static final long valueOffset;

    static {
        try {
            valueOffset = unsafe.objectFieldOffset
                (AtomicInteger.class.getDeclaredField("value"));
        } catch (Exception ex) { throw new Error(ex); }
    }

    private volatile int value;
    
    
    public AtomicInteger(int initialValue) {
        value = initialValue;
    }

    
    public AtomicInteger() {
    }
    
    ...
            
    
    public final int getAndIncrement() {
        return unsafe.getAndAddInt(this, valueOffset, 1);
    }
    
    ...
}
    
UnSafe

1 Unsafe

是CAS的核心类,由于Java方法无法直接访问底层系统,需要通过本地(native)方法来访问,Unsafe相当于一个后门,基于该类可以直接 *** 作特定内存的数据。Unsafe类存在于sun.misc包中,其内部方法 *** 作可以像C的指针一样直接 *** 作内存,因为Java中CAS *** 作的执行依赖于Unsafe类的方法。

注意Unsafe类中的所有方法都是native修饰的,也就是说Unsafe类中的方法都直接调用 *** 作系统底层资源执行相应任务。

2 变量valueOffset,表示该变量值在内存中的偏移地址,因为Unsafe就是根据内存偏移地址获取数据的。

3 变量value用volatile修饰,保证了多线程之间的内存可见性。

CAS是什么

CAS的全称为Compare-And-Swap,它是一条CPU并发原语。

它的功能是判断内存某个位置的值是否为预期值,如果是则更改为新的值,这个过程是原子的。

CAS并发原语体现在JAVA语言中就是sun.misc.Unsafe类中的各个方法。调用UnSafe类中的CAS方法,JVM会帮我们实现出CAS汇编指令。这是一种完全依赖于硬件的功能,通过它实现了原子 *** 作。再次强调,由于CAS是一种系统原语,原语属于 *** 作系统用语范畴,是由若干条指令组成的,用于完成某个功能的一个过程,并且原语的执行必须是连续的,在执行过程中不允许被中断,也就是说CAS是一条CPU的原子指令,不会造成所谓的数据不一致问题。(原子性)

unsafe getAndInt 方法解析

public final int getAndInt (Object var1,long var2,int var4) {
    int var5;
    do {
        var5 = this.getIntVolatie(var1,var2)
    } while(!this.compareAndSwapInt(var1,var2,var5,var5 + var4));
    return var5;
}
  • var1 AtomicInteger对象本身。
  • var2 该对象值得引用地址。
  • var4 需要变动的数量。
  • var5是用过var1,var2找出的主内存中真实的值。
  • 用该对象当前的值与var5比较:
  • 如果相同,更新var5+var4并且返回true,、
  • 如果不同,继续取值然后再比较,直到更新完成。

this.getIntVolatie(var1,var2) 先获取到改对象对应内存地址的值。get *** 作

然后在while中判断其是否和预期值相等,如果相等则自增1,如果不相等,则继续进行循环获取值,直到与预期值相等位置。

假设线程A和线程B两个线程同时执行getAndAddInt *** 作(分别跑在不同CPU上) :

  1. Atomiclnteger里面的value原始值为3,即主内存中Atomiclnteger的value为3,根据JMM模型,线程A和线程B各自持有一份值为3的value的副本分别到各自的工作内存。
  2. 线程A通过getIntVolatile(var1, var2)拿到value值3,这时线程A被挂起。
  3. 线程B也通过getintVolatile(var1, var2)方法获取到value值3,此时刚好线程B没有被挂起并执行compareAndSwapInt方法比较内存值也为3,成功修改内存值为4,线程B打完收工,一切OK。
  4. 这时线程A恢复,执行compareAndSwapInt方法比较,发现自己手里的值数字3和主内存的值数字4不一致,说明该值己经被其它线程抢先一步修改过了,那A线程本次修改失败,只能重新读取重新来一遍了。
  5. 线程A重新获取value值,因为变量value被volatile修饰,所以其它线程对它的修改,线程A总是能够看到,线程A继续执行compareAndSwaplnt进行比较替换,直到成功。

底层汇编

Unsafe类中的compareAndSwapInt,是一个本地方法,该方法的实现位于unsafe.cpp中。

UNSAFE_ENTRY(jboolean, Unsafe_CompareAndSwapInt(JNIEnv *env, jobject unsafe, jobject obj, jlong offset, jint e, jint x)
UnsafeWrapper("Unsafe_CompareAndSwaplnt");
oop p = JNlHandles::resolve(obj);
jint* addr = (jint *)index_oop_from_field_offset_long(p, offset);
return (jint)(Atomic::cmpxchg(x, addr, e))== e;
UNSAFE_END
//先想办法拿到变量value在内存中的地址。
//通过Atomic::cmpxchg实现比较替换,其中参数x是即将更新的值,参数e是原内存的值。

小结

CAS指令

CAS有3个 *** 作数,内存值V,旧的预期值A,要修改的更新值B。
当且仅当预期值A和内存值V相同时,将内存值V修改为B,否则什么都不做。

CAS缺点

循环时间长开销很大

我们可以看到getAndAddInt方法执行时,有个do while,如果CAS失败,会一直进行尝试。如果CAS长时间一直不成功,可能会给CPU带来很大的开销。

只能保证一个共享变量的原子 *** 作

当对一个共享变量执行 *** 作时,我们可以使用循环CAS的方式来保证原子 *** 作,但是,对多个共享变量 *** 作时,循环CAS就无法保证 *** 作的原子性,这个时候就可以用锁来保证原子性。

引出来ABA问题

ABA问题

ABA问题怎么产生的

CAS会导致“ABA问题”。

CAS算法实现一个重要前提需要取出内存中某时刻的数据并在当下时刻比较并替换,那么在这个时间差类会导致数据的变化。

比如说一个线程one从内存位置V中取出A,这时候另一个线程two也从内存中取出A,并且线程two进行了一些 *** 作将值变成了B,然后线程two又将V位置的数据变成A,这时候线程one进行CAS *** 作发现内存中仍然是A,然后线程one *** 作成功。

尽管线程one的CAS *** 作成功,但是不代表这个过程就是没有问题的。

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/5692484.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-12-17
下一篇 2022-12-17

发表评论

登录后才能评论

评论列表(0条)

保存