探索CAS无锁技术
前言:关于同步,很多人都知道synchronized,Reentrantlock等加锁技术,这种方式也很好理解,是在线程访问的临界区资源上建立一个阻塞机制,需要线程等待
其它线程释放了锁,它才能运行。这种方式很显然是奏效的,但是它却带来一个很大的问题:程序的运行效率。线程的上下文切换是非常耗费资源的,而等待又会有一定的时间消耗,那么有没有一种方式既能控制程序的同步效果,又能避免这种锁带来的消耗呢?答案就是无锁技术,本篇博客讨论的中心就是无锁。
一:有锁与无锁
二:cas技术原理
三:AtomicInteger与unsafe类
四:经典的ABA问题与解决方法
五:总结
正文
一:有锁与无锁
1.1:悲观锁与乐观锁
数据库有两种锁,悲观锁的原理是每次实现数据库的增删改的时候都进行阻塞,防止数据发生脏读;乐观锁的原理是在数据库更新的时候,用一个version字段来记录版本号,然后通过比较是不是自己要修改的版本号再进行修改。这其中就引出了一种比较替换的思路来实现数据的一致性,事实上,cas也是基于这样的原理。
二:CAS技术原理
2.1:cas是什么?
cas的英文翻译全称是compare and set ,也就是比较替换技术,·它包含三个参数,CAS(V,E,N),其中V(variile)表示欲更新的变量,E(Excepted)表示预期的值,N(New)表示新值,只有当V等于E值的时候吗,才会将V的值设为N,如果V值和E值不同,则说明已经有其它线程对该值做了更新,则当前线程什么都不做,直接返回V值。
举个例子,假如现在有一个变量int a=5;我想要把它更新为6,用cas的话,我有三个参数cas(5,5,6),我们要更新的值是5,找到了a=5,符合V值,预期的值也是5符合,然后就会把N=6更新给a,a的值就会变成6;
2.2:cas的优点
2.2.1cas是以乐观的态度运行的,它总是认为当前的线程可以完成操作,当多个线程同时使用CAS的时候只有一个最终会成功,而其他的都会失败。这种是由欲更新的值做的一个筛选机制,只有符合规则的线程才能顺利执行,而其他线程,均会失败,但是失败的线程并不会被挂起,仅仅是尝试失败,并且允许再次尝试(当然也可以主动放弃)
2.2.2:cas可以发现其他线程的干扰,排除其他线程造成的数据污染
三:AtomicInteger与unsafe类
CAS在jdk5.0以后就被得到广泛的利用,而AtomicInteger是很典型的一个类,接下来我们就来着重研究一下这个类:
3.1:AtomicInteger
关于Integer,它是final的不可变类,AtomicInteget可以把它视为一种整数类,它并非是fianl的,但却是线程安全的,而它的实现就是著名的CAS了,下面是一些它的常用方法:
public final int getAndSet(int newValue); public final boolean compareAndSet(int expect, int update); public final boolean weakCompareAndSet(int expect, int update); public final int getAndIncrement(); public final int getAndDecrement(); public final int addAndGet(int delta); public final int decrementAndGet(); public final int incrementAndGet()
其中主要的方法就是compareAndSet,我们来测试一下这个方法,首先先给定一个值是5,我们现在要把它改成2,如果expect传的是1,程序会输出什么呢?
public class TestAtomicInteger { public static void main(String[] args) { AtomicInteger atomicInteger = new AtomicInteger(5); boolean isChange = atomicInteger.compareAndSet(1, 2); int i = atomicInteger.get(); System.out.println("是否变化:"+isChange); System.out.println(i); } }
//outPut:
是否变化:false 5
boolean isChange = atomicInteger.compareAndSet(5, 2);
如果我们把期望值改成5的话,最后的输出结果将是: // 是否变化:true 2
结论:只有当期望值与要改的值一致的时候,cas才会替换原始的值,设置成新值
3.2:测试AtomicInteger的线程安全性
为此我新建了10个线程,每个线程对它的值自增5000次,如果是线程安全的,应该输出:50000
public class TestAtomicInteger { static AtomicInteger number=new AtomicInteger(0); public static class AddThread implements Runnable{ @Override public void run() { for (int i = 0; i < 5000; i++) { number.incrementAndGet(); } } } public static void main(String[] args) throws InterruptedException { Thread[] threads=new Thread[10]; for (int i = 0; i < threads.length; i++) { threads[i]=new Thread(new AddThread()); } for (int i = 0; i < threads.length; i++) { threads[i].start(); } for (int i = 0; i < threads.length; i++) { threads[i].join(); } System.out.println(number); } }
最后重复执行了很多次都是输出:50000
3.3:unsafe类
翻以下这个方法的源码,可以看到其中是这样实现的:
public final boolean compareAndSet(int expect, int update) { return unsafe.compareAndSwapInt(this, valueOffset, expect, update); }
public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);
主要交给了unsafe类的compareAndSwapInt的方法,再翻以下可以看到是native的,也就是本地调用C++实现的源码,这里我们就不深究了。关于unsafe类,它有一个最重要的点就是jdk的开发人员认为这个类是很危险的,所以是unsafe!因此不建议程序员调用这个类,为此他们还对这个类做了一个绝妙的处理,让你无法使用它:
public static Unsafe getUnsafe() { Class class= Reflection.getCallerClass(); if (!VM.isSystemDomainLoader(class.getClassLoader())) { throw new SecurityException("Unsafe"); } else { return theUnsafe; } }
public static boolean isSystemDomainLoader(ClassLoader var0) {
return var0 == null;
}
//outPut
Exception in thread "main" java.lang.SecurityException: Unsafe at sun.misc.Unsafe.getUnsafe(Unsafe.java:90)
这个方法实现的原理主要是类的加载机制,应用类的类加载器是有applicationClassLoder加载的,而jdk的类,比如关键库,rt.jar是由Bootstrap加载的,而BootStrapclassLoader是最上层加载库,它其实是没有java对象的,因为jdk的常用类比如(AtomicInteger)加载的时候它会返回null,而我们自定义的类一定不会返回null,就会抛出异常!
3.4:compareAndSet的方法原理
public final int incrementAndGet(){ for(;;){ int current=get(); int next=current+1; if(compareAndSet(current,next)){
return next; } } }
可以看出这是在一个无限的for循环里,然后获取当前的值,再给他加1(固定写死的值,每次自增1)。然后通过comePareandSet把当前的值和通过+1获取的值经过cas设值,这个方法返回一个boolean值,当成功的时候就返回当前的值,这样就保证了只有一个线程可以设值成功。注意:这里是一个死循环,只有当前值等于设置后的+1的值时,它才会跳出循环。这也证明cas是一个不断尝试的过程
四:经典的ABA问题与解决方法
4.2:AbA问题的产生
要了解什么是ABA问题,首先我们来通俗的看一下这个例子,一家火锅店为了生意推出了一个特别活动,凡是在五一期间的老用户凡是卡里余额小于20的,赠送10元,但是这种活动没人只可享受一次。然后火锅店的后台程序员小王开始工作了,很简单就用cas技术,先去用户卡里的余额,然后包装成AtomicInteger,写一个判断,开启10个线程,然后判断小于20的,一律加20,然后就很开心的交差了。可是过了一段时间,发现账面亏损的厉害,老板起先的预支是2000块,因为店里的会员总共也就100多个,就算每人都符合条件,最多也就2000啊,怎么预支了这么多。小王一下就懵逼了,赶紧debug,tail -f一下日志,这不看不知道,一看吓一跳,有个客户被充值了10次!
阐述:
假设有个线程A去判断账户里的钱此时是15,满足条件,直接+20,这时候卡里余额是35.但是此时不巧,正好在连锁店里,这个客人正在消费,又消费了20,此时卡里余额又为15,线程B去执行扫描账户的时候,发现它又小于20,又用过cas给它加了20,这样的话就相当于加了两次,这样循环往复肯定把老板的钱就坑没了!
本质:
ABA问题的根本在于cas在修改变量的时候,无法记录变量的状态,比如修改的次数,否修改过这个变量。这样就很容易在一个线程将A修改成B时,另一个线程又会把B修改成A,造成casd多次执行的问题。
4.3:AtomicStampReference
AtomicStampReference在cas的基础上增加了一个标记stamp,使用这个标记可以用来觉察数据是否发生变化,给数据带上了一种实效性的检验。它有以下几个参数:
//参数代表的含义分别是 期望值,写入的新值,期望标记,新标记值 public boolean compareAndSet(V expected,V newReference,int expectedStamp,int newStamp); public V getRerference(); public int getStamp(); public void set(V newReference,int newStamp);
4.4:AtomicStampReference的使用实例
我们定义了一个money值为19,然后使用了stamp这个标记,这样每次当cas执行成功的时候都会给原来的标记值+1。而后来的线程来执行的时候就因为stamp不符合条件而使cas无法成功,这就保证了每次
只会被执行一次。
public class AtomicStampReferenceDemo { static AtomicStampedReference<Integer> money =new AtomicStampedReference<Integer>(19,0); public static void main(String[] args) { for (int i = 0; i < 3; i++) { int stamp = money.getStamp(); System.out.println("stamp的值是"+stamp); new Thread(){ //充值线程 @Override public void run() { while (true){ Integer account = money.getReference(); if (account<20){ if (money.compareAndSet(account,account+20,stamp,stamp+1)){ System.out.println("余额小于20元,充值成功,目前余额:"+money.getReference()+"元"); break; } }else { System.out.println("余额大于20元,无需充值"); } } } }.start(); } new Thread(){ @Override public void run() { //消费线程 for (int j = 0; j < 100; j++) { while (true){ int timeStamp = money.getStamp();//1 int currentMoney =money.getReference();//39 if (currentMoney>10){ System.out.println("当前账户余额大于10元"); if (money.compareAndSet(currentMoney,currentMoney-10,timeStamp,timeStamp+1)){ System.out.println("消费者成功消费10元,余额"+money.getReference()); break; } }else { System.out.println("没有足够的金额"); break; } try { Thread.sleep(1000); }catch (Exception ex){ ex.printStackTrace(); break; } } } } }.start(); } }
这样实现了线程去充值和消费,通过stamp这个标记属性来记录cas每次设置值的操作,而下一次再cas操作时,由于期望的stamp与现有的stamp不一样,因此就会设值失败,从而杜绝了ABA问题的复现。
五:总结
本篇博文主要分享了cas的技术实现原理,对于无锁技术,它有很多好处。同时,指出了它的弊端ABA问题,与此同时,也给出了解决方法。jdk源码中很多用到了cas技术,而我们自己如果使用无锁技术,一定要谨慎处理ABA问题,最好使用jdk现有的api,而不要尝试自己去做,无锁是一个双刃剑,用好了,绝对可以让性能比锁有很大的提升,用不好就很容易造成数据污染与脏读,望谨慎之。