乐观锁与悲观锁
处理多线程并发访问最常用的就是加锁，锁又分成乐观锁和悲观锁。
悲观锁
在多线程访问共享资源时，同时只允许一个线程独享此资源，其他线程都被悲观锁阻塞，只有当前拥有锁的线程释放锁，其他线程才能被唤起竞争这个资源，每个线程在获取资源前都要悲观的检查该资源是否已经被占用，所以悲观锁的开销是巨大的，但安全性高，用synchronized关键字或者ReentrantLock都是悲观锁。
乐观锁
乐观锁假定在多线程修改共享资源时是有先后顺序的，不会发生同时修改的冲突，所以操作都不进行加锁，只是提交时检查是否有冲突，有冲突则失败，解决冲突的方法就是不断自旋重试，直到成功，所以乐观锁效率比悲观锁效率高，但也引入了自旋过多和ABA问题。
CAS
CAS全称是compareAndSwap，1.5中引入了java.util.concurrent包,其中乐观锁的实现就是基于CAS，它是建立在“硬件指令集”上来控制原子性的，常见的CAS操作有：
public final native boolean compareAndSwapObject(Object o, long offset, Object expected, Object x);
public final native boolean compareAndSwapInt(Object o, long offset, int expected, int x);
public final native boolean compareAndSwapLong(Object o, long offset, long expected, long x);
CAS的执行步骤是将指定地址的值与期待的值比较，如果相等则修改成新值，如果不相等则放弃修改，在AtomicInteger中就使用了CAS，自增中如果修改失败则自旋，重新获取新值继续自增
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;
}
CAS带来的问题
既然CAS能解决并发问题，那我们都使用CAS怎么样？
CAS虽然是一种多线程的解决方案，但其实是需要根据业务场景区分的，CAS带来的第一个问题就是ABA。
ABA问题
CAS比较的是该地址预期的值，如果在执行CAS期间，有其他的线程修改了值并且最终此值与原值相同，CAS是会忽略修改历史的，比如：
CAS前记录值为A，修改成B，在修改前值A被修改成C又修改成A，这时再执行CAS就会通过，程序无法知道修改历史，如果只是数值自增这样的逻辑不用在乎ABA问题，但如果业务逻辑需要关心值是否被修改过就需要解决ABA问题。
下面的例子存在ABA问题
Unsafe unsafe = getUnsafeInstance();
long offSet = 0;
try {
offSet = unsafe.objectFieldOffset(Integer.class.getDeclaredField("value"));
} catch (Exception ex) {
throw new Error(ex);
}
Integer value = 0;
long finalOffSet = offSet;
Thread thread1 = new Thread(()->{
boolean b = unsafe.compareAndSwapInt(value, finalOffSet, 0, 1);
boolean b1 = unsafe.compareAndSwapInt(value, finalOffSet, 1, 0);
System.out.println("result "+b +"-"+b1+" value "+ value);
});
Thread thread2 = new Thread(()->{
boolean b = unsafe.compareAndSwapInt(value, finalOffSet, 0, 3);
System.out.println("result "+b +" final value "+value);
});
thread1.start();
thread1.join();
thread2.start();
thread2.join();
取到Unsafe需要反射
public static Unsafe getUnsafeInstance() throws Exception{
Field unsafeStaticField =
Unsafe.class.getDeclaredField("theUnsafe");
unsafeStaticField.setAccessible(true);
return (Unsafe) unsafeStaticField.get(Unsafe.class);
}
输出
result true-true value 0
result true final value 3
可以看出有ABA问题并且修改都成功了。
解决这个问题可以引入版号，java中可以使用AtomicStampedReference来解决ABA问题
线程1将值从0自增成1，stamp增加1，线程2自增2，但stamp已经改变，修改失败
public static void main(String[] args) throws Exception {
AtomicStampedReference<Integer> atomicStampedReference = new AtomicStampedReference(0, 0);
Integer reference = atomicStampedReference.getReference();
int stamp = atomicStampedReference.getStamp();
Thread th1 = new Thread(() -> {
int stampT = stamp;
int newStamp = stampT + 1;
boolean b = atomicStampedReference.compareAndSet(reference, reference + 1, stampT, newStamp);
System.out.println("th1 result " + b);
});
Thread th2 = new Thread(() -> {
int stampT = stamp;
int newStamp = stampT + 1;
boolean b = atomicStampedReference.compareAndSet(reference, reference + 2, stampT, newStamp);
System.out.println("th2 result " + b);
});
th1.start();
th1.join();
th2.start();
th2.join();
}
输出
th1 result true
th2 result false
自旋过多问题
如果并发的比较厉害，修改失败的概率就会增加，失败后的自旋相应的也会增多，会影响效率。
所以CAS适用于预期不太会发生冲突或者冲突不多的情况，如果并发概率很大还是用悲观锁。
