Java原子化读并且写操作中存在的问题

标签: Java

保留所有版权,请引用而不是转载本文(原文地址 https://yeecode.top/blog/21/ )。

背景

之前的文章中我们已经讲过,Java的AtomicInteger类中能够将读和写封装成为一个原子操作,例如其中的getAndIncrement()方法就可以实现原子化的i++操作。这一切的实现是通过系统原生的CAS操作实现的。

CAS操作即比较并交换操作,能够在内存真值与预期原值一样时,将新值放入指定的内存中。

本文我们探讨基于CAS操作实现的读写原子化中引发的问题。

CAS存在的问题

CAS实现了高效的原子操作,但是仍然存在一些问题,主要有三个:

ABA问题

因为CAS需要在操作值的时候检查下值有没有发生变化,如果没有发生变化则更新,但是如果一个值原来是A,变成了B,又变成了A,那么使用CAS进行检查时会发现它的值没有发生变化,认为情况还是乐观的。此时可能引发错误。

例如,时刻t1在队列中CAS操作前获取预期原值A=5,之后队列发生了移动,再次获取的原值仍然为5,此时进行了CAS操作。则会引发错误。

【1-3】 ABA问题的解决思路就是使用版本号。在变量前面追加上版本号,每次变量更新的时候把版本号加一,那么A-B-A 就会变成1A-2B-3A。Java1.5开始,atomic包中存在一个AtomicStampedReference类来解决ABA问题。 该类的compareAndSet方法会先检查当前引用是否发生变化,如果没有变化才会使用CAS更新其值。

源代码如下:

public boolean compareAndSet(V   expectedReference,
                                 V   newReference,
                                 int expectedStamp,
                                 int newStamp) {
        Pair<V> current = pair;
        return
            expectedReference == current.reference &&
            expectedStamp == current.stamp &&
            ((newReference == current.reference &&
              newStamp == current.stamp) ||
             casPair(current, Pair.of(newReference, newStamp)));
    }

循环开销问题

因为CAS是基于乐观锁的思想的,需要不断判断乐观情况是否成立,因此是一个循环操作,常被称为CAS自旋。如果并发严重,则CAS自旋会不断尝试,导致CPU开销大。

解决此问题的办法是在多次CAS操作失败时,能够暂停一段时间,在进行CAS操作。防止在其他线程密集修改某变量时对该变量不断进行CAS自旋。当然,这需要JVM的支持。

无法应用于多个共享变量

对一个共享变量进行CAS操作时可以的,那如果对一组变量展开操作呢?显然是不可以的,因为内存位置V是一个值,而非一组值。这个时候只能使用锁。

其实,还有一个办法,即将这一组变量封装成一个对象,从而将对一组变量的操作转化为对一个对象的操作。Java1.5之后,便可以使用AtomicReference来封装一个需要原子化更新的对象。

总结

虽然,AtomicInteger类中的原子化操作存在一些问题,但是它与加同步锁的方法相比仍然在性能、易用性上具有巨大的优势。希望大家能够在日常的编码中掌握并使用AtomicInteger类中的相关方法,写出简洁、高效的代码。

本文首发于个人知乎:易哥(https://www.zhihu.com/people/yeecode),欢迎关注。

作者书籍推荐