JAVA中锁的解决方案

前言

在上一节中，我们给大家介绍了什么是锁，以及锁的使用场景，我相信大家对锁的定义，以及锁的重要性都有了比较清晰的认识。在这一节中，我们会给大家继续做深入的介绍，介绍JAVA为我们提供的不同种类的锁。

JAVA为我们提供了种类丰富的锁，每种锁都有不同的特性，锁的使用场景也各不相同。由于篇幅有限，在这里只给大家介绍比较常用的几种锁。我们会通过锁的定义，核心代码剖析，以及使用场景来给大家介绍JAVA中主流的几种锁。

乐观锁与悲观锁

乐观锁与悲观锁应该是每个开发人员最先接触的两种锁。小编最早接触的就是这两种锁，但是不是在JAVA中接触的，而是在数据库当中。当时的应用场景主要是在更新数据的时候，更新数据这个场景也是使用锁的非常主要的场景之一。更新数据的主要流程如下：

检索出要更新的数据，供操作人员查看；
操作人员更改需要修改的数值；
点击保存，更新数据；

这个流程看似简单，但是我们用多线程的思维去考虑，这也应该算是一种互联网思维吧，就会发现其中隐藏着问题。我们具体看一下，

A检索出数据；
B检索出数据；
B修改了数据；
A修改数据，系统会修改成功吗？

当然啦，A修改成功与否，要看程序怎么写。咱们抛开程序，从常理考虑，A保存数据的时候，系统要给提示，说“您修改的数据已被其他人修改过，请重新查询确认”。那么我们程序中怎么实现呢？

在检索数据，将数据的版本号（version）或者最后更新时间一并检索出来；
操作员更改数据以后，点击保存，在数据库执行update操作；
执行update操作时，用步骤1检索出的版本号或者最后更新时间与数据库中的记录作比较；
如果版本号或最后更新时间一致，则可以更新；
如果不一致，就要给出上面的提示；

上述的流程就是乐观锁的实现方式。在JAVA中乐观锁并没有确定的方法，或者关键字，它只是一个处理的流程、策略。咱们看懂上面的例子之后，再来看看JAVA中乐观锁。

乐观锁呢，它是假设一个线程在取数据的时候不会被其他线程更改数据，就像上面的例子那样，但是在更新数据的时候会校验数据有没有被修改过。它是一种比较交换的机制，简称CAS（Compare And Swap）机制。一旦检测到有冲突产生，也就是上面说到的版本号或者最后更新时间不一致，它就会进行重试，直到没有冲突为止。

乐观锁的机制如图所示：

咱们看一下JAVA中最常用的i++,咱们思考一个问题，i++它的执行顺序是什么样子的？它是线程安全的吗？当多个线程并发执行i++的时候，会不会有问题？接下来咱们通过程序看一下：

public class Test {

