IT老哥,一个在大厂做高级Java开发的程序员,每天分享技术干货文章
由于最近项目上遇到了高并发问题,而自己对高并发,多线程这里的知识点相对薄弱,尤其是基础,所以想系统的学习一下,以后可能会出一系列的JUC文章及总结 ,同时也为企业级的高并发项目做好准备。
此系列文章的总结思路大致分为三部分:
在这里提前说也是为了防止大家看着看着就迷路了。
首先,下图是本文的大纲,也就是说在看本文之前,你需要先了解本文到底是讲什么内容,有个整体大观,然后逐个细分到内容层次去讲解。
查看
AtomicInteger.getAndIncrement()
方法,发现其没有加synchronized
也实现了同步。这是为什么?
CAS的全称是Compare-And-Swap,它是一条CPU并发原语。
正如它的名字一样,比较并交换,它是一种很重要的同步思想。如果主内存的值跟期望值一样,那么就进行修改,否则一直重试,直到一致为止。
而原语的执行必须是连续的,在执行过程中不允许被中断,也就是说CAS是一条CPU的原子指令,不会造成所谓的数据不一致性问题。
它的功能是判断内存某个位置的值是否为预期值
,如果是则更改为新的值
,这个过程是原子的。
我们来看一段代码:
public class CasDemo {
public static void main(String[] args) {
//初始值
AtomicInteger integer = new AtomicInteger(5);
//比较并替换
boolean flag = integer.compareAndSet(5, 10);
boolean flag2 = integer.compareAndSet(5, 15);
System.out.println("是否自选并替换 \t"+flag +"\t更改之后的值为:"+integer.get());
System.out.println("是否自选并替换 \t"+flag2 +"\t更改之后的值为:"+integer.get());
}
}
你能猜到答案么?
是否自选并替换 true 更改之后的值为:10
是否自选并替换 false 更改之后的值为:10
第一次修改,期望值为5,主内存也为5,修改成功,为10。
第二次修改,期望值为5,主内存为10,修改失败。
在翻了源码之后,大致可以总结出两个关键点:
当点开compareAndSet
方法后:
// AtomicInteger类内部
public final boolean compareAndSet(int expect, int update) {
return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
}
通过这个方法,我们可以找出AtomicInteger
内部维护了volatile int value
和private static final Unsafe unsafe
两个比较重要的参数。(注意value是用volatile修饰)
还有变量private static final long valueOffset
,表示该变量在内存中的偏移地址,因为Unsafe就是根据内存偏移地址获取数据的。
变量value用volatile修饰,保证了多线程之间的内存可见性。
// AtomicInteger类内部
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;
然后我们通过compareAndSwapInt
找到了unsafe类核心方法:
//unsafe内部类
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;
}
AtomicInteger.
compareAndSwapInt()
调用了Unsafe.
compareAndSwapInt()
方法。Unsafe
类的大部分方法都是native
的,用来像C语言一样从底层操作内存。
这个方法的var1和var2,就是根据对象和偏移量得到在主内存的快照值var5。然后compareAndSwapInt
方法通过var1和var2得到当前主内存的实际值。如果这个实际值跟快照值相等,那么就更新主内存的值为var5+var4。如果不等,那么就一直循环,一直获取快照,一直对比,直到实际值和快照值相等为止。
比如有A、B两个线程
var5=this.getIntVolatile
,即var5=3。此时A线程挂起;this.compareAndSwapInt()
方法,发现这个时候主内存的值不等于快照值3,所以继续循环,重新从主内存获取。所谓ABA问题,其实用最通俗易懂的话语来总结就是狸猫换太子
就是比较并交换的循环,存在一个时间差,而这个时间差可能带来意想不到的问题。
比如有两个线程A、B:
var5=this.getIntVolatile
,即var5=3。此时A线程挂起;this.compareAndSwapInt()
方法,发现这个时候主内存的值等于快照值3,(但是却不知道B曾经修改过),修改成功。尽管线程A CAS操作成功,但不代表就没有问题。有的需求,比如CAS,只注重头和尾,只要首尾一致就接受。但是有的需求,还看重过程,中间不能发生任何修改。这就引出了AtomicReference
原子引用。
AtomicInteger
对整数进行原子操作,如果是一个POJO呢?可以用AtomicReference
来包装这个POJO,使其操作原子化。
User user1 = new User("Jack",25);
User user2 = new User("Lucy",21);
AtomicReference<User> atomicReference = new AtomicReference<>();
atomicReference.set(user1);
System.out.println(atomicReference.compareAndSet(user1,user2)); // true
System.out.println(atomicReference.compareAndSet(user1,user2)); //false
本质是比较的是两个对象的地址
是否相等。
使用AtomicStampedReference
类可以解决ABA问题。这个类维护了一个“版本号”Stamp
,其实有点类似乐观锁的意思。
在进行CAS操作的时候,不仅要比较当前值,还要比较版本号。只有两者都相等,才执行更新操作。
AtomicStampedReference.compareAndSet(expectedReference,newReference,oldStamp,newStamp);
任何技术都不是完美的,当然,CAS也有他的缺点:
CAS实际上是一种自旋锁,
而他的使用场景适合在一些并发量不高、线程竞争较少的情况,加锁太重。但是一旦线程冲突严重的情况下,循环时间太长,为给CPU带来很大的开销。
云服务器,云硬盘,数据库(包括MySQL、Redis、MongoDB、SQL Server),CDN流量包,短信流量包,cos资源包,消息队列ckafka,点播资源包,实时音视频套餐,网站管家(WAF),大禹BGP高防(包含高防包及高防IP),云解析,SSL证书,手游安全MTP,移动应用安全、 云直播等等。