Java中的CAS和ABA问题说明

目录
  • 1.CAS
    • 1)CAS概念
    • 2)CAS产生的影响(无锁执行)
    • 3)Automic并发类CAS原理代码分析
    • 4)CAS导致的ABA问题

1.CAS

1)CAS概念

CAS时Compare And Swap缩写,即比较与交换是用于实现多线程同步的原子指令,它将内存位置的内容与给定值相比较,相同则修改内存位置的值为新值,而整个操作是调用的UnSafe的compareAndSwapObject、compareAndSwapInt或者compareAndSwapLong完成的,而这些方法都是native修饰的本地方法,是一种系统原语系统支持的操作。

2)CAS产生的影响(无锁执行)

CAS是一种无锁对象的原子操作,锁分为乐观锁和悲观锁,乐观派抱着几乎不会发生修改同一资源的状态,任意操作同意对象资源,如果遇到修改同一资源的情况,资源不会修改成功,能够保证资源的安全,而悲观派会认为同一资源被错误修改后会造成不可挽回的局面,故自能有一个线程修改资源,这样总会对系统性能产生一定的影响,拖慢自行速度,CAS即无锁执行者,被CAS修饰过的资源可以同时被多个线程修改依然能保证系统安全,无锁不需要等待提高系统性能,jdk提供的CAS原理实现的并发类Automic系列运用及其原理介绍。

3)Automic并发类CAS原理代码分析

首先介绍java的指针操作类UnSafe,Unsafe类是在sun.misc包下,不属于Java标准。但是很多Java的基础类库,包括一些被广泛使用的高性能开发库都是基于Unsafe类开发的,因为UnSafe使Java像C语言一样使其拥有操作内存指针的能力,因为操作内存指针容易出错,故起名UnSafe不安全的类,因此Java官方并不建议使用的,但CAS原理就是UnSafe类中的compareAndSwapObject、compareAndSwapInt和compareAndSwapLong方法实现的,该方法需传入四个参数:第一个参数代表给定的对象,第二个参数代表给定对象再内存中的偏移量,第三个参数标识对象的期望值,第四个参数标识要修改的值,并发保重的Automic系列的原子操作类都是使用UnSafe类实现的。

UnSafe源码如下:

/**
* 第一个参数var1代表给定对象,第二个参数var2代表var1对象在内存中的偏移量,第三个参数var3为期望修改* 的对象旧值,第四个参数var4代表要修改的值或着说是修改后的值。
**/
public final native boolean compareAndSwapObject(Object var1, long var2, Object var3, Object var4);
    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);

举例AtomicInteger源码实现原理:

AutomicInteger中的getAndSet实现原理解析:

    /**
    * 调用的UnSafe的getAndSetInt方法,给定值和偏移量和修改的值,
    * 获取修改的值var5作为compareAndSwapInt的第三个参数用来和var1比较相同则执行更新操作
    * while循环知道操作成功。
    *public final int getAndSetInt(Object var1, long var2, int var4) {
    *   int var5;
    *   do {
    *       var5 = this.getIntVolatile(var1, var2);
    *   } while(!this.compareAndSwapInt(var1, var2, var5, var4));
    *
    *    return var5;
    *}
    **/
    public final int getAndSet(int newValue) {
        return unsafe.getAndSetInt(this, valueOffset, newValue);
    }
package java.util.concurrent.atomic;
import java.util.function.IntUnaryOperator;
import java.util.function.IntBinaryOperator;
import sun.misc.Unsafe;

public class AtomicInteger extends Number implements java.io.Serializable {
    private static final long serialVersionUID = 6214790243416807050L;

    // 获取UnSafe对象实例
    private static final Unsafe unsafe = Unsafe.getUnsafe();
    //对象在内存中的偏移量
    private static final long valueOffset;

    //初始化valueOffset
    static {
        try {
            valueOffset = unsafe.objectFieldOffset
                (AtomicInteger.class.getDeclaredField("value"));
        } catch (Exception ex) { throw new Error(ex); }
    }

    //对象属性值
    private volatile int value;

    public AtomicInteger(int initialValue) {
        value = initialValue;
    }

    public AtomicInteger() {
    }

    /**
    * 调用的UnSafe的getAndSetInt方法,给定值和偏移量和修改的值,
    * 获取修改的值var5作为compareAndSwapInt的第三个参数用来和var1比较相同则执行更新操作
    * while循环知道操作成功。
    *public final int getAndSetInt(Object var1, long var2, int var4) {
    *   int var5;
    *   do {
    *       var5 = this.getIntVolatile(var1, var2);
    *   } while(!this.compareAndSwapInt(var1, var2, var5, var4));
    *
    *    return var5;
    *}
    **/
    public final int getAndSet(int newValue) {
        return unsafe.getAndSetInt(this, valueOffset, newValue);
    }

    //调用UnSafe的compareAndSwapInt方法保证CAS
    public final boolean compareAndSet(int expect, int update) {
        return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
    }

    //调用UnSafe的compareAndSwapInt方法保证CAS
    public final boolean weakCompareAndSet(int expect, int update) {
        return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
    }

    //调用UnSafe的getAndAddInt再调用UnSafe的getAndSetInt方法保证CAS
    public final int getAndIncrement() {
        return unsafe.getAndAddInt(this, valueOffset, 1);
    }

    public final int getAndDecrement() {
        return unsafe.getAndAddInt(this, valueOffset, -1);
    }
    .........
}

4)CAS导致的ABA问题

操作对象,获取对象后,执行CAS操作前,被其他线程修改后,且又修改为原来的对象值,导致CAS忽略其他线程的修改,成功执行CAS对象修改,这种情况就叫做ABA问题。

下图所示:

解决办法:

AtomicStampedReference类提供了解决办法,在对象之中又添加了stamp时间戳属性避免其他线程修改了多次并变回修改前的value值,但对比stamp不同便可知道对象是被修改过的,只有提供属性值和stamp时间戳相等才能成功执行CAS修改操作,里面包裹了一个键值对对象AtomicStampedReference.Pair<V> pair类型,pair中值为属性值,value为stamp时间戳,在执行CAS操作时需要提供原值的value和时间戳都相等的情况才能成功执行CAS操作。

AtomicMarkableReference类提供了解决办法,在对象之中又添加了stamp时间戳属性避免其他线程修改了多次并变回修改前的value值,但对比stamp不同便可知道对象是被修改过的,只有提供属性值和boolean类型的mark标记相等才能成功执行CAS修改操作,里面包裹了一个键值对对象AtomicMarkableReference.Pair<V> pair类型,pair中值为属性值,value为mark是否被修改的标记,在执行CAS操作时需要提供原值的value和mark标记都相等的情况才能成功执行CAS操作。

本文只介绍AtomicStampedReference类的源码分析,AtomicMarkableReference类同AtomicStampedReference类原理一样,

源码如下:

package java.util.concurrent.atomic;
public class AtomicStampedReference<V> {
   /**
    * 对象值时一个AtomicStampedReference内置对象Pair,包裹了reference和stamp两个属性
    */
    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;

    /**
     * 初始化对象并初始化pair
     */
    public AtomicStampedReference(V initialRef, int initialStamp) {
        pair = Pair.of(initialRef, initialStamp);
    }

    /**
     * 比较当前对象属性值和输入原始值为真,在比较当前对象的时间stamp与期望的stamp进行比较
     * 如果也想等,就更新值和stamp
     * @param expectedReference 原始值
     * @param newReference 新值
     * @param expectedStamp 期望时间
     * @param newStamp 新时间
     * @return {@code true} if successful
     */
    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)));
    }

    // Unsafe mechanics

    private static final sun.misc.Unsafe UNSAFE = sun.misc.Unsafe.getUnsafe();
    private static final long pairOffset =
        objectFieldOffset(UNSAFE, "pair", AtomicStampedReference.class);

    private boolean casPair(Pair<V> cmp, Pair<V> val) {
        return UNSAFE.compareAndSwapObject(this, pairOffset, cmp, val);
    }

    static long objectFieldOffset(sun.misc.Unsafe UNSAFE,
                                  String field, Class<?> klazz) {
        try {
            return UNSAFE.objectFieldOffset(klazz.getDeclaredField(field));
        } catch (NoSuchFieldException e) {
            // Convert Exception to corresponding Error
            NoSuchFieldError error = new NoSuchFieldError(field);
            error.initCause(e);
            throw error;
        }
    }
}

以上为个人经验,希望能给大家一个参考,也希望大家多多支持我们。

(0)

