并发编程(六)CAS原理+ABA问题的解决

乐观锁和悲观锁
Synchronized属于悲观锁,悲观地认为程序中的并发情况严重,所以严防死守。CAS属于乐观锁,乐观地认为程序中的并发情况不那么严重,所以让线程不断去尝试更新。

性能对比:
Synchronized关键字会让没有得到锁资源的线程进入blocked状态,而后在争夺到锁资源后恢复为runnable状态,这个过程中涉及到操作系统用户模式和内核模式的转换,代价比较高。
尽管Java1.6为Synchronized做了优化,增加了从偏向锁到轻量级锁再到重量级锁的过度,但是在最终转变为重量级锁之后,性能仍然较低。

CAS原理
CAS机制当中使用了3个基本操作数:内存地址V,旧的预期值A,要修改的新值B。
更新一个变量的时候,只有当变量的预期值A和内存地址V当中的实际值相同时,才会将内存地址V对应的值修改为B。

CAS机制:
AtomicInteger当中常用的自增方法 incrementAndGet:

 //+1操作
    public final long getAndIncrement() {
        while (true) {
            long current = get();
            long next = current + 1;
            //当+1操作成功的时候直接返回,退出此循环
            if (compareAndSet(current, next))
                return current;
        }
    }


    //调用JNI实现CAS
    public final boolean compareAndSet(long expect, long update) {
        return unsafe.compareAndSwapLong(this, valueOffset, expect, update);
    }

JNI:Java Native Interface为JAVA本地调用,允许java调用其他语言。在jdk1.8后getAndIncrement()方法已经看不到具体代码了,而是封装在unsafe类里面。
CAS的自旋。循环体当中做了三件事:
1.获取当前值。
2.当前值+1,计算出目标值。
3.进行CAS操作,如果成功则跳出循环,如果失败则重复上述步骤。

CAS的缺点:
ABA问题。由于为了避免数据结构复杂的情况,读写内存开销比较大,而使用了AtomicReference只比较两个对象的引用。因为CAS需要在操作值的时候检查下值有没有发生变化,如果没有发生变化则更新,但是如果一个值原来是A,变成了B,又变成了A,那么使用CAS进行检查时会发现它的值没有发生变化,但是实际上却变化了。ABA问题的解决思路就是使用版本号。在变量前面追加上版本号,每次变量更新的时候把版本号加一,那么A-B-A 就会变成1A-2B-3A。
从Java1.5开始JDK的atomic包里提供了一个类AtomicStampedReference来解决ABA问题。这个类的compareAndSet方法作用是首先检查当前引用是否等于预期引用,并且当前标志是否等于预期标志,如果全部相等,则以原子方式将该引用和该标志的值设置为给定的更新值。
循环时间长开销大。自旋CAS如果长时间不成功,会给CPU带来非常大的执行开销。如果JVM能支持处理器提供的pause指令那么效率会有一定的提升,pause指令有两个作用,第一它可以延迟流水线执行指令(de-pipeline),使CPU不会消耗过多的执行资源,延迟的时间取决于具体实现的版本,在一些处理器上延迟时间是零。第二它可以避免在退出循环的时候因内存顺序冲突(memory order violation)而引起CPU流水线被清空(CPU pipeline flush),从而提高CPU的执行效率。
不能保证代码块的原子性,只能保证变量的原子性操作。当对一个共享变量执行操作时,我们可以使用循环CAS的方式来保证原子操作,但是对多个共享变量操作时,循环CAS就无法保证操作的原子性,这个时候就可以用锁,或者有一个取巧的办法,就是把多个共享变量合并成一个共享变量来操作。比如有两个共享变量i=2,j=a,合并一下ij=2a,然后用CAS来操作ij。从Java1.5开始JDK提供了AtomicReference类来保证引用对象之间的原子性,你可以把多个变量放在一个对象里来进行CAS操作。
比较花费CPU资源,即使没有任何争用也会做一些无用功。
会增加程序测试的复杂度,稍不注意就会出现问题。

你可能感兴趣的:(职场@多线程高并发@Java)