本文主要是介绍【Java笔记】CAS比较的是什么+交换的是什么+自旋到啥时候,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
文章目录
- 什么是CAS
- CAS原理
- CAS的原子性
- CAS的三个问题
- 问题一:ABA
- 解决方法
- 问题二:CPU开销过大
- 解决方法
- 问题三:不能保证代码块的原子性
- 解决方法
- Reference
之前看CAS一致迷迷糊糊的,知道它通过自旋来避免多线程冲突,然后通过不断比较交换来不停自旋。
但一直有个疑问,一开始比较时Value跟Expect不一样,自旋几次就一样了吗?难道是Value刚开始不一样,后来又变得跟原来一样?这不就变成ABA问题了。
五一没啥事,稍微来理一下。
什么是CAS
CAS(Compare And Swap )是乐观锁的一种实现方式,是一种轻量级锁,其实就是无锁实现,在不使用锁(没有线程被阻塞)的情况下实现多线程之间的变量同步。
CAS原理
CAS工作时涉及三个值:
- 需要读写的内存值 V (Value)
- 进行比较的值 E (Expect)
- 要写入的新值 N (New)
假设一个线程要操作一个变量,而这个变量在主内存(JMM中的抽象说法,大概就是线程间共享的区域,用jvm运行时数据区来说就是堆区、方法区一类的)中的位置为V,一般需要:
- 先将V的值读进该线程的本地内存中(JMM中线程私有的内存区域,比如栈),记为 E
- 该线程在本地内存中对 E 的值进行运算,并将运算结果存在本地内存N中
- 将N的值写回原来主内存V中【此时如果有另一个线程在操作V就会出现线程竞争】
然后我们梳理下CAS避免线程竞争的流程:
- 1,2两步都没什么问题,正常读进本地内存然后运算
- 重点在第3步中,将N写回V前,会对比V的值(主内存中的当前值)与E 的值(本线程进程操作时V的值),即CAS的C,Compare
- 如果一致,则说明之前没有其他线程更改过V,成功写回;
- 如果不一致,说明有其他线程在使用V,在把现在V的值读到线程本地内存中作为E,重新运算得到N,然后写回前比较V跟E的值…
就这样,E与V的值不同–重新读E的新值到V–重新运算得到N–重新比较-E与V的值不同–…这样一致循环“比较+交换”的过程,就是自旋。也就回答了刚开始的问题,咱一开始没搞清楚的时候觉得E是固定的,那不是一直死循环?脑子确实不灵光,现在明白了。
Java中实现CAS主要是通过Unsafe类(Atomic系类的类底层调用的是Unsafe类的API),其中包含了很多public natice的方法,有关CAS的主要就是:
boolean compareAndSwapObject(Object o, long offset,Object expected, Object x);
boolean compareAndSwapInt(Object o, long offset,int expected,int x);
boolean compareAndSwapLong(Object o, long offset,long expected,long x);
其中,offset就是目标变量在类对象中的内存偏移值
CAS的原子性
CAS本身就是一个原子操作,也就是说,比较(Compare)跟交换(Swap)是不能被打断的。
当多个线程同时使用CAS操作一个变量时,只有一个会胜出,并成功更新,其他的线程不会被挂起阻塞,而是一直自旋,直到成功。
Java中的原子操作主要就是通过AtomicInteger类实现的,
CAS的三个问题
老生常谈了,稍微过一下
问题一:ABA
简单来说就是主内存V的值原来是A,读进【线程1】的本地内存的E的值也是A,但是另一个【线程2】先把A更新成B,再把B更新成A,这时候在【线程1】CAS比较时会觉得V没被更改过就擅自更新了,实际上【线程2】更改过了。
解决方法
在变量前面追加上版本号或者时间戳。
从JDK 1.5开始,JDK的atomic包里提供了AtomicStampedReference
类来解决ABA问题,其中compareAndSet
会检查当前引用是否等于预期引用,并且检查当前标志是否等于预期标志,如果二者都相等,才使用CAS设置为新的值和标志。
public boolean compareAndSet(V expectedReference,V newReference,int expectedStamp,int newStamp) {Pair<V> current = pair;returnexpectedReference == current.reference &&expectedStamp == current.stamp &&((newReference == current.reference &&newStamp == current.stamp) ||casPair(current, Pair.of(newReference, newStamp)));
}
问题二:CPU开销过大
CAS虽然不像悲观锁一样会有加锁、释放、挂起、阻塞等上下文切换开销,但代价就是会一直占用CPU资源的。
在很多线程都并发竞争的场景下,大量线程都在长时间自旋,那CPU就寄了。
因此可以看出,如果线程之间竞争程度小,使用CAS是一个很好的选择;但是如果竞争很大,使用锁可能是个更好的选择。
解决方法
主要思想就是控制自旋频率或者次数,比如:
- 自旋到一定次数不能成功,就停止
- 让JVM支持处理器提供的pause指令,也就是让自旋失败时cpu睡眠一小段时间再继续自旋
- 自适应自旋锁:自旋次数不固定。简单来说,对于一个锁资源,如果大部分情况下都不能被成功获得,说明竞争比较激烈,就会减少下一次的自旋次数;如果大部分情况下都能成功获得,就增加自旋次数。
问题三:不能保证代码块的原子性
CAS只能保证一个共享变量的原子操作
解决方法
- 使用其他锁,比如Lock,synchronized。锁内的临界区代码可以保证只有当前线程能操作。
- 把多个变量放到一个对象里面进行CAS操作,JDK 1.5开始提供了AtomicReference类保证对象之间的原子性
Reference
并发编程的基石——CAS机制
第十章 CAS与原子操作
这篇关于【Java笔记】CAS比较的是什么+交换的是什么+自旋到啥时候的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!