转载

CAS解析

CAS:compare and swap,也有的叫做 compare and set;意思都差不多,翻译过来就是比较并交换或者比较并设值。

CAS包含三个值,内存地址(V),预期值(A),新值(B)。先比较内存地址的值和预期的值是否相等,如果相等,就将新值赋在内存地址上,否则,不做任何处理。这种是乐观锁的思想。

CAS解析

源码解析

CAS操作在JUC中大量用到,在解析AQS那章中,我们也有提到。再回头看一下AQS中CAS的操作

protected final boolean compareAndSetState(int expect, int update) {
        return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
    }

这里是对AQS中state变量进行的CAS操作,要知道,很多同步类都是通过这个变量来实现线程安全的,所以在AQS中,首先要保证对state的赋值是线程安全的。

在java中,不论什么操作,只要他还是在Java api级别,就不能保证他一定是线程安全的,除非这个操作调用系统资源来支持。这里保证state线程安全是通过unsafe中的compareAndSwapInt方法来实现的,里面的参数stateOffset就是内存地址(V),expect是预期值(A),新值(B)。在unsafe中,大部分方法都是native的,而且unsafe可以直接操作系统的内存资源,不受jvm限制,通过它来保证线程安全,应该是稳了,但是unsafe类官方是不建议用的,咱们平时开发大部分时候也用不着,需要的操作,jdk已经帮我们封装好了。

CAS的问题

CAS虽然看起来很完美,可以在原子级别保证一个变量的线程安全,但是它有时候也会出问题,比如著名的ABA问题。

ABA问题:我们都知道CAS操作是先比较A的预期值和内存地址中的值是否相同,如果相同就认为此时没有其他线程修改A值,但是一定是这样吗?假如一个线程读取到A值,此时有另外一个线程将A值改成了B,然后又将B改回了A,这时比较A和预期值是相同的,就认为A值没有被改变过。为了解决ABA的问题,可以使用版本号,每次修改变量,都在这个变量的版本号上加1,这样,刚刚A->B->A,虽然A的值没变,但是它的版本号已经变了,再判断版本号就会发现此时的A已经被别人偷偷改过了。

CAS还有一个性能问题,在大部分使用CAS的时候,都是配合自旋来使用,这里的自旋,你可以理解为for(;;)这样的无限循环,我们在jdk源码中找一处来看看

public final int getAndSet(int newValue) {
        for (;;) {
            int current = get();
            if (compareAndSet(current, newValue))
                return current;
        }
    }

这AtomicInteger类中getAndSet方法,这是jdk1.7中的代码,在1.8中换成了另外一种写法,意思都是自旋加CAS,jdk1.7中自旋在AtomicInteger里,而jdk1.8调用了unsafe中getAndSetInt方法,在这个方法中自旋,有兴趣的话可以去看看1.8中的源码。

平时我们开发过程中,如果碰到系统蹦了,大部分人可能第一时间就会想到代码里是不是出现死循环了,当出现死循环时,会占用系统大量资源,造成系统崩溃。在这里我们看到源码中的自旋就是当CAS成功时,才会return。当然也不会出现CAS一直失败的情况,那几率也太小了。因此CAS带来的性能问题也是需要考虑的。但是从某种意思上来说,这个自旋也是CAS的优势,自旋算是一种非阻塞算法,相对于其他阻塞算法而已,非阻塞是不需要cpu切换时间片保存上下文的,节省了大量性能消耗。

结论

CAS是一种无锁解决并发问题的手段,解决了锁引起线程切换带来的性能问题。

原文  https://segmentfault.com/a/1190000021537113
正文到此结束
Loading...