Java并发编程系列之十六：Lock锁

Lock锁简介

Lock锁机制是JDK 5之后新增的锁机制，不同于内置锁，Lock锁必须显式声明，并在合适的位置释放锁。Lock是一个接口，其由三个具体的实现：ReentrantLock、ReetrantReadWriteLock.ReadLock 和 ReetrantReadWriteLock.WriteLock，即重入锁、读锁和写锁。增加Lock机制主要是因为内置锁存在一些功能上局限性。比如无法中断一个正在等待获取锁的线程，无法在等待一个锁的时候无限等待下去。内置锁必须在释放锁的代码块中释放，虽然简化了锁的使用，但是却造成了其他等待获取锁的线程必须依靠阻塞等待的方式获取锁，也就是说内置锁实际上是一种阻塞锁。而新增的Lock锁机制则是一种非阻塞锁（这点后面还会详细介绍）。

首先我们看看Lock接口的源码：

public interface Lock {
   
    //无条件获取锁
    void lock();
    //获取可响应中断的锁
    //在获取锁的时候可响应中断，中断的时候会抛出中断异常
    void lockInterruptibly() throws InterruptedException;
    //轮询锁。如果不能获得锁，则采用轮询的方式不断尝试获得锁
    boolean tryLock();
    //定时锁。如果不能获得锁，则每隔unit的时间就会尝试重新获取锁
    boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
    //释放获得锁
    void unlock();
    //获取绑定的Lock实例的条件变量。在等待某个条件变量满足的之
    //前，lock实例必须被当前线程持有。调用Condition的await方法
    //会自动释放当前线程持有的锁
    Condition newCondition();

注释写得很详细就不再赘述，可以看出Lock锁机制新增的可响应中断锁和使用公平锁是内置锁机制锁没有的。使用Lock锁的示例代码如下：

Lock lock = new ReentrantLock();
        lock.lock();
        try {
            //更新对象状态
            //如果有异常则捕获异常
            //必要时恢复不变性条件
            //如果由return语句必须放在这里
        }finally {
            lock.unlock();
        }

ReentrantLock与synchronized实现策略的比较

前面的文章有提到synchronized使用的是互斥锁机制，这种同步机制的最大问题在于当由多个线程需要获取通一把锁的时候只能通过阻塞同步的方式等待已经获得锁的线程自动释放锁。这个过程涉及线程的阻塞和线程的唤醒，这个过程需要在操作系统从用户态切换到内核态完成。那么问题来了，多个线程竞争同一把锁的时候，会引起CPU频繁的上下文切换，效率很低，系统开销也很大。这种策略被称为悲观并发策略，也是synchronized使用的并发策略。

ReentrantLock使用了更为先进的并发策略，既然互斥同步造成的阻塞会影响系统的性能，有没有一种办法不用阻塞也能实现同步呢？并发大师Doug Lea（也是Lock锁的作者）提出了以自旋的方式获得锁。简单来说，如果需要获得锁不存在争用的情况，那么获取成功；如果锁存在争用的情况，那么使用失败补偿措施（jdk 5之后到目前的jdk 8使用的是不断尝试重新获取，直到获取成功）解决争用的矛盾。由于自旋发生在线程内部，所以不用阻塞其他的线程，也就是实现了非阻塞同步。这种策略也称为基于冲突检测的乐观并发策略，也是ReentrantLock使用的并发策略。

简单总结ReentrantLock和synchronized，前者的先进性体现在以下几点：

1. 可响应中断的锁。当在等待锁的线程如果长期得不到锁，那么可以选择不继续等待而去处理其他事情，而synchronized的互斥锁则必须阻塞等待，不能被中断
2. 可实现公平锁。所谓公平锁指的是多个线程在等待锁的时候必须按照线程申请锁的时间排队等待，而非公平性锁则保证这点，每个线程都有获得锁的机会。synchronized的锁和ReentrantLock使用的默认锁都是非公平性锁，但是ReentrantLock支持公平性的锁，在构造函数中传入一个boolean变量指定为true实现的就是公平性锁。不过一般而言，使用非公平性锁的性能优于使