Lock 解析，如何避免死锁？

前面聊了聊 synchronized，今天再聊聊 Lock。Lock 接口是 Java 5 引入的，最常见的实现类是 ReentrantLock、ReadLock、WriteLock，可以起到 “锁” 的作用。

PS：篇幅原因，这章不聊实现类，后面再聊，只专注于 Lock 以及它与 synchronized 的区别。

Lock 和 synchronized 是 java 中两种最常见的锁，"锁" 是一种工具。它用于控制对共享资源的访问。需要注意的是 Lock 设计的初衷并不是为了取代 synchronized ，而是一种升级。当 synchronized 不合适或者不能满足需求时（后面会说两者区别），Lock 顶上。

一般情况下，Lock 同一时间只允许一个线程来访问这个共享资源。但是也有特殊的时候允许并发访问。比如读写锁（ReadWriteLock）里面的读锁（ReadLock）。PS：这就是其中一个 synchronized 不能满足的场景。

Lock 的方法

如下图所示，Lock 有 5 个方法，1 个条件：

public interface Lock {
    void lock();
    void lockInterruptibly() throws InterruptedException;
    boolean tryLock();
    boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
    void unlock();
    Condition newCondition();
}

lock 加锁主要有 4 个方法：lock、lockInterruptibly、tryLock、tryLock (long time, TimeUnit unit) 。解锁只有一个 unlock 方法。此外，还有一个线程间通信的条件（Condition）。下面逐一讲解：

lock

Lock 有 4 种加锁方法，其中 lock 是最基础的。Lock 获取锁和释放锁都是显式的，不像  synchronized 是隐式的。所以 synchronized 会在抛异常时自动释放锁，而 Lock 只能是主动释放，加解锁都必须有显式的代码控制。所以就有了以下伪代码：

Lock lock = ...;
// 代码显式加锁
lock.lock();
try {
    //获取到了被本锁保护的资源，处理任务
    //捕获异常
} finally {
    //代码显式释放锁
    lock.unlock(); 
}

这种 lock 的写法才是最安全的，先获取 lock，然后在 try 中操作资源，最后 finally 中释放锁，以保证绝对释放（这一步非常重要，它防止代码走不到这里，导致跳过了 unlock () 语句，使得这个锁永远不能被释放）。

此外，lock () 方法有个缺点就是它不能被中断，一旦陷入死锁，lock () 就会陷入永久等待。所以，一般来说我们会用 tryLock 来代替 lock。

tryLock

tryLock 顾名思义是尝试获取锁的意思，返回值是 boolean，获取成功返回 true，获取失败返回 false*。使用方法如下：

Lock lock = ...;
if (lock.tryLock()) {
    try {
        //操作资源
    } finally {
        //释放锁
        lock.unlock();
    }
} else {
    //如果不能获取锁，则做其他事情
}

使用 if 判断是否获取锁，成功获取则去操作共享资源，失败则去干别的事（比如，几秒之后重试，或者跳过此任务），最后还是记得要在 finally 中释放锁。

tryLock 解决死锁问题

想象这样一个场景：比如有两个线程同时调用以下这个方法，传入的 lock1 和 lock2 恰好是相反的。如果第一个线程获取了 lock1，第二个线程获取了 lock2，两个线程都需要获取对方的锁才能工作。如果用 lock 这就很容易陷入死锁，原因前面也说了。

这个时候 tryLock 就发挥作用了：其中一个线程尝试获取锁 lock1，获取不到，则去隔段时间重试（这样做的目的在于等另一个获取到锁的线程在这段时间内完成任务，释放锁）。获取到了，则继续获取 lock2 ，获取到就操作共享资源，获取不到则释放 lock1，继续进入重试。

public void tryLock(Lock lock1, Lock lock2) throws InterruptedException {
    while (true) {
        if (lock1.tryLock()) {
            try {
                if (lock2.tryLock()) {
                    try {
                        System.out.println("获取到了两把锁，完成业务逻辑");
                        return;
                    } finally {
                        lock2.unlock();
                    }
                }
            } finally {
                lock1.unlock();
            }
        } else {
            Thread.sleep(new Random().nextInt(1000));
        }
    }
}

tryLock(long time, TimeUnit unit)

这个方法是 tryLock 的重载，区别在于 tryLock (long time, TimeUnit unit) 方法会有一个超时时间。在拿不到锁时会等待指定的时间，在指定时间内获取不到锁返回 false；获取到锁或者等待期间内获取到锁，返回 true。

此外，超时之后，它将放弃主动获取锁。它还可以响应中断，抛出 InterruptException，避免死锁的产生。

lockInterruptibly

lockInterruptibly 去获取锁，获取到了马上返回 true。它非常执拗，如果获取不到锁就会一直尝试获取直到获取到为止，除非当前线程在获取锁期间被中断。可以把它理解为不限时的 tryLock (long time, TimeUnit unit)。

public void lockInterruptibly() throws InterruptException {
    lock.lockInterruptibly();
    try {
        System.out.println("操作资源");
    } finally {
        lock.unlock();
    }
}

unlock

unlock 顾名思义就是释放锁。就 ReentrantLock 而言，调用 unlock 方法时，内部会把锁的 “被持有计数器” 减 1，减到 0 代表当前线程已经完全释放这把锁。

newCondition()

Condition 的用法就不说了，不会的看之前这篇文章：线程之生产者消费者模式。它有两个主要的方法 await 和 signal 分别用于阻塞线程和唤醒线程。对应于 Object 的 wait 和 notify。