Lock锁

Lock是自JDK1.5起在Java并发包(JUC)中提供的锁。与synchronized相比，Lock提供了更加灵活的、可扩展的锁相关操作。支持多个与锁相关的条件。

锁本质上是用于控制多个线程对共享资源访问的工具。 通常，锁提供对共享资源的独占访问，一次只有一个线程可以获取锁，所有对共享资源的访问都需要先获取锁。 但是，某场景下可能允许并发访问共享资源，例如对某个共享资源的读操作，这就要求锁具备这个功能。Lock接口的一个具体实现：ReadWriteLock就可以实现多个线程同时读。这种特性是synchronized不具备的。

synchronized方法或代码块隐式提供了对每个对象关联的监视器锁(monitor)的访问，所有锁的获取和释放必须在一个代码块结构中。即当获取多个锁时，它们必须以相反的顺序释放，并且所有锁必须在它们被获取的同一个代码范围内释放。

虽然synchronized方法和代码块的作用域机制使得我们实现并发编程更加容易，避免了许多涉及锁的常见编程错误。但在某些情况下，我们需要以更灵活的方式使用锁。 比如我们需要先获取A锁，然后获取B锁，接着释放A锁获取C锁，然后释放B锁获取D锁。像这种复杂的场景，synchronized无能为力。而Lock接口的实现允许在不同范围内获取和释放锁，并允许以任何顺序获取和释放多个锁。

这种灵活性也要求我们必须控制好锁的获取和释放。不像synchronized那样，锁的获取和释放是由底层自动实现的，编程中只要使用关键字就行了。