    private int i=0;
    public static void main(String[] args) {
        Test test = new Test();
        //线程池：50个线程
        ExecutorService es = Executors.newFixedThreadPool(50);
        //闭锁
        CountDownLatch cdl = new CountDownLatch(5000);
        for (int i = 0;i < 5000; i++){
            es.execute(()->{
                test.i++;
                cdl.countDown();
            });
        }
        es.shutdown();
        try {
            //等待5000个任务执行完成后，打印出执行结果
            cdl.await();
            System.out.println("执行完成后，i="+test.i);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

上面的程序中，我们模拟了50个线程同时执行i++，总共执行5000次，按照常规的理解，得到的结果应该是5000，我们运行一下程序，看看执行的结果如何？

执行完成后，i=4975
执行完成后，i=4986
执行完成后，i=4971

这是我们运行3次以后得到的结果，可以看到每次执行的结果都不一样，而且不是5000，这是为什么呢？这就说明i++并不是一个原子性的操作，在多线程的情况下并不安全。我们把i++的详细执行步骤拆解一下：

从内存中取出i的当前值；
将i的值加1；
将计算好的值放入到内存当中；

这个流程和我们上面讲解的数据库的操作流程是一样的。在多线程的场景下，我们可以想象一下，线程A和线程B同时从内存取出i的值，假如i的值是1000，然后线程A和线程B再同时执行+1的操作，然后把值再放入内存当中，这时，内存中的值是1001，而我们期望的是1002，正是这个原因导致了上面的错误。那么我们如何解决呢？在JAVA1.5以后，JDK官方提供了大量的原子类，这些类的内部都是基于CAS机制的，也就是使用了乐观锁。我们将上面的程序稍微改造一下，如下：

public class Test {

    private AtomicInteger i = new AtomicInteger(0);
    public static void main(String[] args) {
        Test test = new Test();
        ExecutorService es = Executors.newFixedThreadPool(50);
        CountDownLatch cdl = new CountDownLatch(5000);
        for (int i = 0;i < 5000; i++){
            es.execute(()->{
                test.i.incrementAndGet();
                cdl.countDown();
            });
        }
        es.shutdown();
        try {
            cdl.await();
            System.out.println("执行完成后，i="+test.i);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

我们将变量i的类型改为AtomicInteger，AtomicInteger是一个原子类。我们在之前调用i++的地方改成了i.incrementAndGet()，incrementAndGet()方法采用了CAS机制，也就是说使用了乐观锁。我们再运行一下程序，看看结果如何。

执行完成后，i=5000
执行完成后，i=5000
执行完成后，i=5000

我们同样执行了3次，3次的结果都是5000，符合了我们预期。这个就是乐观锁。我们对乐观锁稍加总结，乐观锁在读取数据的时候不做任何限制，而是在更新数据的时候，进行数据的比较，保证数据的版本一致时再更新数据。根据它的这个特点，可以看出乐观锁适用于读操作多，而写操作少的场景。

悲观锁与乐观锁恰恰相反，悲观锁从读取数据的时候就显示的加锁，直到数据更新完成，释放锁为止。在这期间只能有一个线程去操作，其他的线程只能等待。在JAVA中，悲观锁可以使用synchronized关键字或者ReentrantLock类来实现。还是上面的例子，我们分别使用这两种方式来实现一下。首先是使用synchronized关键字来实现：

public class Test {

    private int i=0;
    public static void main(String[] args) {
        Test test = new Test();
        ExecutorService es = Executors.newFixedThreadPool(50);
        CountDownLatch cdl = new CountDownLatch(5000);
        for (int i = 0;i < 5000; i++){
            es.execute(()->{
                //修改部分  开始
                synchronized (test){
                    test.i++;
                }
                //修改部分  结束
                cdl.countDown();
            });
        }
        es.shutdown();
        try {
            cdl.await();
            System.out.println("执行完成后，i="+test.i);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

我们唯一的改动就是增加了synchronized块，它锁住的对象是test，在所有线程中，谁获得了test对象的锁，谁才能执行i++操作。我们使用了synchronized悲观锁的方式，使得i++线程安全。我们运行一下，看看结果如何。

执行完成后，i=5000
执行完成后，i=5000
执行完成后，i=5000

我们运行3次，结果都是5000，符合预期。接下来，我们再使用ReentrantLock类来实现悲观锁。代码如下：

public class Test {
    //添加了ReentrantLock锁
    Lock lock = new ReentrantLock();
    private int i=0;
    public static void main(String[] args) {
        Test test = new Test();
        ExecutorService es = Executors.newFixedThreadPool(50);
        CountDownLatch cdl = new CountDownLatch(5000);
        for (int i = 0;i < 5000; i++){
            es.execute(()->{
                //修改部分  开始
                test.lock.lock();
                test.i++;
                test.lock.unlock();
                //修改部分  结束
                cdl.countDown();
            });
        }
        es.shutdown();
        try {
            cdl.await();
            System.out.println("执行完成后，i="+test.i);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

我们在类中显示的增加了Lock lock = new ReentrantLock();，而且在i++之前增加了lock.lock(),加锁操作，在i++之后增加了lock.unlock()释放锁的操作。我们同样运行3次，看看结果。

执行完成后，i=5000
执行完成后，i=5000
执行完成后，i=5000

3次运行结果都是5000，完全符合预期。我们再来总结一下悲观锁，悲观锁从读取数据的时候就加了锁，而且在更新数据的时候，保证只有一个线程在执行更新操作，没有像乐观锁那样进行数据版本的比较。所以乐观锁适用于读相对少，写相对多的操作。

公平锁与非公平锁

前面我们介绍了乐观锁与悲观锁，这一小节我们将从另外一个维度去讲解锁——公平锁与非公平锁。从名字不难看出，公平锁在多线程情况下，对待每一个线程都是公平的；而非公平锁恰好与之相反。从字面上理解还是有些晦涩难懂，我们还是举例说明，场景还是去超市买东西，在储物柜存储东西的例子。储物柜只有一个，同时来了3个人使用储物柜，这时A先抢到了柜子，A去使用，B和C自觉进行排队。A使用完以后，后面排队中的第一个人将继续使用柜子，这就是公平锁。在公平锁当中，所有的线程都自觉排队，一个线程执行完以后，排在后面的线程继续使用。

非公平锁则不然，A在使用柜子的时候，B和C并不会排队，A使用完以后，将柜子的钥匙往后一抛，B和C谁抢到了谁用，甚至可能突然跑来一个D，这个D抢到了钥匙，那么D将使用柜子，这个就是非公平锁。

公平锁如图所示：

多个线程同时执行方法，线程A抢到了锁，A可以执行方法。其他线程则在队列里进行排队，A执行完方法后，会从队列里取出下一个线程B，再去执行方法。以此类推，对于每一个线程来说都是公平的，不会存在后加入的线程先执行的情况。

非公平锁入下图所示：

多个线程同时执行方法，线程A抢到了锁，A可以执行方法。其他的线程并没有排队，A执行完方法，释放锁后，其他的线程谁抢到了锁，谁去执行方法。会存在后加入的线程，反而先抢到锁的情况。

公平锁与非公平锁都在ReentrantLock类里给出了实现，我们看一下ReentrantLock的源码。

    /**
     * Creates an instance of {@code ReentrantLock}.
     * This is equivalent to using {@code ReentrantLock(false)}.
     */
    public ReentrantLock() {
        sync = new NonfairSync();
    }

    /**
     * Creates an instance of {@code ReentrantLock} with the
     * given fairness policy.
     *
     * @param fair {@code true} if this lock should use a fair ordering policy
     */
    public ReentrantLock(boolean fair) {
        sync = fair ? new FairSync() : new NonfairSync();
    }

ReentrantLock有两个构造方法，默认的构造方法中，sync = new NonfairSync();我们可以从字面意思看出它是一个非公平锁。再看看第二个构造方法，它需要传入一个参数，参数是一个布尔型，true是公平锁，false是非公平锁。从上面的源码我们可以看出sync有两个实现类，分别是FairSync和NonfairSync，我们再看看获取锁的核心方法，首先是公平锁FairSync的，

@ReservedStackAccess
protected final boolean tryAcquire(int acquires) {
    final Thread current = Thread.currentThread();
    int c = getState();
    if (c == 0) {
        if (!hasQueuedPredecessors() &&
            compareAndSetState(0, acquires)) {
            setExclusiveOwnerThread(current);
            return true;
        }
    }
    else if (current == getExclusiveOwnerThread()) {
        int nextc = c + acquires;
        if (nextc < 0)
            throw new Error("Maximum lock count exceeded");
        setState(nextc);
        return true;
    }
    return false;
}

然后是非公平锁NonfairSync的，

@ReservedStackAccess
final boolean nonfairTryAcquire(int acquires) {
    final Thread current = Thread.currentThread();
    int c = getState();
    if (c == 0) {
        if (compareAndSetState(0, acquires)) {
            setExclusiveOwnerThread(current);
            return true;
        }
    }
    else if (current == getExclusiveOwnerThread()) {
        int nextc = c + acquires;
        if (nextc < 0) // overflow
            throw new Error("Maximum lock count exceeded");
        setState(nextc);
        return true;
    }
    return false;
}

通过对比两个方法，我们可以看出唯一的不同之处在于!hasQueuedPredecessors()这个方法，很明显这个方法是一个队列，由此可以推断，公平锁是将所有的线程放在一个队列中，一个线程执行完成后，从队列中取出下一个线程，而非公平锁则没有这个队列。这些都是公平锁与非公平锁底层的实现原理，我们在使用的时候不用追到这么深层次的代码，只需要了解公平锁与非公平锁的含义，并且在调用构造方法时，传入true和false即可。

总结

JAVA中锁的种类非常多，在这一节中，我们找了非常典型的几个锁的类型给大家做了介绍。乐观锁与悲观锁是最基础的，也是大家必须掌握的。大家在工作中不可避免的都要使用到乐观锁和悲观锁。从公平锁与非公平锁这个维度上看，大家平时使用的都是非公平锁，这也是默认的锁的类型。如果要使用公平锁，大家可以在秒杀的场景下使用，在秒杀的场景下，是遵循先到先得的原则，是需要排队的，所以这种场景下是最适合使用公平锁的。

如想深入了解，请关注我们的《架构师课程》