lock是悲观锁还是乐观锁_乐观锁与悲观锁

乐观锁与悲观锁之前略有了解，没想到上次面试正好被面试官问到，感觉撞了大运哈哈......今天对这个问题来总结一下，文章如有错误之处，欢迎各位指正。首先我们来介绍一下何为乐观锁？何为悲观锁？

乐观锁

我们都知道，锁的出现是为了保护共享资源的独占性的，避免多个线程同时操作一个共享资源。从名字就可以看出来，乐观锁就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断在此期间别人有没有去更新这个数据，具体方法可以使用版本号机制和CAS算法（后面会说到这两种方式，现在了解即可） 。

悲观锁

乐观锁总是假设最好的情况，而悲观锁总是假设最坏的情况，每次拿数据的时候都认为别人会修改，所以每次拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。Java中 synchronized和 ReentrantLock等独占锁就是悲观锁思想的实现。

下面我们来说一下乐观锁的两种实现机制：版本号机制和CAS算法

版本号机制

版本号机制一般是在数据表中加上一个数据版本号version字段，它代表数据被修改的次数，当数据被修改时，version的值会加1。当一个线程要更新数据值时，在读取数据的同时也会读取version字段的值，在提交更新的时候，如果之前读取的version值与当前数据库中version值相等时才进行更新，同时将version值+1；否则重新读取数据和version值，尝试更新，直到更新成功。

下面举一个简单的例子来进一步说明该机制：

假设数据库中帐户信息表中有一个 version 字段，当前值为 1 ；而当前帐户余额字段（ balance ）为 $100 。

1. 操作员 A 此时将其读出（ version=1 ），并从其帐户余额中扣除 $50（ $100-$50 ）。
2. 在操作员 A 操作的过程中，操作员B 也读入此用户信息（ version=1 ），并从其帐户余额中扣除 $20 （ $100-$20 ）。
3. 操作员 A 完成了修改工作，将数据版本号加一（ version=2 ），连同帐户扣除后余额（ balance=$50 ），提交至数据库更新，此时由于提交数据版本大于数据库记录当前版本，数据被更新，数据库记录 version 更新为 2 。
4. 操作员 B 完成了操作，也将版本号加一（ version=2 ）试图向数据库提交数据（ balance=$80 ），但此时比对数据库记录版本时发现，操作员 B 提交的数据版本号为 2 ，数据库记录当前版本也为 2 ，不满足 “ 提交版本必须大于记录当前版本才能执行更新 “ 的乐观锁策略，因此，操作员 B 的提交被驳回。

这样，就避免了操作员 B 用基于 version=1 的旧数据修改的结果覆盖操作员A 的操作结果的可能。

CAS算法

CAS是一种著名的无锁算法，即compare and swap（比较与交换）。什么是无锁算法呢？直白来说就是在不使用锁的情况下实现多线程之间的变量同步，也就是在没有线程被阻塞的情况下实现变量的同步，因此也被称为非阻塞同步算法（non-blocking synchronization）。 CAS操作中包含三个操作数：需要读写的内存位置（V）、进行比较的预期原值（A）和拟写入的新值（B）。如果内存位置V的值与预期原值A相匹配，那么处理器会自动将该位置值更新为新值B。否则处理器不做任何操作。简单来说，CAS的算法思想可以解释为“ 我认为位置 V 应该包含值 A；如果包含该值，则将 B 放到这个位置；否则，不要更改该位置，只告诉我这个位置现在的值即可。”一般情况下，该操作是一个自旋操作（详细解释我们后面再说），即不断的尝试。

关于乐观锁和悲观锁，没有谁好谁坏之说，各有利弊，只是适用的场景不同罢了。根据我们前面的解释，不难理解，乐观锁适合于多读少写的场景，此时冲突较少；而悲观锁则适用于多写的场景，此时冲突较多。

乐观锁在使用的时候，会出现一下几个问题，其中最著名的就是ABA问题：所谓ABA问题，指的是如果一个变量V初次读取的时候是A值，并且在准备赋值的时候检查到它仍然是A值，那我们就能说明它的值没有被其他线程修改过了吗？很明显是不能的，因为在这段时间它的值可能被改为其他值，然后又改回A，那CAS操作就会误认为它从来没有被修改过。举一个简单的例子，假设我们有一个链表，表头为head，线程A想将表头删掉，用后面一个节点取代，在此过程中，线程B在链表的尾部新增了一个节点，当线程A进行值的更新的时候，发现表头依然是head，和预期一样，然后进行更新，但是此时链表已经不是原来的那个链表了，而是被线程B修改过的。

第二个问题就是乐观锁中自旋CAS如果长时间不成功，会给CPU带来非常大的开销。

第三个问题是CAS 只对单个共享变量有效，当操作涉及跨多个共享变量时CAS无效。但是从 JDK 1.5开始，提供了 AtomicReference类来保证引用对象之间的原子性，你可以把多个变量放在一个对象里来进行 CAS 操作.所以我们可以使用锁或者利用 AtomicReference类把多个共享变量合并成一个共享变量来操作。

好了，最后我们来解释一下前面提到的自旋锁是什么？自旋锁（spinlock） 是指当一个线程在获取锁的时候，如果锁已经被其它线程获取，那么该线程将循环等待，然后不断的判断锁是否能够被成功获取，直到获取到锁才会退出循环。这种获取锁的线程一直处于活跃状态，但是并没有执行任何有效的任务。其实现如下：

public class SpinLock {
    private AtomicReference<Thread> cas = new AtomicReference<Thread>();
    public void lock() {
        Thread current = Thread.currentThread();
        // 利用CAS
        while (!cas.compareAndSet(null, current)) {
            // DO nothing
        }
    }
    public void unlock() {
        Thread current = Thread.currentThread();
        cas.compareAndSet(current, null);
    }
}

可以看出，lock()方法利用的CAS，当第一个线程A获取锁的时候，能够成功获取到，不会进入while循环，如果此时线程A没有释放锁，另一个线程B又来获取锁，此时由于不满足CAS，所以就会进入while循环，不断判断是否满足CAS，直到A线程调用unlock()方法释放了该锁。

自旋锁的优缺点也是显而易见的，它的好处就是不会使线程状态发生切换，一直处于用户态，即线程一直都是active的；不会使线程进入阻塞状态，减少了不必要的上下文切换，执行速度快。缺点就是如果某个线程持有锁的时间过长，就会导致其它等待获取锁的线程进入循环等待，消耗CPU。使用不当会造成CPU使用率极高。