因此在通常情况下，我们应该是遵循下列使用Lock的习惯：

 Lock lock = ...;lock.lock();try {// access the resource protected by this lock} finally {lock.unlock();}

当锁定和解锁发生在不同的作用域时，必须确保持有锁时执行的所有代码都受到 try-finally 或 try-catch 的保护，以保证在必要时释放锁。

Lock的实现提供了多种形式的锁。

1）非阻塞方式获取锁：tryLock()；

2）可中断的方式获取锁：lockInterruptibly()；

3）获取锁时还可以加入超时时间：tryLock(long, TimeUnit)；

Lock实例只是普通对象，它们本身也可以用作synchronized语句中的目标对象。 获取Lock实例的监视器锁(monitor)与调用该实例的任何lock方法没有特定的关系。 建议不要在synchronized方法或者代码块中使用Lock实例作为锁定的对象，以避免混淆。

Lock锁的方法

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

lock

以阻塞的方式获取锁，如果获取锁失败，则该线程进入休眠状态，线程调度被暂停，直到获得锁。

lockInterruptibly

与lock方法相比，该方法可以响应中断。

如果获取锁成功则立即返回。否则线程进入休眠状态，暂停被线程调度，直到下列情况发生：

1）获取到锁

2）其它线程中断了该线程，并且支持锁获取中断

如果当前线程在获取锁时被中断（并且支持中断获取锁）则该方法会抛出一个InterruptedException。

tryLock

以非阻塞方式获取锁，如果锁可用则返回true；如果不可用则立即返回false，而不是阻塞线程。

一贯用法如下：

 Lock lock = ...;if (lock.tryLock()) {try {// 业务逻辑A} finally {lock.unlock();}} else {// 业务逻辑B}

tryLock(long time, TimeUnit unit)

和tryLock方法相比，多了支持设置等待时间和中断响应。

如果锁可用，则此方法立即返回true。 如果锁不可用，则当前线程将出于线程调度目的而被禁用并处于休眠状态，直到以下三种情况之一发生：

1）锁被当前线程获取到

2）其他一些线程中断当前线程，并且支持中断获取锁

3）经过了指定的等待时间

如果当前线程在获取锁时被中断（支持中断获取锁的前提下），则该方法会抛出一个InterruptedException。

unlock

有加锁，必然有释放锁。unlock方法就是用于释放锁。

newCondition

Lock锁提供了一个与之相关的条件对象(Condition)。该方法就是返回绑定到此Lock实例的新Condition实例。

在等待Condition条件之前，当前线程必须先持有与Condition相关联的锁。 调用Condition.await()方法将在等待之前自动释放锁，并在等待返回之前重新获取锁。

后面会介绍具体的案例。

Lock锁的优势

当一个线程调用了synchronized方法之后，如果没有成功获取到锁，就立即陷入了等待，没有第二种选择。而Lock锁可以选择不同的方式，可以立即陷入等待，也可以立即返回，也可以等待一段时间。具体看你调用哪个API方法。

Lock锁的使用案例

Lock是一个接口，其有多种实现类，常用的有ReentrantLock、ReentrantReadWriteLock等，我们一一举例。

ReentrantLock

ReentrantLock是Lock接口最常用的实现类，它一个可重入的锁，可以认为和synchronized具有相同的语义，但更具扩展性。

ReentrantLock锁会被最近一次成功获取到锁的但还未释放锁的线程拥有。ReentrantLock的lock方法会在成功获取到锁时返回，如果检测到当前线程已经拥有了该锁，则该方法立即返回。

ReentrantLock的构造函数接受一个可选的公平参数。当设置为为true，即公平锁时，锁倾向于授予等待时间最长的线程。反之，不能保证任何特定的锁的获取顺序，即非公平。

注意，在高并发场景下，多个线程访问的公平锁的程序可能会显示出较低的总体吞吐量（即更慢，通常慢得多）。并且在公平性方面(保证不出现饿死的情况)和非公平锁的差异也很小。

另外，锁的公平性并不能保证线程调度的公平性。因此，使用公平锁的众多线程之一可能会连续多次获得它，而其他活动线程一直没能够持有该锁。特别要强调的是，使用没有设置等待时间的tryLock()方法是不遵守公平性设置的。

ReentrantLock典型的使用模式如下：

class X {private final ReentrantLock lock = new ReentrantLock();// ...public void method() {lock.lock();  // block until condition holdstry {// ... method body} finally {lock.unlock()}}}

举例1：快速入门

下面的例子中，方法method1中会对成员变量count自增，而自增操作不是一个原子操作，有读数据、加法操作、写数据多个步骤。因此需要加锁保证多线程环境下的并发安全。

加锁时，能保证输出的结果是正确的累计值；而不加锁时，输出的最终结果可能小于预期。可以对比下加锁和不加锁的运行结果。

public class TestLock {private ReentrantLock lock = new ReentrantLock();private int count = 0;public void method1() {//lock.lock();//注释这行代码取消加锁try {Thread.sleep(1000);System.out.println(++count);} catch (InterruptedException e) {e.printStackTrace();} finally {//lock.unlock();}}public static void main(String[] args) {TestLock testLock = new TestLock();//创建多个线程对共享变量同时进行操作for (int i = 0; i < 20000; i++) {new Thread(new Runnable() {@Overridepublic void run() {testLock.method1();}}).start();}}
}

举例2：基本使用

public class Test1 {private Lock lock = new ReentrantLock();public void method1() {try {lock.lock();System.out.println("method1 business");} finally {lock.unlock();}}public void method2() {try {lock.lock();System.out.println("method2 business");} finally {lock.unlock();}}public static void main(String[] args) {Test1 test = new Test1();Thread thread1 = new Thread(() -> {for (int i = 0; i < 10; i++) {test.method1();try {Thread.sleep(200);} catch (InterruptedException e) {e.printStackTrace();}}});Thread thread2 = new Thread(() -> {for (int i = 0; i < 10; i++) {test.method2();try {Thread.sleep(500);} catch (InterruptedException e) {e.printStackTrace();}}});thread1.start();thread2.start();}
}

上述案例展示了多个方法共享一把锁的场景，运行程序，我们可以看到程序正常输出20次，两个线程交替执行完成。

如果我们忘记了释放锁，此时会发生什么情况呢？比如注释掉第一个方法的释放锁操作。

    public void method1() {try {lock.lock();System.out.println("method1 business");} finally {//lock.unlock();}}

此时只输出了10次method1 business，并且程序没有终止。因为method1 先被调用，并且一直持有锁没有释放，导致method2获取锁失败，一直等待 。然而method1 可以不断重新获取锁(可重入的)，因此第一个线程循环调用method1方法后输出。

上述使用Lock的方式和synchronized类似，都是一直等待，直到获得锁。

在实际开发中要遵循try{...}finally{...}这种使用Lock锁的范式，防止锁得不到释放。

上述代码method2方法改进为使用tryLock，则可以避免程序阻塞，虽然获取锁失败，但是程序最终能执行完成，示例如下。

public void method2() {
//        try {
//            lock.lock();
//            System.out.println("method2 business");
//        } finally {
//            lock.unlock();
//        }boolean success = false;try {success = lock.tryLock(1000, TimeUnit.MILLISECONDS);} catch (InterruptedException e) {e.printStackTrace();}if (success) {System.out.println("lock success");} else {System.out.println("lock fail");}}

举例3：可重入性

下列例子中，虽然get方法中也要获取锁，但是并不会导致死锁，因为ReentrantLock 支持重入。

public class Test02 extends Thread {private ReentrantLock lock = new ReentrantLock();public void get() {lock.lock();try {System.out.println("get方法" + Thread.currentThread().getName());} finally {lock.unlock();}}public void set() {lock.lock();try {System.out.println("set方法" + Thread.currentThread().getName());get();//虽然get方法中也要获取锁，但是不会死锁，因为ReentrantReadWriteLock 支持重入} catch (Exception e) {e.printStackTrace();} finally {lock.unlock();}}@Overridepublic void run() {set();}public static void main(String[] args) {for (int i = 0; i < 4; i++) {Test02 ss = new Test02();ss.start();}}
}//输出
set方法Thread-0
get方法Thread-0
set方法Thread-1
set方法Thread-2
get方法Thread-1
get方法Thread-2
set方法Thread-3
get方法Thread-3

公平锁、非公平锁

如果在绝对时间上，先对锁进行获取的请求一定会先被满足，那么这个锁是公平的，反之，是不公平的。公平的获取锁，也就是等待时间最长的线程最优先获取锁，也可以说锁获取是顺序的。

ReentrantLock类提供了一个构造函数，通过传入fair参数控制锁是否是公平的。

1）公平锁

公平和非公平锁的队列都基于锁内部维护的一个双向链表，表结点Node的值就是每一个请求当前锁的线程。公平锁每次都是依次从队首取值。

2）非公平锁

在等待锁的过程中， 如果有任意新的线程妄图获取锁，都是有很大的几率直接争抢到锁的。

公平锁是先到先得，按序进行。非公平锁就是不排队直接拿，失败再说。公平锁保证了锁的获取按照FIFO原则，而代价是进行大量的线程切换。非公平性锁虽然可能造成线程“饥饿”，但由于先尝试争抢，失败后才阻塞，因此最大限度减少线程切换，具有更大的吞吐量。

ReentrantReadWriteLock

前面提到锁（如ReentrantLock、synchronized）都是排他锁，这些锁在同一时刻只允许一个线程进行访问，而读写锁在同一时刻可以允许多个读线程访问。在写线程访问时，所有的读线程和其他写线程均被阻塞。读写锁维护了一对锁，一个读锁和一个写锁，通过分离读锁和写锁，使得并发性相比一般的排他锁有了很大提升。
假设你的程序中涉及到对一些共享资源的读和写操作，且写操作没有读操作那么频繁。在没有写操作的时候，两个线程同时读一个资源没有任何问题，那么应该允许多个线程能同时读取共享资源。但是如果有一个线程去写这些共享资源，就不应该再有其它线程对该资源进行读或写（也就是说：读-读能共存，读-写不能共存，写-写不能共存）。这就需要一个读/写锁来解决这个问题。

JDK5引入的ReentrantReadWriteLock 就可以来实现读写锁。

案例1：快速入门

分别使用读锁和写锁，从运行效果可以发现读锁是可以共享的，而写锁是独占的；

因此读锁可以近乎同时完成操作，而写锁是排他的，需要等待前一个线程操作完成并释放掉锁，下一个线程才能进行操作。

public class ReadWriteLockTest {private ReadWriteLock readWriteLock = new ReentrantReadWriteLock();public void method1() {//readWriteLock.readLock().lock();readWriteLock.writeLock().lock();try {Thread.sleep(1000);System.out.println("method1 business");} catch (Exception e) {e.printStackTrace();} finally {//readWriteLock.readLock().unlock();readWriteLock.writeLock().unlock();}}public static void main(String[] args) {ReadWriteLockTest readWriteLockTest = new ReadWriteLockTest();IntStream.range(0, 10).forEach(i -> new Thread(readWriteLockTest::method1).start());}
}

案例2：自定义缓存

我们以一个自定义缓存的例子来演示读写锁的使用。

public class Cache {static Map<String, Object> map = new HashMap<String, Object>();static ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();static Lock r = rwl.readLock();static Lock w = rwl.writeLock();// 获取一个key对应的valuepublic static final Object get(String key) {r.lock();try {//为了演示出效果，get操作再细分如下，开始—>结束视为原子步骤System.out.println("正在做读的操作,key:" + key + " 开始");Thread.sleep(100);Object object = map.get(key);System.out.println("正在做读的操作,key:" + key + ",value:" + object + " 结束");System.out.println();return object;} catch (InterruptedException e) {e.printStackTrace();} finally {r.unlock();}return key;}// 设置key对应的value，并返回旧有的valuepublic static final Object put(String key, Object value) {w.lock();try {//为了演示效果，set操作再细分如下，开始—>结束整个过程视为原子步骤System.out.println("正在做写的操作,key:" + key + ",value:" + value + "开始.");Thread.sleep(100);Object object = map.put(key, value);System.out.println("正在做写的操作,key:" + key + ",value:" + value + "结束.");System.out.println();return object;} catch (InterruptedException e) {e.printStackTrace();} finally {w.unlock();}return value;}// 清空所有的内容public static final void clear() {w.lock();try {map.clear();} finally {w.unlock();}}public static void main(String[] args) {new Thread(new Runnable() {@Overridepublic void run() {for (int i = 0; i < 10; i++) {Cache.put(i + "", i + "");}}}).start();new Thread(new Runnable() {@Overridepublic void run() {for (int i = 0; i < 10; i++) {Cache.get(i + "");}}}).start();}
}//输出
正在做读的操作,key:0 开始
正在做读的操作,key:0,value:null 结束正在做写的操作,key:0,value:0开始.
正在做写的操作,key:0,value:0结束.正在做读的操作,key:1 开始
正在做读的操作,key:1,value:null 结束正在做写的操作,key:1,value:1开始.
正在做写的操作,key:1,value:1结束.正在做读的操作,key:2 开始
正在做读的操作,key:2,value:null 结束正在做写的操作,key:2,value:2开始.
正在做写的操作,key:2,value:2结束.正在做读的操作,key:3 开始
正在做读的操作,key:3,value:null 结束正在做写的操作,key:3,value:3开始.
正在做写的操作,key:3,value:3结束.正在做写的操作,key:4,value:4开始.
正在做写的操作,key:4,value:4结束.正在做读的操作,key:4 开始
正在做读的操作,key:4,value:4 结束正在做写的操作,key:5,value:5开始.
正在做写的操作,key:5,value:5结束.正在做读的操作,key:5 开始
正在做读的操作,key:5,value:5 结束正在做写的操作,key:6,value:6开始.
正在做写的操作,key:6,value:6结束.正在做读的操作,key:6 开始
正在做读的操作,key:6,value:6 结束正在做写的操作,key:7,value:7开始.
正在做写的操作,key:7,value:7结束.正在做读的操作,key:7 开始
正在做读的操作,key:7,value:7 结束正在做写的操作,key:8,value:8开始.
正在做写的操作,key:8,value:8结束.正在做读的操作,key:8 开始
正在做读的操作,key:8,value:8 结束正在做写的操作,key:9,value:9开始.
正在做写的操作,key:9,value:9结束.正在做读的操作,key:9 开始
正在做读的操作,key:9,value:9 结束

一般而言，读写锁的性能都会比排它锁好，因为大多数场景读是多于写的。在读多于写的情况下，读写锁能够提供比排它锁更好的并发性和吞吐量。

上述案例中，Cache使用了一个非线程安全的HashMap作为缓存的存储结构，同时使用读写锁的读锁和写锁来保证Cache是线程安全的。在读操作get(String key)方法中，需要获取读锁，这使得并发访问该方法时不会被阻塞。写操作put(String key,Object value)方法和clear()方法，在更新HashMap时必须提前获取写锁，当获取写锁后，其他线程对于读锁和写锁的获取均被阻塞，而只有写锁被释放之后，其他读写操作才能继续。Cache使用读写锁提升读操作的并发性，也保证每次写操作对所有的读写操作的可见性。

Lock与Synchronized的比较

可以从4个方面来对比基于Java API的Lock锁和基于Java关键字Synchronized的同步锁

1）锁的获取：Lock是JDK提供的API，通过编程的方式手动获取锁。而synchronized是Java关键字，底层通过JVM自动获取锁。

2）锁的实现：Lock锁是JDK自带的，是以Java代码方式实现的。而synchronized底层是通过JVM 调用操作系统的系统函数实现的。

3）锁的释放：Lock锁需要通过unlock手动释放，而synchronized是JVM自动释放的。

4）锁的类型：Lock锁提供了灵活多样的锁，比如公平锁、非公平锁、读写锁、可重入锁；而synchronized只支持可重入。

使用上面缓存代码的案例，来比较一下两者的性能。

基于Lock

public class Cache1 {static Map<String, Object> map = new HashMap<>();static ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();static Lock r = rwl.readLock();static Lock w = rwl.writeLock();// 获取一个key对应的valuepublic static final Object get(String key) {r.lock();try {//为了演示出效果，get操作再细分如下，开始—>结束视为原子步骤System.out.println("正在做读的操作,key:" + key + " 开始");Thread.sleep(10);Object object = map.get(key);System.out.println("正在做读的操作,key:" + key + ",value:" + object + " 结束");System.out.println();return object;} catch (InterruptedException e) {e.printStackTrace();} finally {r.unlock();}return key;}// 设置key对应的value，并返回旧有的valuepublic static final Object put(String key, Object value) {w.lock();try {//为了演示效果，set操作再细分如下，开始—>结束整个过程视为原子步骤System.out.println("正在做写的操作,key:" + key + ",value:" + value + "开始.");Thread.sleep(10);Object object = map.put(key, value);System.out.println("正在做写的操作,key:" + key + ",value:" + value + "结束.");System.out.println();return object;} catch (InterruptedException e) {e.printStackTrace();} finally {w.unlock();}return value;}// 清空所有的内容public static final void clear() {w.lock();try {map.clear();} finally {w.unlock();}}public static void main(String[] args) throws InterruptedException {long start = System.currentTimeMillis();Thread t1 = new Thread(() -> {for (int i = 0; i < 3000; i++) {Cache1.put(i + "", i + "");}});Thread t2 = new Thread(() -> {for (int i = 0; i < 3000; i++) {Cache1.get(i + "");}});t1.start();t2.start();System.out.println("waiting...");t1.join();t2.join();long end = System.currentTimeMillis();System.out.println("Lock cost:" + (end - start));}
}

基于synchronized

public class Cache2 {static Map<String, Object> map = new HashMap<>();// 获取一个key对应的valuepublic static synchronized final Object get(String key) throws InterruptedException {//为了演示出效果，get操作再细分如下，开始—>结束视为原子步骤System.out.println("正在做读的操作,key:" + key + " 开始");Thread.sleep(10);Object object = map.get(key);System.out.println("正在做读的操作,key:" + key + ",value:" + object + " 结束");System.out.println();return object;}// 设置key对应的value，并返回旧有的valuepublic static synchronized final Object put(String key, Object value) throws InterruptedException {//为了演示效果，set操作再细分如下，开始—>结束整个过程视为原子步骤System.out.println("正在做写的操作,key:" + key + ",value:" + value + "开始.");Thread.sleep(10);Object object = map.put(key, value);System.out.println("正在做写的操作,key:" + key + ",value:" + value + "结束.");System.out.println();return object;}// 清空所有的内容public static synchronized final void clear() {map.clear();}public static void main(String[] args) throws InterruptedException {long start = System.currentTimeMillis();Thread t1 = new Thread(() -> {for (int i = 0; i < 3000; i++) {try {Cache2.put(i + "", i + "");} catch (InterruptedException e) {e.printStackTrace();}}});Thread t2 = new Thread(() -> {for (int i = 0; i < 3000; i++) {try {Cache2.get(i + "");} catch (InterruptedException e) {e.printStackTrace();}}});t1.start();t2.start();System.out.println("waiting...");t1.join();t2.join();long end = System.currentTimeMillis();System.out.println("synchronized cost:" + (end - start));}
}

对比发现两者没有太明显的差异，从侧面印证了JDK1.6之后synchronized的性能提升。

Lock锁的原理

Lock锁的底层基于AQS实现，下面简单阐述一下Lock锁的实现步骤。后面会对AQS作详细介绍。

ReentrantLock

1）当调用了ReentrantLock的lock方法时，当前线程尝试获取对象的锁，如果已经有其它线程持有了该锁，则获取失败，该线程进入到AQS的阻塞队列中

2）如果获取到锁，那么根据是否是公平锁进行不同的处理

2.1) 公平锁，则当前线程会直接放置到AQS阻塞队列的末尾

2.2) 非公平锁，则当前线程会先进行CAS操作，如果成功则直接争抢到锁；如果失败则与公平锁的处理方式一致，当前线程被放置到阻塞队列的末尾

3）当调用了ReentrantLock的unlock方法时，底层会调用AQS的release方法对AQS的state成员变量进行减一操作，如果减一后state值不为0，那么release操作执行完毕；如果state值为0，则调用LockSupport的unpark方法(底层是操作系统的pthread_mutex_unlock)唤醒该线程对象后面的等待队列中的第一个后继线程，使其能够获得对象的锁。之所以减一后state值不为0，是因为ReentrantLock是可重入的，同一个线程可能多次调用过lock方法，每调一次，state值加一

在ReentrantLock中，上锁的本质就是对AQS中的state成员变量的操作：+1表示上锁，-1表示释放锁。

ReentrantReadWriteLock

读锁：

1）在获取读锁时，会先判断当前对象是否已经被加了写锁，如果已经拥有写锁，则直接失败

2）如果没有写锁，就表示当前对象没有排它锁，则当前线程会尝试给对象加锁

3）如果当前线程已经拥有了该对象的锁，那么直接将对象的读锁数量加一

写锁：

1）在获取写锁时，会先判断当前对象是否已经拥有了锁(读锁和写锁)。如果已经拥有了锁且持有锁的线程不是当前线程，则失败

2）如果当前对象没有被加锁，则为当前对象加上写锁，并且写锁的个数加一

3）将当前对象的排它锁线程持有者设置为自身

Tip：关于Java中各种锁的讲解与使用案例也可以参见：《Java中的锁》