相关推荐

  • 分析ABA问题的本质及其解决办法

    简介 CAS的原理其实很简单,为了保证在多线程环境下我们的更新是符合预期的,或者说一个线程在更新某个对象的时候,没有其他的线程对该对象进行修改.在线程更新某个对象(或值)之前,先保存更新前的值,然后在实际更新的时候传入之前保存的值,进行比较,如果一致的话就进行更新,否则失败. 注意,CAS在java中是用native方法来实现的,利用了系统本身提供的原子性操作. 那么CAS在使用中会有什么问题呢?一般来说CAS如果设计的不够完美的话,可能会产生ABA问题,而ABA问题又可以分为两类,我们先看来看

  • 全面了解Java中的CAS机制

    前言 在看到Java锁机制的时候,无意中看到了CAS这个词,然后在百度查找CAS看了很多文章始终没有看的太懂,今天又在Google上查找了一些资料,才算是真正弄清楚了CAS机制. 什么是CAS 在jdk 1.5中增加的一个最主要的支持是Atomic类,比如说AtomicInteger, AtomicLong,这些类可帮助最大限度地减少在多线程中对于一些基本操作(例如,增加或减少多个线程之间共享的值)的复杂性.而这些类的实现都依赖于CAS(compare and swap)的算法. 乐观锁和悲观锁

  • Java并发的CAS原理与ABA问题的讲解

    CAS原理 在计算机科学中,比较和交换(Compare And Swap)是用于实现多线程同步的原子指令. 它将内存位置的内容与给定值进行比较,只有在相同的情况下,将该内存位置的内容修改为新的给定值. 这是作为单个原子操作完成的. 原子性保证新值基于最新信息计算; 如果该值在同一时间被另一个线程更新,则写入将失败. 操作结果必须说明是否进行替换; 这可以通过一个简单的布尔响应(这个变体通常称为比较和设置),或通过返回从内存位置读取的值来完成(摘自维基本科) CAS流程 以AtomicIntege

  • 浅谈Java中ABA问题及避免

    本文主要研究的是关于Java中ABA问题及避免的相关内容,具体如下. 在<Java并发实战>一书的第15章中有一个用原子变量实现的并发栈,代码如下: public class Node { public final String item; public Node next; public Node(String item){ this.item = item; } } public class ConcurrentStack { AtomicReference<Node> top

  • 详解java 中的CAS与ABA

    1. 独占锁: 属于悲观锁,有共享资源,需要加锁时,会以独占锁的方式导致其它需要获取锁才能执行的线程挂起,等待持有锁的钱程释放锁.传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁.Java中synchronized和ReentrantLock等独占锁就是悲观锁的思想. 1.1 乐观锁的操作 多线程并发修改一个值时的实现: public class SimulatedCAS { //加volatile的目的是利用其happens-before原则

  • Java中的CAS和ABA问题说明

    目录 1.CAS 1)CAS概念 2)CAS产生的影响(无锁执行) 3)Automic并发类CAS原理代码分析 4)CAS导致的ABA问题 1.CAS 1)CAS概念 CAS时Compare And Swap缩写,即比较与交换是用于实现多线程同步的原子指令,它将内存位置的内容与给定值相比较,相同则修改内存位置的值为新值,而整个操作是调用的UnSafe的compareAndSwapObject.compareAndSwapInt或者compareAndSwapLong完成的,而这些方法都是nati

  • 详解Java中的悲观锁与乐观锁

    一.悲观锁 悲观锁顾名思义是从悲观的角度去思考问题,解决问题.它总是会假设当前情况是最坏的情况,在每次去拿数据的时候,都会认为数据会被别人改变,因此在每次进行拿数据操作的时候都会加锁,如此一来,如果此时有别人也来拿这个数据的时候就会阻塞知道它拿到锁.在Java中,Synchronized和ReentrantLock等独占锁的实现机制就是基于悲观锁思想.在数据库中也经常用到这种锁机制,如行锁,表锁,读写锁等,都是在操作之前先上锁,保证共享资源只能给一个操作(一个线程)使用. 由于悲观锁的频繁加锁,

  • 浅析从同步原语看非阻塞同步以及Java中的应用

    一.从硬件原语上理解同步(非特指Java) 同步机制是多处理机系统的重要组成部分,其实现方式除了关系到计算的正确性之外还有效率的问题.同步机制的实现通常是在硬件提供的同步指令的基础上,在通过用户级别软件例程实现的.上面说到的乐观策略实际上就是建立在硬件指令集的基础上的(我们需要实际操作和冲突检测是原子性的),一般有下面的常用指令:测试并设置(test_and_set).获取并增加(fetch_and_increment).原子交换(Atomic_Exchange).比较并交换(CAS).加载连接

  • 关于Java 并发的 CAS

    目录 一.为什么要无锁 二.什么是CAS? 三.Java 中的CAS 四.CAS存在的问题 1.自旋的劣势 2.ABA 问题 3.尝试应用 4.CAS 源码 一.为什么要无锁 我们一想到在多线程下保证安全的方式头一个要拎出来的肯定是锁,不管从硬件.操作系统层面都或多或少在使用锁.锁有什么缺点吗?当然有了,不然 JDK 里为什么出现那么多各式各样的锁,就是因为每一种锁都有其优劣势. 使用锁就需要获得锁.释放锁,CPU 需要通过上下文切换和调度管理来进行这个操作,对于一个 「独占锁」 而言一个线程在

  • 详解Java中的ReentrantLock锁

    ReentrantLock锁 ReentrantLock是Java中常用的锁,属于乐观锁类型,多线程并发情况下.能保证共享数据安全性,线程间有序性 ReentrantLock通过原子操作和阻塞实现锁原理,一般使用lock获取锁,unlock释放锁, 下面说一下锁的基本使用和底层基本实现原理,lock和unlock底层 lock的时候可能被其他线程获得所,那么此线程会阻塞自己,关键原理底层用到Unsafe类的API: CAS和park 使用 java.util.concurrent.locks.R

  • 基于java中cas实现的探索

    目录 1.背景简介 2. java源码追踪 3. hotspot jvm源码追踪 4. 手写一个cas实现 1. 通过汇编手写一个cas方法 2. 多线程条件下测试自行实现的cas方法 3. cas与互斥锁方式的对比 4. 结论 5. 思考 1.背景简介 当我们在并发场景下,增加某个integer值的时,就涉及到多线程安全的问题,解决思路两个 将值增加的方法使用同步代码块同步 使用AtomicInteger,来逐步增加其值 这两种实现方式代码如下 import java.util.concurr

随机推荐