主要有两种实现,悲观锁和乐观锁实现方式.
悲观的解决方案(阻塞同步)
我们知道,num++看似简单的一个操作,实际上是由1.读取 2.加一 3.写入 三步组成的,这是个复合类的操作(所以我们之前提到过的volatile是无法解决num++的原子性问题的),在并发环境下,如果不做任何同步处理,就会有线程安全问题。最直接的处理方式就是加锁。
synchronized(this){
num++;
}
使用独占锁机制来解决,是一种悲观的并发策略,每次操作数据的时候都认为别的线程会参与竞争修改,所以直接加锁。同一刻只能有一个线程持有锁,那其他线程就会阻塞。线程的挂起恢复会带来很大的性能开销,尽管jvm对于非竞争性的锁的获取和释放做了很多优化,但是一旦有多个线程竞争锁,频繁的阻塞唤醒,还是会有很大的性能开销的。所以,使用synchronized或其他重量级锁来处理显然不够合理。
方案一:ReentrantLock方式实现,100个并发任务基于10个线程执行,每个任务循环执行10次计数.
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
public class ReentrantLockTest {
private static int count = 0;
private static final Lock CAS_LOCK=new ReentrantLock();
private static final int JOB_NUM=100;
private static final int THREAD_SIZE=10;
private static void service() {
CAS_LOCK.lock();
try {
count++;
System.out.println("thread num execute:"+Thread.currentThread().getName()+":"+count);
} finally {
CAS_LOCK.unlock();
}
}
public static void main(String[] args) {
ExecutorService executorService = Executors.newFixedThreadPool(THREAD_SIZE);
CountDownLatch countDownLatch = new CountDownLatch(JOB_NUM);
for(int i=0;i<JOB_NUM;i++){
executorService.execute(new Runnable() {
// 每个线程执行10次计算
@Override
public void run() {
for(int j=0;j<10;j++){
try {
service();
} finally {
countDownLatch.countDown();
}
}
}
});
}
try {
countDownLatch.await();
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
executorService.shutdown();
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
System.out.println("get Count:"+count);
}
}
执行结果如下:
方案一:synchionized方式实现,100个并发任务基于10个线程执行,每个任务循环执行10次计数.
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
public class ReentrantLockTest {
private static volatile int count = 0;
private static final int JOB_NUM=100;
private static final int THREAD_SIZE=10;
private static final byte[] lock=new byte[0];
private static void service(){
synchronized (lock){
count++;
System.out.println("thread num execute:"+Thread.currentThread().getName()+":"+count);
}
}
public static void main(String[] args) {
ExecutorService executorService = Executors.newFixedThreadPool(THREAD_SIZE);
CountDownLatch countDownLatch = new CountDownLatch(JOB_NUM);
for(int i=0;i<JOB_NUM;i++){
executorService.execute(new Runnable() {
// 每个线程执行10次计算
@Override
public void run() {
for(int j=0;j<10;j++){
try {
service();
} finally {
countDownLatch.countDown();
}
}
}
});
}
try {
countDownLatch.await();
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
executorService.shutdown();
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
System.out.println("get Count:"+count);
}
}
运行截图
乐观的解决方案(非阻塞同步)
乐观的解决方案,顾名思义,就是很大度乐观,每次操作数据的时候,都认为别的线程不会参与竞争修改,也不加锁。如果操作成功了那最好;如果失败了,比如中途确有别的线程进入并修改了数据(依赖于冲突检测),也不会阻塞,可以采取一些补偿机制,一般的策略就是反复重试。很显然,这种思想相比简单粗暴利用锁来保证同步要合理的多。
鉴于并发包中的原子类其实现机理都差不太多,本章我们就通过AtomicInteger这个原子类来进行分析。我们先来看看对于num++这样的操作AtomicInteger是如何保证其原子性的。
方案一:AtomicInteger方式实现,100个并发任务基于10个线程执行,每个任务循环执行10次计数.
package com.boot.skywalk;
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.atomic.AtomicInteger;
public class ReentrantLockTest {
private static AtomicInteger atomicInteger=new AtomicInteger(0);
private static final int JOB_NUM=100;
private static final int THREAD_SIZE=10;
private static void service(){
atomicInteger.getAndIncrement();
System.out.println("thread num execute:"+Thread.currentThread().getName()+":"+atomicInteger.get());
}
public static void main(String[] args) {
ExecutorService executorService = Executors.newFixedThreadPool(THREAD_SIZE);
CountDownLatch countDownLatch = new CountDownLatch(JOB_NUM);
for(int i=0;i<JOB_NUM;i++){
executorService.execute(new Runnable() {
// 每个线程执行10次计算
@Override
public void run() {
for(int j=0;j<10;j++){
try {
service();
} finally {
countDownLatch.countDown();
}
}
}
});
}
try {
countDownLatch.await();
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
executorService.shutdown();
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
System.out.println("get Count:"+atomicInteger.get());
}
}
运行截图
源码如下:
/**
* Atomically increments by one the current value.
*
* @return the updated value
*/
public final int incrementAndGet() {
for (;;) {
int current = get();
int next = current + 1;
if (compareAndSet(current, next))
return next;
}
}
我们来分析下incrementAndGet的逻辑:
1.先获取当前的value值
2.对value加一
3.第三步是关键步骤,调用compareAndSet方法来来进行原子更新操作,这个方法的语义是:先检查当前value是否等于current,如果相等,则意味着value没被其他线程修改过,更新并返回true。如果不相等,compareAndSet则会返回false,然后循环继续尝试更新。
compareAndSet调用了Unsafe类的compareAndSwapInt方法。
/**
* Atomically sets the value to the given updated value
* if the current value {@code ==} the expected value.
*
* @param expect the expected value
* @param update the new value
* @return true if successful. False return indicates that
* the actual value was not equal to the expected value.
*/
public final boolean compareAndSet(int expect, int update) {
return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
}
Unsafe的compareAndSwapInt是个native方法,也就是平台相关的。它是基于CPU的CAS指令来完成的。
public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);
CAS(Compare-and-Swap)
CAS算法是由硬件直接支持来保证原子性的,有三个操作数:内存位置V、旧的预期值A和新值B,当且仅当V符合预期值A时,CAS用新值B原子化地更新V的值,否则,它什么都不做。
CAS的ABA问题
当然CAS也并不完美,它存在"ABA"问题,假若一个变量初次读取是A,在compare阶段依然是A,但其实可能在此过程中,它先被改为B,再被改回A,而CAS是无法意识到这个问题的。CAS只关注了比较前后的值是否改变,而无法清楚在此过程中变量的变更明细,这就是所谓的ABA漏洞。
CAS解决
使用AtomicStampedReference解决,带有版本号.
import com.google.common.collect.Lists;
import java.util.concurrent.atomic.AtomicStampedReference;
public class CodeTest {
public static void main(String[] args) {
// 初始化一个带版本号的原子操作类,原始值:a,原始版本号:1
AtomicStampedReference<String> reference = new AtomicStampedReference<>("a", 1);
// 将a更为b,同时将版本号加1,第一个参数:预期原值;第二个参数:更新后的新值;第三个参数:预期原版本号;第四个参数:更新后的版本号
boolean result1 = reference.compareAndSet("a", "b", reference.getStamp(), reference.getStamp() + 1);
System.out.println("第一次更新:" + result1);
// 将b更为a,因为预期原版本号不对,所以更新失败
System.out.println(reference.getStamp());
boolean result2 = reference.compareAndSet("b", "a", 1, reference.getStamp());
System.out.println("第二次更新:" + result2);
}
CAS算法实现
for(;;):循环方式实现自旋
public class IncrementExamplePositive {
private volatile int num;
// private int num;
public void incrementNum() {
int current;
int next;
do {
current = num; // 获取当前值
next = current + 1; // 计算递增后的值
} while (!compareAndSet(current, next)); // 比较并设置,知道成功递增
}
private boolean compareAndSet(int expect, int update) {
if (num == expect) {
num = update; // 设置新值
return true;
}
return false;
}
public int getNum() {
return num;
}
}
LongAddr
方案一:LongAddr方式实现,100个并发任务基于10个线程执行,每个任务循环执行10次计数.
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.atomic.LongAdder;
public class ReentrantLockTest {
private static LongAdder adder=new LongAdder();
private static final int JOB_NUM=100;
private static final int THREAD_SIZE=10;
private static void service(){
adder.increment();
System.out.println("thread num execute:"+Thread.currentThread().getName()+":"+adder.longValue());
}
public static void main(String[] args) {
ExecutorService executorService = Executors.newFixedThreadPool(THREAD_SIZE);
CountDownLatch countDownLatch = new CountDownLatch(JOB_NUM);
for(int i=0;i<JOB_NUM;i++){
executorService.execute(new Runnable() {
// 每个线程执行10次计算
@Override
public void run() {
for(int j=0;j<10;j++){
try {
service();
} finally {
countDownLatch.countDown();
}
}
}
});
}
try {
countDownLatch.await();
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
executorService.shutdown();
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
System.out.println("get Count:"+adder.longValue());
}
}
LongAdder是JDK1.8由Doug Lea大神新增的原子操作类,位于java.util.concurrent.atomic包下,LongAdder在高并发的场景下会比AtomicLong 具有更好的性能,代价是消耗更多的内存空间。
LongAdder是Google开源的一个高性能计数器实现。它采用了一种分段锁的策略,将一个long型的变量分割成多个16字节的段,每个段都使用一个独立的AtomicLong进行更新。这样,在高并发场景下,多个线程可以同时对不同的段进行更新操作,互不干扰。
LongAdder的优点是并发性能高,适用于高并发的场景。由于采用了分段锁的策略,LongAdder可以避免AtomicLong中的竞争问题。此外,LongAdder还支持可扩展性,可以通过增加更多的段来提高性能。但是,LongAdder的缺点是代码相对复杂一些,需要更多的维护成本。
LongAdder设计思想上,采用分段的方式降低并发冲突的概率。通过维护一个基准值base和 Cell 数组:
AtomicInteger的缺点:
图里可以看出在高并发情况下,当有大量线程同时去更新一个变量,任意一个时间点只有一个线程能够成功,绝大部分的线程在尝试更新失败后,会通过自旋的方式再次进行尝试,这样严重占用了CPU的时间片,进而导致系统性能问题。
高并发下推荐使用LongAdder的原因主要有以下几点:
- 高并发性能:LongAdder采用分段锁的策略,可以避免AtomicLong中的竞争问题,提高并发性能。在分布式系统中,高并发性能是非常重要的。
- 可扩展性:LongAdder支持可扩展性,可以通过增加更多的段来提高性能。这对于需要处理大量请求的分布式系统来说是非常有利的。
- 代码简单易懂:虽然LongAdder的代码相对复杂一些,但是相对于AtomicLong来说更容易理解和维护。这对于开发人员来说是非常重要的。
- 更好的适用场景:推荐使用LongAdder主要是因为在分布式系统中需要一个高性能、高可用的计数器实现。而LongAdder正好符合这个需求。
常见原子类图谱如下:
常用方法如下:
int get() | 获取当前值 |
void set(int newValue) | 设置 value 值 |
int getAndIncrement() | 先取得旧值,然后加1,最后返回旧值 |
int getAndDecrement() | 先取得旧值,然后减1,最后返回旧值 |
int incrementAndGet() | 加1,然后返回新值 |
int decrementAndGet() | 减1,然后返回新值 |
int getAndAdd(int delta) | 先取得旧值,然后增加指定值,最后返回旧值 |
int addAndGet(int delta) | 增加指定值,然后返回新值 |
boolean compareAndSet(int expect, int update) | 直接使用CAS方式,将【旧值】更新成【新值】,核心方法 |