- A+
前言：关于同步，很多人都知道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: 是否变化: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类
翻以下这个方法的源码，可以看到其中是这样实现的：
compareAndSet( expect, unsafe.compareAndSwapInt(
public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);
主要交给了unsafe类的compareAndSwapInt的方法，再翻以下可以看到是native的，也就是本地调用C++实现的源码，这里我们就不深究了。关于unsafe类，它有一个最重要的点就是jdk的开发人员认为这个类是很危险的，所以是unsafe！因此不建议程序员调用这个类，为此他们还对这个类做了一个绝妙的处理，让你无法使用它：
= (! SecurityException("Unsafe"
public static boolean isSystemDomainLoader(ClassLoader var0) {
return var0 == null;
}
//outPut Exception in thread "main"90)
这个方法实现的原理主要是类的加载机制，应用类的类加载器是有applicationClassLoder加载的，而jdk的类，比如关键库，rt.jar是由Bootstrap加载的，而BootStrapclassLoader是最上层加载库，它其实是没有java对象的，因为jdk的常用类比如（AtomicInteger）加载的时候它会返回null,而我们自定义的类一定不会返回null，就会抛出异常！
3.4:compareAndSet的方法原理
current= next=current+1
可以看出这是在一个无限的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，而不要尝试自己去做，无锁是一个双刃剑，用好了，绝对可以让性能比锁有很大的提升，用不好就很容易造成数据污染与脏读，望谨慎之。
