还在用Synchronized？Atomic你了解不？

前言

只有光头才能变强

之前已经写过多线程相关的文章了，有兴趣的同学可以去了解一下：

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

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

之前在学习的时候也看过AtomicInteger类很多次了，一直没有去做相关的笔记。现在遇到问题了，于是就过来写写笔记，并希望在学习的过程中解决掉问题。

一、基础铺垫

首先我们来个例子：


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：

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

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

于是我们原子变量的类就登场了！

1.2CAS再来看看

在写文章之前，本以为对CAS有一定的了解了(因为之前已经看过相关概念，以为自己理解了)..但真正敲起键盘写的时候，还是发现没完全弄懂...所以再来看看CAS吧。

来源维基百科：

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

CAS有3个操作数：

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

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

我们画张图来理解一下：

我们可以发现CAS有两种情况：

  • 如果内存值V和我们的预期值A相等，则将内存值修改为B，操作成功！
  • 如果内存值V和我们的预期值A不相等，一般也有两种情况：
    • 重试(自旋)
    • 什么都不做

我们再继续往下看，如果内存值V和我们的预期值A不相等时，应该什么时候重试，什么时候什么都不做。

1.2.1CAS失败重试(自旋)

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

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

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

1.2.2CAS失败什么都不做

上面是每个线程都要为count值加1，但我们也可以有这种情况：将count值设置为5

我也来画个图说明一下：

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

二、原子变量类简单介绍

原子变量类在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的问题(以链表为例)：

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)，每个线程访问时,通过哈希等算法映射到其中一个数字进行计数，而最终的计数结果，则为这个数组的求和累加。
    • 简单来说就是将一个值分散成多个值，在并发的时候就可以分散压力，性能有所提高。

参考资料：

最后

参考资料：

如果你觉得我写得还不错，了解一下：

原文地址：https://www.cnblogs.com/Java3y/p/10000999.html

时间： 2024-11-29 10:15:47

还在用Synchronized？Atomic你了解不？的相关文章

锁的原理：final、volatile、ThreadLocal、synchronized、Atomic（自己整理）

锁 原理 使用场景 final volatile ThreadLocal synchronized Atomic 原文地址:https://www.cnblogs.com/cag2050/p/12408266.html

Java中的synchronized、volatile、ReenTrantLock、AtomicXXX

多线程和并发性并不是什么新内容,但是 Java 语言设计中的创新之一就是,它是第一个直接把跨平台线程模型和正规的内存模型集成到语言中的主流语言.核心类库包含一个 Thread 类,可以用它来构建.启动和操纵线程,Java 语言包括了跨线程传达并发性约束的构造 -- synchronized 和 volatile .在简化与平台无关的并发类的开发的同时,它决没有使并发类的编写工作变得更繁琐,只是使它变得更容易了. synchronized 快速回顾 把代码块声明为 synchronized,有两个

Java synchronized详解

Java synchronized详解 第一篇: 使用synchronized 在编写一个类时,如果该类中的代码可能运行于多线程环境下,那么就要考虑同步的问题.在Java中内置了语言级的同步原语--synchronized,这也大大简化了Java中多线程同步的使用.我们首先编写一个非常简单的多线程的程序,是模拟银行中的多个线程同时对同一个储蓄账户进行存款.取款操作的. 在程序中我们使用了一个简化版本的Account类,代表了一个银行账户的信息.在主程序中我们首先生成了1000个线程,然后启动它们

（转）synchronized用法

转自:http://javacrazyer.iteye.com/blog/759300/ synchronized 关键字,代表这个方法加锁,相当于不管哪一个线程A每次运行到这个方法时,都要检查有没有其它正在用这个方法的线程B(或者C D等),有的话要等正在使用这个方法的线程B(或者C D)运行完这个方法后再运行此线程A,没有的话,直接运行 它包括两种用法:synchronized 方法和 synchronized 块. 1. synchronized 方法:(相当于 synchronized(

synchronized 详细分析

Java语言的关键字,当它用来修饰一个方法或者一个代码块的时候,能够保证在同一时刻最多只有一个线程执行该段代码. 一.当两个并发线程访问同一个对象object中的这个synchronized(this)同步代码块时,一个时间内只能有一个线程得到执行.另一个线程必须等待当前线程执行完这个代码块以后才能执行该代码块. 二.然而,当一个线程访问object的一个synchronized(this)同步代码块时,另一个线程仍然可以访问该object中的非synchronized(this)同步代码块.

Java关键字synchronized详解

Java关键字synchronized详解 博客分类: Java综合 Java多线程thread互联网制造 synchronized 关键字,代表这个方法加锁,相当于不管哪一个线程A每次运行到这个方法时,都要检查有没有其它正在用这个方法的线程B(或者C D等),有的话要等正在使用这个方法的线程B(或者C D)运行完这个方法后再运行此线程A,没有的话,直接运行 它包括两种用法:synchronized 方法和 synchronized 块. 1. synchronized 方法: 通过在方法声明中

synchronized的使用方法

synchronized 关键字,它包括两种用法:synchronized 方法和 synchronized 块.  1. synchronized 方法:通过在方法声明中加入 synchronized关键字来声明 synchronized 方法.如:  public synchronized void accessVal(int newVal);  synchronized 方法控制对类成员变量的访问:每个类实例对应一把锁,每个 synchronized 方法都必须获得调用该方法的类实例的锁方

Java多线程总结之由synchronized说开去(转)

这几天不断添加新内容,给个大概的提纲吧,方面朋友们阅读,各部分是用分割线隔开了的: synchronized与wait()/notify() JMM与synchronized ThreadLocal与synchronized ReentrantLock与synchronized 最重要一条: synchronized是针对对象的隐式锁使用的,注意是对象! 举个小例子,该例子没有任何业务含义,只是为了说明synchronized的基本用法: Java代码   Class MyClass(){ sy

Java中的ReentrantLock和synchronized两种锁定机制的对比

多线程和并发性并不是什么新内容,但是 Java 语言设计中的创新之一就是,它是第一个直接把跨平台线程模型和正规的内存模型集成到语言中的主流语言.核心类库包含一个 Thread 类,可以用它来构建.启动和操纵线程,Java 语言包括了跨线程传达并发性约束的构造 —— synchronized 和 volatile .在简化与平台无关的并发类的开发的同时,它决没有使并发类的编写工作变得更繁琐,只是使它变得更容易了. synchronized 快速回顾 把代码块声明为 synchronized,有两个