在JDK 1.5之后,java api中提供了java.util.concurrent包,简称JUC包。这个包定义了很多我们非常熟悉的工具类,比如原子类AtomicXX,线程池executors、信号量semaphore、阻塞队列、同步器等。日常并发编程要用的熟面孔基本都在这里。
首先,Atomic包,原子操作类,提供了用法简单、性能高效、最重要是线程安全的更新一个变量。支持整型、长整型、布尔、double、数组、以及对象的属性原子修改,支持种类非常丰富。
之前的文章《JAVA并发编程volatile核心原理》说过,volatile只是解决了多线程的可见性和有序性问题,原子性问题并没有解决。 在这里volatile+Atomic原子类可以完美实现多线程共享变量的安全修改。
1、Atomic原子类并发修改共享变量demo
package lading.java.mutithread;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.atomic.AtomicInteger;
/**
* 多线程并发下,使用原子类+volatile进行操作,实现共享变量修改并发安全
* 10个线程并发对共享变量count进行求和,每个线程求和100次,最后结果是1000
*/
public class Demo005AtomicCount {
public static volatile AtomicInteger count = new AtomicInteger(0);
public static void main(String[] args) {
int threadNum = 10;
ExecutorService threadPool = Executors.newFixedThreadPool(threadNum);
for (int i = 0; i < threadNum; i++) {
//10个线程并发对共享变量count进行求和,每个线程求和100次
threadPool.submit(() -> {
System.out.println(Thread.currentThread().getName() + "开始对count求和100次");
for (int j = 0; j < 100; j++) {
count.getAndIncrement();
}
});
}
threadPool.shutdown();
System.out.println("最后count的值:" + count.get());
}
}
结果,刚好就是1000.
2、说一下CAS原理
CAS 英文原名compare AND swap(比较再置换)。在JUC包中,大量应用了CAS的原理实现,比如AQS ,concurrentHashMap都有应用CAS技术。可以说,synchronized、volatile、CAS就是JAVA并发编程里的基石。
CAS本质是一条CPU指令,fun(address,oldValue,newValue),其中Address就是本次操作要读取旧值以及修改为新值的内存地址,oldValue就是该内存地址之前的旧值,newValue就是本次操心希望写入的新值。
核心原理:判断内存地址address当前的值是否与oldValue相同,如果相同就更新该内存地址的值为newValue。
先看一下源码,这个AtomicInteger +1源码:
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;
}
然后compareAndSwapInt的源码如下:
public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);
这里this.compareAndSwapInt(var1, var2, var5, var5 + var4));可以看到其实是4个变量,实际就是我们常说的三个变量,因为Object var1表示这个对象内存地址,var2只是偏移量。
这个偏移量有什么用呢?继续看unsafe c++的源码,发现,其实和我们之前讲的JVM内存模型是一样的,一个对象有自己的地址,对象在内存中会占据一段内存区域,这一片区域会有对象的各种信息,比如锁状态,对象头信息,最重要的是还有我们这个对象的值。那如何找到这个值的内存地址呢?
这时候就是需要这个long var2 偏移量。通过这个var2才可以读到当前变量的旧值old。然后拿这个old和预期的oldValue去比对,相等了就把newValue更新到值的内存地址。
3、CAS有什么缺陷吗
在2的核心原理源码看到,很明显,如果发现从内存地址里值不是预期的oldValue,那就陷入了死循环。CAS就是一个while循环判断内存地址值是否等于预期值,不等于就继续循环。
3.1 CAS一直不成功,就会导致CPU自旋时间过长,CPU开销过大。
3.2 A->B->A问题,俗称ABA问题。
举个例子,有个变量name="A",有个线程想把name从A修改为C。但是很不幸在次过程中被别的线程修改为B后,又再修改为A,它才能执行。再具体一点就是:有个人存款有100块,想去取出来,但是取款机显示余额是0,无法取现;过了一会,发现余额是100,这才能取现。这个诡异的过程就是ABA的问题,CAS对变量预期旧值的循环变化是无感的。
4、如何解决CAS的ABA问题
我们先看一下ABA的demo。
package lading.java.mutithread;
import java.util.concurrent.atomic.AtomicInteger;
/**
* CAS ABA问题复现
* count 原值100
*/
public class Demo006CasBug {
public static volatile AtomicInteger count = new AtomicInteger(100);
public static void main(String[] args) throws InterruptedException {
//线程1先修改为200,然后马上修改为100
Thread thread1 = new Thread(() -> {
count.compareAndSet(100, 200);
count.compareAndSet(200, 100);
System.out.println(Thread.currentThread().getName() + "完成对count的从100修改为200,然后再修改为100");
});
Thread thread2 = new Thread(() -> {
count.compareAndSet(100, 300);
System.out.println(Thread.currentThread().getName() + "对count的从100修改为" + count.get());
});
thread1.start();
thread2.start();
thread1.join();
thread2.join();
}
}
结果是线程1无感的修改为300,实际上期间线程0已经修改了2次。
JDK提供了AtomicStampedReference来解决。解决demo:
package lading.java.mutithread;
import java.util.concurrent.atomic.AtomicStampedReference;
/**
* 解决CAS ABA问题
* 用AtomicStampedReference,给原子类增加一个时间戳6666,这样每次修改需要增加判断预期的时间戳
* 类似数据库mysql更新一个记录,update set col1='' where col2=oldVal and timestamp=oldVal
* 在cas基础上增加一个数据时间戳,确保数据未更新修改过。
*/
public class Demo007CasBugFix {
public static AtomicStampedReference<Integer> count = new AtomicStampedReference<>(100, 6666);
public static void main(String[] args) throws InterruptedException {
//线程1先修改为200,然后马上修改为100
Thread thread1 = new Thread(() -> {
System.out.println(Thread.currentThread().getName() + "第一次修改前时间戳版本号:" + count.getStamp());
count.compareAndSet(100, 200, count.getStamp(), count.getStamp() + 1);
System.out.println(Thread.currentThread().getName() + "第二次修改前时间戳版本号:" + count.getStamp());
count.compareAndSet(200, 100, count.getStamp(), count.getStamp() + 1);
System.out.println(Thread.currentThread().getName() + "完成对count的从100修改为200,然后再修改为100");
});
Thread thread2 = new Thread(() -> {
try {
Thread.sleep(5);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
System.out.println(Thread.currentThread().getName() + "第三次修改前时间戳版本号:" + count.getStamp());
boolean isSuccess = count.compareAndSet(100, 300, count.getStamp(), count.getStamp() + 1);
if (isSuccess) {
System.out.println(Thread.currentThread().getName() + "修改成功,对count的从100修改为300");
} else {
System.out.println(Thread.currentThread().getName() + "修改失败,count值为:" + count.getReference());
}
});
thread1.start();
thread2.start();
}
}
结果,因为时间戳已经被修改了,线程1就没法修改cout,避免了ABA问题: