还在用Synchronized？Atomic你了解不？

时间  2019-11-10
标签 还在 synchronized atomic 了解 栏目 Java 繁體版
原文   原文链接

前言

只有光头才能变强java

以前已经写过多线程相关的文章了，有兴趣的同窗能够去了解一下：git

多线程文章

在阅读《阿里巴巴 Java开发手册》读后感时，还有未解决的问题：github

若是是count++操做，使用以下类实现: AtomicInteger count = new AtomicInteger(); count.addAndGet(1);若是是 JDK8，推荐使用 LongAdder 对象，比 AtomicLong 性能更好(减小乐观锁的重试次数)。算法

以前在学习的时候也看过AtomicInteger类不少次了，一直没有去作相关的笔记。如今遇到问题了，因而就过来写写笔记，并但愿在学习的过程当中解决掉问题。编程

1、基础铺垫

首先咱们来个例子：数组

public class AtomicMain {

    public static void main(String[] args) throws InterruptedException {

        ExecutorService service = Executors.newCachedThreadPool();

        Count count = new Count();
        // 100个线程对共享变量进行加1
        for (int i = 0; i < 100; i++) {
            service.execute(() -> count.increase());
        }

        // 等待上述的线程执行完
        service.shutdown();
        service.awaitTermination(1, TimeUnit.DAYS);


        System.out.println("公众号：Java3y---------");
        System.out.println(count.getCount());
    }

}

class Count{

    // 共享变量
    private Integer count = 0;
    public Integer getCount() {
        return count;
    }
    public  void increase() {
        count++;
    }
}

大家猜猜得出的结果是多少？是100吗？安全

多运行几回能够发现：结果是不肯定的，多是95，也多是98，也多是100多线程

结果不肯定

根据结果咱们得知：上面的代码是线程不安全的！若是线程安全的代码，屡次执行的结果是一致的！并发

咱们能够发现问题所在：count++并不是原子操做。由于count++须要通过读取-修改-写入三个步骤。举个例子：高并发

  • 若是某一个时刻：线程A读到count的值是10，线程B读到count的值也是10
  • 线程A对count++，此时count的值为11
  • 线程B对count++，此时count的值也是11(由于线程B读到的count是10)
  • 因此到这里应该知道为啥咱们的结果是不肯定了吧。

要将上面的代码变成线程安全的(每次得出的结果是100)，那也很简单，毕竟咱们是学过synchronized锁的人：

  • 在increase()加synchronized锁就行了
public synchronized void increase() {
    count++;
}

不管执行多少次，得出的都是100：

结果都是100

从上面的代码咱们也能够发现，只作一个++这么简单的操做，都用到了synchronized锁，未免有点小题大作了。

  • Synchronized锁是独占的，意味着若是有别的线程在执行，当前线程只能是等待！

因而咱们原子变量的类就登场了！

1.2CAS再来看看

在写文章以前，本觉得对CAS有必定的了解了(由于以前已经看过相关概念，觉得本身理解了)..但真正敲起键盘写的时候，仍是发现没彻底弄懂...因此再来看看CAS吧。

来源维基百科：

比较并交换(compare and swap, CAS)，是原子操做的一种，可用于在多线程编程中实现不被打断的数据交换操做，从而避免多线程同时改写某一数据时因为执行顺序不肯定性以及中断的不可预知性产生的数据不一致问题。 该操做经过将内存中的值与指定数据进行比较，当数值同样时将内存中的数据替换为新的值。

CAS有3个操做数：

  • 内存值V
  • 旧的预期值A
  • 要修改的新值B

当多个线程尝试使用CAS同时更新同一个变量时，只有其中一个线程能更新变量的值(A和内存值V相同时，将内存值V修改成B)，而其它线程都失败，失败的线程并不会被挂起，而是被告知此次竞争中失败，并能够再次尝试(或者什么都不作)。

咱们画张图来理解一下：

CAS理解

咱们能够发现CAS有两种状况：

  • 若是内存值V和咱们的预期值A相等，则将内存值修改成B，操做成功！
  • 若是内存值V和咱们的预期值A不相等，通常也有两种状况：
    • 重试(自旋)
    • 什么都不作

咱们再继续往下看，若是内存值V和咱们的预期值A不相等时，应该何时重试，何时什么都不作。

1.2.1CAS失败重试(自旋)

好比说，我上面用了100个线程，对count值进行加1。咱们都知道：若是在线程安全的状况下，这个count值最终的结果必定是为100的。那就意味着：每一个线程都会对这个count值实质地进行加1。

我继续画张图来讲明一下CAS是如何重试(循环再试)的：

CAS循环重试

上面图只模拟出两个线程的状况，但足够说明问题了。

1.2.2CAS失败什么都不作

上面是每一个线程都要为count值加1，但咱们也能够有这种状况：将count值设置为5

我也来画个图说明一下：

CAS失败什么都不作

理解CAS的核心就是：CAS是原子性的，虽然你可能看到比较后再修改(compare and swap)以为会有两个操做，但终究是原子性的！

2、原子变量类简单介绍

原子变量类在java.util.concurrent.atomic包下，整体来看有这么多个：

