JAVA---悲观锁与乐观锁

悲观锁

悲观锁总是假设最坏的情况，认为自己在使用数据的时候一定会有其他的线程来修改数据，因此在获取数据时先加锁，确保数据不会被别的线程修改。

synchronized和Lock实现类都是悲观锁。

悲观锁适合用于并发写入多，竞争激烈等场景，避免频繁失败和重试影响性能。

乐观锁

乐观锁总是假设最好的情况，认为自己在使用数据的时候不会有其他的线程来修改数据，无需加锁也无需等待，只是在提交数据的时候去检查有没有别的线程更新过数据。

乐观锁实现一般是利用CAS算法，java.util.concurrent.atomic里的原子类就是通过CAS自旋实现的。

乐观锁适合用于读取多，少部分修改、竞争不激烈的场景，避免频繁加锁影响性能，提升系统的吞吐量。

乐观锁存在哪些问题？

ABA问题

比如一个变量V的初始值为A，有3个线程在处理，线程1和线程2同时处理，线程1将V的值修改为B，在线程2赋值检查之前，线程3又将V的值修改回了A，线程2在赋值检查时V的值虽然仍然是A，但是V的值已经被线程1和3修改过了。CAS操作会误认为V的值从来没被修改过。这个问题被称为CAS操作的ABA问题。

解决思路是在变量前面追加上版本号或者时间戳。在JDK1.5之后，AtomicStampedReference类就是用来解决ABA问题的。compareAndSet方法就是先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值。

public boolean compareAndSet(V   expectedReference,
                             V   newReference,
                             int expectedStamp,
                             int newStamp) {
    Pair<V> current = pair;
    return
        expectedReference == current.reference &&
        expectedStamp == current.stamp &&
        ((newReference == current.reference &&
          newStamp == current.stamp) ||
         casPair(current, Pair.of(newReference, newStamp)));
}

循环时间长开销大

CAS经常会用到自旋操作来重试，如果一直不成功会一直循环重试，长时间不成功，会给CPU带来很大的开销。

只能保证一个共享变量的原子操作

CAS只对单个共享变量有效，当操作涉及跨多个共享变量时CAS无效。从JDK1.5版本后，AtomicReference类来保证引用对象的原子性，可以把多个变量放到一个对象里进行CAS操作。