乐观锁与悲观锁

处理多线程并发访问最常用的就是加锁，锁又分成乐观锁和悲观锁。

悲观锁

在多线程访问共享资源时，同时只允许一个线程独享此资源，其他线程都被悲观锁阻塞，只有当前拥有锁的线程释放锁，其他线程才能被唤起竞争这个资源，每个线程在获取资源前都要悲观的检查该资源是否已经被占用，所以悲观锁的开销是巨大的，但安全性高，用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适用于预期不太会发生冲突或者冲突不多的情况，如果并发概率很大还是用悲观锁。