原子变量类

咱们能够对其进行分类：

  • 基本类型：
    • AtomicBoolean：布尔型
    • AtomicInteger：整型
    • AtomicLong：长整型
  • 数组：
    • AtomicIntegerArray：数组里的整型
    • AtomicLongArray：数组里的长整型
    • AtomicReferenceArray：数组里的引用类型
  • 引用类型：
    • AtomicReference：引用类型
    • AtomicStampedReference：带有版本号的引用类型
    • AtomicMarkableReference：带有标记位的引用类型
  • 对象的属性：
    • AtomicIntegerFieldUpdater：对象的属性是整型
    • AtomicLongFieldUpdater：对象的属性是长整型
    • AtomicReferenceFieldUpdater：对象的属性是引用类型
  • JDK8新增DoubleAccumulator、LongAccumulator、DoubleAdder、LongAdder
    • 是对AtomicLong等类的改进。好比LongAccumulator与LongAdder在高并发环境下比AtomicLong更高效。

Atomic包里的类基本都是使用Unsafe实现的包装类。

Unsafe里边有几个咱们喜欢的方法(CAS)：

// 第一和第二个参数表明对象的实例以及地址，第三个参数表明指望值，第四个参数表明更新值
public final native boolean compareAndSwapObject(Object var1, long var2, Object var4, Object var5);

public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);

public final native boolean compareAndSwapLong(Object var1, long var2, long var4, long var6);

从原理上概述就是：Atomic包的类的实现绝大调用Unsafe的方法，而Unsafe底层其实是调用C代码，C代码调用汇编，最后生成出一条CPU指令cmpxchg，完成操做。这也就为啥CAS是原子性的，由于它是一条CPU指令，不会被打断。

2.1原子变量类使用

既然咱们上面也说到了，使用Synchronized锁有点小题大做了，咱们用原子变量类来改一下：

class Count{

    // 共享变量(使用AtomicInteger来替代Synchronized锁)
    private AtomicInteger count = new AtomicInteger(0);
    
    public Integer getCount() {
        return count.get();
    }
    public void increase() {
        count.incrementAndGet();
    }
}


// Main方法仍是如上

修改完，不管执行多少次，咱们的结果永远是100！

其实Atomic包下原子类的使用方式都不会差太多，了解原子类各类类型，看看API，基本就会用了(网上也写得比较详细，因此我这里果断偷懒了)...

2.2ABA问题

使用CAS有个缺点就是ABA的问题，什么是ABA问题呢？首先我用文字描述一下：

  • 如今我有一个变量count=10，如今有三个线程，分别为A、B、C
  • 线程A和线程C同时读到count变量，因此线程A和线程C的内存值和预期值都为10
  • 此时线程A使用CAS将count值修改为100
  • 修改完后，就在这时，线程B进来了，读取获得count的值为100(内存值和预期值都是100)，将count值修改为10
  • 线程C拿到执行权，发现内存值是10，预期值也是10，将count值修改为11

上面的操做均可以正常执行完的，这样会发生什么问题呢？？线程C没法得知线程A和线程B修改过的count值，这样是有风险的。

下面我再画个图来讲明一下ABA的问题(以链表为例)：

CAS ABA的问题讲解

2.3解决ABA问题

要解决ABA的问题，咱们可使用JDK给咱们提供的AtomicStampedReference和AtomicMarkableReference类。

AtomicStampedReference：

An {@code AtomicStampedReference} maintains an object referencealong with an integer "stamp", that can be updated atomically.

简单来讲就是在给为这个对象提供了一个版本，而且这个版本若是被修改了，是自动更新的。

原理大概就是：维护了一个Pair对象，Pair对象存储咱们的对象引用和一个stamp值。每次CAS比较的是两个Pair对象

// Pair对象
    private static class Pair<T> {
        final T reference;
        final int stamp;
        private Pair(T reference, int stamp) {
            this.reference = reference;
            this.stamp = stamp;
        }
        static <T> Pair<T> of(T reference, int stamp) {
            return new Pair<T>(reference, stamp);
        }
    }

    private volatile Pair<V> pair;

	// 比较的是Pari对象
    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)));
    }

由于多了一个版本号比较，因此就不会存在ABA的问题了。

2.4LongAdder性能比AtomicLong要好

若是是 JDK8，推荐使用 LongAdder 对象，比 AtomicLong 性能更好(减小乐观锁的重试次数)。

去查阅了一些博客和资料，大概的意思就是：

  • 使用AtomicLong时，在高并发下大量线程会同时去竞争更新同一个原子变量，可是因为同时只有一个线程的CAS会成功，因此其余线程会不断尝试自旋尝试CAS操做，这会浪费很多的CPU资源。
  • 而LongAdder能够归纳成这样：内部核心数据value分离成一个数组(Cell)，每一个线程访问时,经过哈希等算法映射到其中一个数字进行计数，而最终的计数结果，则为这个数组的求和累加。
    • 简单来讲就是将一个值分散成多个值，在并发的时候就能够分散压力，性能有所提升。

参考资料：

最后

参考资料：

若是你以为我写得还不错，了解一下：

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程