前言:
如果不知道JMM(java 内存模型),还请看博主的上一篇博客: volatile关键字与内存可见性详解 ,因为本博客还需要JMM的理论基础。
CAS(Compare-And-Swap)是一种硬件对并发的支持,针对多处理器操作而设计的处理器中的一种特殊指令,用于管理对共享数据的并发访问. CAS 是一种无锁的非阻塞算法的实现。
以上是一本书给出的定义。其实我们在上篇博客已经提过CAS了,AtomicInteger 实现num++,AtomicInteger的底层就是用了CAS的思想。CAS是一条CPU并发原语.并且原语的执行必须是连续的,在执行过程中不允许中断,也即是说CAS是一条原子指令,不会造成所谓的数据不一致(线程安全)的问题.
2、CAS解决了什么问题
对于多线程而言,实现线程安全是最要的也是最基本的,我们之前通过同步锁synchronized()实现,它保证了线程安全,也就是数据的一致性,但是它的并发性下降,因为每次在都要对代码块进行加锁,线程得到锁才可以运行。但是CAS是一种无锁的非阻塞的算法实现,如果线程数不多(并发量小),他的性能要比synchronized()高的多,但是线程数过多,就会过分的消耗cpu资源(具体为啥后面会解释)。
3、CAS的原理
CAS 包含了 3 个操作数:
需要读写的内存值 V
进行比较的值 A
拟写入的新值 B
当且仅当 V 的值等于 A 时,CAS 通过原子方式用新值 B 来更新 V 的 值,否则不会执行任何操作。接下来用源码来验证以上理论。
3.1 atomic包中的类
且看AtomicInteger,AtomicInteger位于java.util.concurrent.atomic包下,如下图:(本图截取自JDK API 1.6中文版)
从上图可知道,atomic包下都是原子性的操作,原子性就是说无论是几行代码,要么这些代码一块执行,要么就不执行,中间不可以 加塞(比如还没执行完,发生线程调度),这就完美的解决num++线程不安全的问题。
3.2 根据atomicInteger.getAndIncrement()源码验证CAS理论
(1)从下面的代码可以看出,用到了Unsafe这个类,UnSafe类在sun.misc包中,UnSafe是CAS的核心类 ,由于Java 方法无法直接访问底层 ,需要通过本地(native)方法来访问,
基于该类可以直接操作特额定的内存数据,其内部方法操作可以像C的指针一样直接操作内存。
UnSafe类中所有的方法都是native修饰的,也就是说UnSafe类中的方法都是直接调用操作底层资源执行响应的任务
看到这里的value是用关键字volatile修饰的,保证了内存可见性
public class AtomicInteger extends Number implements java.io.Serializable {
private static final long serialVersionUID = 6214790243416807050L;
// setup to use Unsafe.compareAndSwapInt for updates
private static final Unsafe unsafe = Unsafe.getUnsafe();
private static final long valueOffset;
static {
try {
valueOffset = unsafe.objectFieldOffset
(AtomicInteger.class.getDeclaredField("value"));
} catch (Exception ex) { throw new Error(ex); }
}
private volatile int value;
2)如下面的代码:
unsafe.getAndAddInt(this, valueOffset, 1),传了三个参数,分别是当前对象this、该对象在内存中的偏移地址,还有表示每次都加1的数字1。其中UnSafe就是根据内存偏移地址获取数据的偏移地址
/**
* Atomically increments by one the current value.
*
* @return the previous value
*/
public final int getAndIncrement() {
return unsafe.getAndAddInt(this, valueOffset, 1);
}
3)如下代码,进入到方法getAndAddInt,发现是一个do while 循环,接下来进行说明:
var1 AtomicInteger对象本身
var2 该对象值的引用地址
var4 需要变动的数量
var5 是通过var1 var2找出内存中真实的值
this.compareAndSwapInt(var1, var2, var5, var5 + var4),表示的是该对象var1在内存中的偏移量var2位置的值与期望值var5进行比较,如果相同,更新var5+var4的值并且返回true,如果不同,继续循环,将期望值var5改为内存中真正的值,然后在进行比较,直到更新完成。
综上也体现出了它的缺点,就是如果线程过多,其他的线程可能会一直改内存中的实际值,那么期望值var5就会很难和内存中的实际值相等,这样就会导致一直循环,效率下降,所以如果线程多,并发大,用锁比较合适。
public final int getAndAddInt(Object var1, long var2, int var4) {
int var5;
do {
var5 = this.getIntVolatile(var1, var2); //其实就是从主存中取值
} while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));
return var5;
}
4)CAS原理分析
1.假设线程A和线程B两个线程同时执行getAndAddInt操作(分别在不同的CPU上)且AtomicInteger里面的value原始值为3,即主内存中AtomicInteger的value为3,根据JMM模型,线程A和线程B各自持有一份值为3的value的副本分别到各自的工作内存.
2.线程A通过getIntVolatile(var1,var2) 拿到value值3,这时线程A被挂起.线程B也通过getIntVolatile(var1,var2) 拿到value值3,
3.此时刚好线程B没有被挂起并执行compareAndSwapInt方法比较内存中的值也是3 ,成功修改内存的值为4 线程B走完收工 一切OK。
4.这时线程A恢复,执行compareAndSwapInt方法比较,发现自己手里的数值和内存中的数值4不一致,说明该值已经被其他线程抢先一步修改了,那A线程修改失败,只能重新来一遍了.
5.线程A重新获取value值,因为变量value是volatile修饰,所以其他线程对他的修改,线程A总是能够看到,线程A继续执行compareAndSwapInt方法进行比较替换,直到成功.
4、CAS的缺点
(1)根据上面所说的原理,如果并发量特别大或者说开启的线程数过多,就可能会存在内存中的共享的值经常被修改,导致unsafe底层匹配不成功,会一直do-while下去,加大了cpu 的压力
(2)只能保证一个共享变量的原子操作。(比如声明两个原子变量a和b 具体操作是a+b,此时只能枷锁了)
(3)引发ABA问题(狸猫换太子)
ABA问题举例:
场景1:
一个线程1从内存中取出A,这个时候另一个线程2也从内存中取出A,并且线程2进行了一些操作将值变成了B,线程1此时还被阻塞,线程2又进行了一些操作,然后将B又变成了A,此时线程1获得资源,开始执行,但是在进行cas操作的时候发现内存中还是A,然后线程1执行成功。(说白了就是可能存在一个线程根本不知道数值发生了变化)
场景2:
ABA问题:内存值V=100;
threadA 将100,改为50;
threadB 将100,改为50;
threadC 将50,改为100;
小牛取款,由于机器不太好使,多点了几次取款操作。后台threadA和threadB工作,此时threadA操作成功(100->50),threadB,取完值100,然后阻塞。正好牛妈打款50元给小牛(50->100),threadC执行成功,之后threadB运行了,又改为(100->50)。
牛气冲天,lz钱哪去了???
5、如何解决ABA问题:
对内存中的值加个版本号,在比较的时候除了比较值还的比较版本号。
AtomicStampedReference就是用版本号实现cas机制,再讲AtomicStampedReference之前,先讲解AtomicReference原子引用。
5.1 AtomicReference原子引用
AtomicReference和AtomicInteger非常类似,不同之处就在于AtomicInteger是对整数的封装,底层采用的是compareAndSwapInt实现CAS,比较的是数值是否相等,而AtomicReference则对应普通的对象引用,底层使用的是compareAndSwapObject实现CAS,比较的是两个对象的地址是否相等。也就是它可以保证你在修改对象引用时的线程安全性。我们可以自定义对象。
代码如下:
public class TestAtomic {
public static void main(String[] args) {
AtomicReference<User> atomicUser=new AtomicReference<>();
User zhangsan=new User("张三",21);
User lisi =new User("李四",25);
atomicUser.set(zhangsan);
System.out.println(atomicUser.compareAndSet(zhangsan,lisi)+"\t"+atomicUser.get().toString());
}
}
class User{
private String username;
private int age;
public User(String username,int age){
this.username=username;
this.age=age;
}
@Override
public String toString() {
return "User{" +
"username='" + username + '\'' +
", age=" + age +
'}';
}
public String getUsername() {
return username;
}
public void setUsername(String username) {
this.username = username;
}
public int getAge() {
return age;
}
public void setAge(int age) {
this.age = age;
}
}
执行结果:
// 分析:
定义了对象User,利用方法compareAndSet进行比较和判断,内存中存入了张三,然后和compareAndset的第一个参数进行比较,发现都是张三,然后修改为lisi。
5.2 版本号原子引用 AtomicStampedReference解决ABA 问题
AtomicStampedReference 增加了版本号,解决了ABA问题。
思想:
内存值V=100;
threadA 获取值100 版本号1,改为50 版本号2;
threadB 获取值100 版本号1
threadC 将50 版本号2 改为100 版本号3
场景:小牛取款,由于机器不太好使,多点了几次取款操作。后台threadA和threadB工作,此时threadA操作成功(100->50) 版本号1->版本号2,threadB取完值100,版本号是1,然后阻塞。正好牛妈打款50元给小牛(50->100) 版本号2->版本号3,threadC执行成功,之后threadB获取资源,开始执行,发现内存的值为100, 但是版本号不对应, 所以重新从内存中读取值,然后再进行判断。这次牛就不会冲天了,哈哈哈哈哈!
以上场景对应代码:
public class ABADemo {
// 表示内存里初始值是100,版本好号为1
private static AtomicStampedReference atomicStampedReference=new AtomicStampedReference(100,1);
public static void main(String[] args) {
new Thread(()->{
// 获得版本号
int stamp = atomicStampedReference.getStamp();
// 这里延迟一秒不是为了说为了线程阻塞,而是为了让线程B得到版本号
System.out.println(Thread.currentThread().getName()+"\t第一次版本号:"+stamp);
try { TimeUnit.SECONDS.sleep(1); } catch (InterruptedException e) { e.printStackTrace(); }
// 期望值为100 和内存中的值进行比较,如果一样,且版本号stamp也和内存中一样,则改为50
atomicStampedReference.compareAndSet(100,50,stamp,stamp+1);
System.out.println(Thread.currentThread().getName()+"\t第二次版本号:"+atomicStampedReference.getStamp());
// atomicStampedReference.compareAndSet(100,50,stamp,stamp+1);
},"A").start();
new Thread(()->{
// 获得版本号
int stamp = atomicStampedReference.getStamp();
System.out.println(Thread.currentThread().getName()+"\t第一次版本号:"+stamp);
// 线程阻塞
try { TimeUnit.SECONDS.sleep(3); } catch (InterruptedException e) { e.printStackTrace(); }
// 期望值为100 和内存中的值进行比较,如果一样,且版本号stamp也和内存中一样,则改为50
boolean result = atomicStampedReference.compareAndSet(100, 50, stamp, stamp + 1);
System.out.println(Thread.currentThread().getName()+"\t修改是否成功"+result+"\t当前实际版本号:"+atomicStampedReference.getStamp());
System.out.println("当前实际最新值:"+atomicStampedReference.getReference());
},"B").start();
new Thread(()->{
// 这里延迟两秒不是为了说为了线程阻塞,而是为了让线程A 执行完毕
try { TimeUnit.SECONDS.sleep(2); } catch (InterruptedException e) { e.printStackTrace(); }
// 获得版本号
int stamp = atomicStampedReference.getStamp();
System.out.println(Thread.currentThread().getName()+"\t第一次版本号:"+stamp);
// 期望值为100 和内存中的值进行比较,如果一样,且版本号stamp也和内存中一样,则改为50
atomicStampedReference.compareAndSet(50,100,stamp,stamp+1);
System.out.println(Thread.currentThread().getName()+"\t第二次版本号:"+atomicStampedReference.getStamp());
},"C").start();
}
}
运行结果: