前言
每个东西的出现,肯定不是无缘无故的、Atomic类的出现是为了解决一些常见类型变量的原子操作问题而提出的。
来来来,程序语言
问题在哪里
package com.pochi.juc;
public class AtomicProblem {
public static void main(String[] args) {
AtomicExample atomicExample = new AtomicExample();
for(int i=0;i<10;i++){
new Thread(atomicExample).start();
}
}
}
class AtomicExample implements Runnable{
private int value;
@Override
public void run() {
try {
// 为了暴露问题,我也是调试了很多次
Thread.sleep(7);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println(getValue());
}
public int getValue() {
return value++;
}
}
结果
不是说一定会出现问题,我也是调试了很多次,才发现了问题。
1
0
2
5
4
3
2
6
8
7
看到了吗,两个2。
用volatile能解决吗?
package com.pochi.juc;
public class AtomicProblem {
public static void main(String[] args) {
AtomicExample atomicExample = new AtomicExample();
for(int i=0;i<10;i++){
new Thread(atomicExample).start();
}
}
}
class AtomicExample implements Runnable{
/****************************************
这里加了Volatile
*****************************************/
private volatile int value;
@Override
public void run() {
try {
Thread.sleep(7);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println(getValue());
}
public int getValue() {
return value++;
}
}
结果
肯定还是扑街了呀,但是也不是说,每一次都扑街,有时候扑街,有时候还好。
0
1
2
3
4
6
5
7
7
看到了吗?一对7。这么尝试不是办法呀,总归得找个办法解决啊?啊对,憋和我说加锁,这个方法我知道,我想说的是有没有不加锁的。
先分析分析它为啥产生呗
现在,主存里有一个val,初始值是0;我们第一个线程先要操作这个线程了,它先拿到了val=0;然后在自己的这块缓存里面,准备(将要)++,然后刷新回主存。哪知道?说时迟那时快…
Thread2,也从主存里面拿到了val,此时val=0;准备进行操作了。
然后,接下来的两张图,大家自己体会,就知道,为什么会出现重复数了。
Thread1 刷新到主存,val=1; Thread2也开始了相应的操作。
Thread2 刷新到主存,但是刷新的还是1
为啥volatile没法解决
我们先想想,volatile是干嘛的,特别是写操作的时候,就是写完必须刷新会主存,这点就算不用volatile做了吗?做了!那volatile有什么用呢?所以我们要想其他办法,加锁是一种,这里不说。
非锁的解法
在开头先说一句,非锁的解法,其实最终还是要用锁,不过锁不是我们自己写,是CPU底层实现的,在我们这里看起来就是没锁,但是你要纠其根源,不管硬件是怎么样实现的吧,还是有隐约的锁的概念。
要介绍的这个思想叫做,CAS(Compare and swap)比较交换策略。当前的处理器基本都支持CAS,只不过每个厂家所实现的算法并不一样罢了。
每一个CAS操作过程都包含三个运算符:一个内存地址V,一个期望的值A和一个新值B,操作的时候如果这个地址上存放的值等于这个期望的值A,则将地址上的值赋为新值B,否则不做任何操作。CAS的基本思路就是,如果这个地址上的值和期望的值相等,则给其赋予新值,否则不做任何事儿,但是要返回原值是多少
一开始从主存拿过来的值是原值V
做完操作之后,就有了一个改变值B
要刷新会主存的时候就那主存的值作为期望值A,与V做对比
return V==A?B:V;
这里是0,所以会返回B,如果是Thread2抢先一步将主存刷新成1,那么V!=A,调用的那个CPU底层函数是返回一个旧值,实际上,我们什么都不做,继续
- 取主存
- 做操作
- 刷新回主存
明白?了解?
问题又来了
如果是Thread1 取主存数据A的那一步之后,Thread2也紧接着取主存数据,会不会又有线程安全问题了呢?
我不知道你们听懂这个问题没有,但是答案是确定的,确实还是会有线程安全问题,所以,取A值,对比,和刷新,这必须是一步加锁的操作。不能让其他线程插一脚,不然就又不安全了。这就是我为什么说CAS说到底还是加锁的。只不过,这个锁硬件是怎么加的,我们并不关心,我们关心的只是,他加了,OK,安全了。对我们自己写代码的操作是,哦,我们不用加锁了,安全了。
验证一下
package com.pochi.juc;
import java.util.concurrent.atomic.AtomicInteger;
public class AtomicProblem {
public static void main(String[] args) {
AtomicExample atomicExample = new AtomicExample();
for(int i=0;i<10;i++){
new Thread(atomicExample).start();
}
}
}
class AtomicExample implements Runnable{
/*****************************************
这里换了原子变量
******************************************/
private volatile AtomicInteger value=new AtomicInteger(0);
@Override
public void run() {
try {
Thread.sleep(7);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println(getValue());
}
public int getValue() {
// 这里改成原子类的自增方法
return value.getAndIncrement();
}
}
结果
这个博主自己验证了十遍,确实没有再出现重复情况,讲道理嘛,也不应再出现这个情况。
0
1
3
2
7
6
5
4
8
9
后记
原子类呢,用起来十分方便,可以实现变量的原子性操作问题,不过,确实也是要牺牲一点效率的,至于和锁比起来,是要比锁高的,因为锁有阻塞,而这里大不了对比V!=A,就再做一遍呗,不过也是有效率损耗的,用的时候也要想清楚,不要说,一个单线程的也用Atomic,那就真是