ReentrantLock学习

　　

　　对于并发工作，你需要某种方式来防止两个任务访问相同的资源，至少在关键阶段不能出现这种冲突情况。防止这种冲突的方法就是当资源被一个任务使用时，在其上加锁。在前面的文章--synchronized学习中，我们学习了Java中内建的同步机制synchronized的基本用法，在本文中，我们来学习Java中另一种锁ReentrantLock。

ReentrantLock介绍

　　ReentrantLock，通常译为再入锁，是Java 5中新加入的锁实现，它与synchronized基本语义相同。再入锁通过代码直接调用lock()方法获取，代码书写更加灵活。与此同时，ReentrantLock提供了很多实用的方法，能够实现很多synchronized无法做到的细节控制，比如可以控制fairness，也就是公平性，或者利用定义条件等。但是，编码中也需要注意，必须要明确调用unlock()方法释放锁，不然就会一直持有该锁。

　　我们先看一个简单例子体验一下：

public class ReLockTest {

    private Lock lock = new ReentrantLock();

    public int shareState;

    public void add() {
        shareState ++ ;
    }

    public void printState() {
        System.out.println("shareState-->" + shareState);
    }

    public static void main(String[] args) throws Exception{
        ReLockTest reLockTest = new ReLockTest();
        Thread t1 = new Thread(()->{
            for(int i = 0; i<10000 ; i++)
                reLockTest.add();
        });
        Thread t2 = new Thread(()->{
            for(int i = 0; i<10000 ; i++)
                reLockTest.add();
        });
        t1.start();
        t2.start();
        t1.join();
        t2.join();
        Thread.sleep(2000);
        reLockTest.printState();
    }
}

/** 输出结果
 *  shareState-->14012
 */

　　我们看到输出结果小于20000，这就是线程不安全，我们加上同步之后再看结果：

public class ReLockTest {

    private Lock lock = new ReentrantLock();

    public int shareState;

    public void add() {
        lock.lock();
        try {
            shareState ++ ;
        }catch(Exception e) {
            e.printStackTrace();
        }finally {
            lock.unlock();
        }
    }

    public void printState() {
        System.out.println("shareState-->" + shareState);
    }

    public static void main(String[] args) throws Exception{
        ReLockTest reLockTest = new ReLockTest();
        Thread t1 = new Thread(()->{
            for(int i = 0; i<10000 ; i++)
                reLockTest.add();
        });
        Thread t2 = new Thread(()->{
            for(int i = 0; i<10000 ; i++)
                reLockTest.add();
        });
        t1.start();
        t2.start();
        t1.join();
        t2.join();
        Thread.sleep(2000);
        reLockTest.printState();
    }
}

/** 输出结果
 *  shareState-->20000
 */

　　

　　我们看到在将自增操作上锁之后，输出结果就达到预期了。这就是ReentrantLock的基本用法，为了保证锁释放，每个lock()动作都对应一个try-catch-finally，这可以说是一个惯用法：

ReentrantLock lock = new ReentrantLock();
lock.lock();
try {
    // do something
} finally {
     lock.unlock();
}

ReentrantLock用法

　　ReentrantLock相比synchronized，虽然所需的代码比synchronized关键字要多，但也是因为可以像普通对象一样使用，所以可以利用其提供的各种便利方法，进行精细的同步操作，甚至是synchronized难以表达的用例，如：

带超时的获取锁尝试

　　通过tryLock(long timeout, TimeUnit unit)方法实现，这是一个具有超时参数的尝试申请锁的方法，阻塞时间不会超过给定的值；如果成功则返回true。

可以指定公平性

　　在创建ReentrantLock对象时往构造器中传入true即指定创建公平锁，这里所谓的公平是指在竞争场景中，当公平性为真时，会倾向于将锁赋予等待时间最久的线程。公平性是减少线程“饥饿”(个别线程长期等待锁，但始终无法获取)情况的发生的一个办法。

　　如果使用synchronized，我们根本无法进行公平性的选择，其永远是不公平的，这也是主流操作系统线程调度的选择。通用场景中，公平性未必有想象中的那么重要，Java默认的调度策略很少会导致“饥饿”发生。与此同时，若要保证公平性则会引入额外开销，自然会导致一定的吞吐量下将。所以，只有当程序确实有公平性需要的时候，才有必要指定它。

可以响应中断请求

　　通过lockInterruptibly()获得锁，但是会不确定地发生阻塞。如果线程被中断，抛出一个InterruptedException异常。

可以创建条件变量，将复杂晦涩的同步操作转变为直观可控的对象行为

　　如果说ReentrantLock是synchronized的替代选择，Conition则是将wait、notify、notifyAll等操作转化为相应的对象，将复杂而晦涩的同步操作转变为直观可控的对象行为。

　　可以通过Condition上调用await()来挂起一个任务，当外部条件发生变化，你可以通过调用signal()来通知这个任务，从而唤醒一个任务，或者调用signAll()来唤醒所有在这个Condition上被其自身挂起的任务，这是Condition最常见的用法。一个典型的应用场景就是标准类库中的ArrayBlockingQueue，下面我们结合部分其源码来分析一下：

　　首先，在构造函数中初始化lock，在从lock中创建两个条件变量Condition分别是notEmpty和notFull。

/** Main lock guarding all access */
final ReentrantLock lock;

/** Condition for waiting takes */
private final Condition notEmpty;

/** Condition for waiting puts */
private final Condition notFull;

public ArrayBlockingQueue(int capacity, boolean fair) {
    if (capacity <= 0)
        throw new IllegalArgumentException();
    this.items = new Object[capacity];
    lock = new ReentrantLock(fair);
    notEmpty = lock.newCondition();
    notFull =  lock.newCondition();
}

　　然后在take方法中，判断和等待条件满足：

public E take() throws InterruptedException {
    final ReentrantLock lock = this.lock;
    lock.lockInterruptibly();
    try {
        while (count == 0)
            notEmpty.await();
        return dequeue();
    } finally {
        lock.unlock();
    }
}

　　在take方法中，如果队列为空，ArrayBlockingQueue的本义是获取对象的线程会阻塞，等待入队的发生，而不是直接返回，代码中是通过调用Condition的await方法来实现的，而当有元素入队之后又是如何触发被阻塞的take操作的呢？我们看看enqueue：

private void enqueue(E x) {
    // assert lock.getHoldCount() == 1;
    // assert items[putIndex] == null;
    final Object[] items = this.items;
    items[putIndex] = x;
    if (++putIndex == items.length)
        putIndex = 0;
    count++;
    notEmpty.signal();　　// 通知等待的线程
}

　　最后一行代码中就是通知等待的线程，这行执行结束后，被take阻塞的线程就会继续执行了。

　　通过signal/await的组合，完成了条件判断和通知等待线程，非常顺畅就完成了状态流转。signal和await成对调用非常重要，不然假设只有await动作，线程会一直等待直到被打断(interrupt)。

ReentrantLock与Synchronized

　　使用synchronized关键字时，需要写的代码量更少，而ReentrantLock的使用往往和try-catch-finally一起配套使用，代码量增加了。

　　从性能角度，synchronized早期的实现比较低效，对比ReentrantLock，大多数场景性能都相差较大。但是在Java 6中对其进行了非常多的改进(可以参考synchronized底层实现学习)，在高竞争情况下，ReentrantLock仍然有一定优势。

　　我们知道synchronized获取的锁是monitor对象，而ReentrantLock获取的锁是什么呢，是否也是同一把锁呢？下文中，我们会深入源码去探究ReentrantLock获取锁的实现细节。