CAS，乐观锁，悲观锁

CAS

什么是CAS?

CAS Compare And Swap 的缩写，比较并替换
CAS当中使用了3个基本操作数：内存地址V,旧的预期值A，要求改的新值B
更新一个变量的时候，只有当变量的预期值A和内存地址V当中的实际值相同时，才会把内存地址V对应的值修改为B

用Unsafe提供了原子性操作

从思想上来说，synchronized属于悲观锁，悲观的以为程序中的并发情况严重，所以严防死守
CAS属于乐观锁，乐观的认为程序中的并发并没有那么严重，所以让线程不断去尝试更新。

CAS的缺点

1)CPU开销大
2)不能保证代码块的原子性
3）ABA问题
当一个值从A更新成B，又更新回A，普通CAS机制会误判通过检测
解决办法：
（1）利用版本号比较可以有效解决ABA问题
（2）jdk 1.5 开始atomic包下提供了一个类AtomicStampedReference来解决ABA问题
这个类的compareAndSet方法作用是首先检查当前引用是否等于预期引用，并且当前标志是都等于预期标志
如果全部相等，就以原子方式将改引用和该标志的值设置为给定的更新值。

自旋锁

看下面程序的输出结果

public class CASTest {
	public static void main(String[] args) {
		//匿名内部类
		new Thread(new Runnable() {
			public void run() {
				System.out.println(Thread.currentThread().getName()+"开始执行");
				
				System.out.println(Thread.currentThread().getName()+"执行结束");				
			}
			
		}).start();
		
		new Thread(new Runnable() {
			@Override
			public void run() {
				System.out.println(Thread.currentThread().getName()+"开始执行");
				
				System.out.println(Thread.currentThread().getName()+"执行结束");			
			}
			
		}).start();
		
		System.out.println("主线程执行完毕");
	}
}

输出顺序

主线程执行完毕一定会在两个线程之前，因为是主线程

如何让主线程最后一个输出

public class CASTest {
	public static void main(String[] args) {
		//匿名内部类
		new Thread(new Runnable() {
			public void run() {
				System.out.println(Thread.currentThread().getName()+"开始执行");
				
				System.out.println(Thread.currentThread().getName()+"执行结束");				
			}
			
		}).start();
		
		new Thread(new Runnable() {
			@Override
			public void run() {
				System.out.println(Thread.currentThread().getName()+"开始执行");
				
				System.out.println(Thread.currentThread().getName()+"执行结束");			
			}
			
		}).start();
		//activeCount() 返回当前线程中活动线程数
		while(Thread.activeCount() != 1) {
			//自旋等待
		}
		System.out.println("主线程执行完毕");
		
	}
}

悲观锁和乐观锁

悲观锁

总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁
这样别人想拿这个数据就会阻塞直到他拿到锁（共享资源每次只给一个线程使用，其他线程阻塞，用完后在把资源转让给其他线程）
传统的关系型数据库里边就用到了很多这样锁机制，比如行锁，表锁，读锁，写锁，都是在操作之前先上锁

乐观锁

总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候就会判断一下在这个期间别人有没有更新这个数据。
可以使用版本号机制和CAS算法实现。乐观锁使用的场景是多读的应用类型，这样可以提高吞吐量。
write_condition机制，用的是乐观锁

synchronized的问题

synchronized保证线程的安全，但某些情况下，不是一个最优的选择

synchronized会让没有得到锁资源的线程进入阻塞状态，而后争夺到锁资源后恢复就绪状态，这个过程中涉及到操作系统用户模式和内核模式的切换，代价比较高，尽管jdk1.6为synchronized做了优化
增加了从偏向锁到轻量说在到重量锁的过度，但是在最终转变为重量级锁后，性能仍然较低