java多线程Lock接口简介使用与synchronized对比 多线程下篇（三）

前面的介绍中，对于显式锁的概念进行了简单介绍

显式锁的概念，是基于JDK层面的实现，是接口，通过这个接口可以实现同步访问

而不同于synchronized关键字，他是Java的内置特性，是基于JVM的实现

Lock接口的核心概念很简单，只有如下几个方法

按照逻辑可以进行如下划分

lock（）

Lock接口，所以synchronized关键字更为灵活的一种同步方案，在实际使用中，自然是能够替代synchronized关键字的

（ps：尽管你不需要总是使用显式锁，显式锁与隐式锁各有利弊，但是在语法上是的确可以替代的）

synchronized关键字是阻塞式的获取锁

lock方法就是这一逻辑的体现，也就是说对于lock（）方法，如果获取不到锁，那么将会进入阻塞状态，与synchronized关键字一样

lockInterruptibly（）

Lock（）方法是一种阻塞式的，另外Lock接口还提供了可中断的lock获取方法，先看下测试例子

package test2;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
public class T28 {
private static final Lock LOCK = new ReentrantLock();
public static void main(String[] args) {
//线程A获取加锁之后，持有五秒钟
Thread threadA = new Thread(() -> {
LOCK.lock();
try {
System.out.println(Thread.currentThread().getName() + " " + System.currentTimeMillis());
System.out.println(Thread.currentThread().getName() + " sleep");
TimeUnit.SECONDS.sleep(10);
System.out.println(Thread.currentThread().getName() + " " + System.currentTimeMillis());
} catch (InterruptedException e) {
System.out.println(Thread.currentThread().getName() + " interrupt");
} finally {
LOCK.unlock();
}
}, "thread-A");
threadA.start();
//线程B开始后，尝试获取锁
Thread threadB = new Thread(() -> {
LOCK.lock();
try {
System.out.println(Thread.currentThread().getName() + " " + System.currentTimeMillis());
System.out.println(Thread.currentThread().getName() + " working");
} finally {
LOCK.unlock();
}
}, "thread-B");
threadB.start();
//为了确保上面的任务都开始了，主线程sleep 1s
try {
TimeUnit.SECONDS.sleep(1);
} catch (InterruptedException e) {
}
threadB.interrupt();
}
}

示例逻辑

两个线程A和B，使用同一把锁

A线程获取锁后，休眠10s，紧接着B尝试获取锁

为了保证前面的任务都开始了，主线程sleep 1s后，将线程B进行中断

对于lock方法，如同synchronized关键字，是阻塞式的，通过执行来看，可以发现，在A持有锁期间，线程B也是一直阻塞的，是不能够获取到锁，也不能被中断（上面示例中调用interrupt()没有任何的反应）

将代码稍作修改，也就是将lock方法修改为lockInterruptibly（）方法，其他暂时不变

再次运行，你会发现马上就被中断了，而不是傻傻的等待A结束

当然，因为根本都没有获取到锁，所以在finally中尝试unlock时，将会抛出异常，这个暂时不管了，通过这个例子可以看得出来

对于lockInterruptibly方法，这是一个“可中断的锁获取操作”

小结

lockInterruptibly就是一个可中断的锁获取操作，在尝试获取锁的过程中，如果不能够获取到，如果被中断，那么它将能够感知到这个中断，而不是一直阻塞下去

如果锁不可用（被其他线程持有），除非发生以下事件，否则将会等待

• 该线程成功获得锁
• 发生中断

如果当前线程遇到下面的事件，则将抛出 InterruptedException，并清除当前线程的已中断状态。

• 在进入此方法时已经设置了该线程的中断状态
• 在获取锁时被中断

从上面的分析可以看得出来，如果什么都没发生，这个方法与lock方法并没有什么区别，就是在等待获取锁，获取不到将会阻塞

他只是额外的对可中断提供了支持  

unlock（）

unlock并没有什么特殊的，他替代了synchronized关键字隐式的解锁操作

通常需要在finally中确保unlock操作会被执行，之前提到过，对于synchronized关键字解锁是隐式的，也是必然的，即使出现错误，JVM也会保障能够正确的解锁

但是对于Lock接口提供的unlock操作，则必须自己确保能够正确的解锁  

tryLock（）

相对于synchronized，Lock接口另一大改进就是try lock

顾名思义，尝试获取锁，既然是尝试，那显然并不会势在必得

tryLock方法就是一次尝试，如果锁可用，则获取锁，并立即返回值 true。如果锁不可用，则此方法将立即返回值 false

也就是说方法会立即返回，如果获取到锁返回true，否则返回false，不管如何都是立马返回

典型的用法就是如下所示，下面的代码还能够确保如果没有获取锁，不会试图进行unlock操作

Lock lock = ...;
if (lock.tryLock()) {
try {
// manipulate protected state
} finally {
lock.unlock();
}
} else {
// perform alternative actions
}

tryLock只是一次尝试，如果你需要不断地进行尝试，那么可以使用while替代if的条件判断

尽管tryLock只是一次的测试，但是可以借助于循环（有限或者无限）进行多次测试

tryLock(long time, TimeUnit unit)

对于TryLock还有可中断、配置超时时间的版本

boolean tryLock(long time,

                TimeUnit unit)

                throws InterruptedException

两个参数，第一个为值，第二个为第一个参数的单位，比如1，单位秒，或者2 ，单位分钟

在指定的超时时间内，如果能够获取到锁，那么将会返回true；

如果超过了指定的时间，但是却不能获取到锁，那么将会返回false；

另外很显然，这个方法是可中断的，也就是说如果尝试过程中，出现了中断，那么他将会抛出InterruptedException

所以，对于这个方法，他会一直尝试获取锁（也可以认为是一定时长内的“阻塞”，当然可以被中断），除非：

• 该线程成功获得锁
• 超过了超时时长
• 该线程被中断

可以认为是lockInterruptibly的限时版本

如果没有发生中断，也认为他就是“定时版本的lock（）”

不管怎么理解，只需要记住：他会在一定时长内尝试进行锁的获取，也支持中断

锁小结

对于lock方法和unlock方法，就是类似于synchronized关键字的加锁和解锁，并没有什么特别的

其他几个方法是Lock接口针对于锁获取的阻塞以及可中断两个方面进行了拓展

隐式锁的阻塞以及不可中断，导致一旦开始尝试获取，那么则没办法唤醒，将会一直等待，除非获得

• lockInterruptibly（）是阻塞式的，如果获取不到会一直等待，但是他是可中断的，能够通过阻塞打破这种等待
• tryLock（）不会进行任何阻塞，只是尝试获取一下，能获取到就获取，获取不到就false，拉倒
• tryLock(long time, TimeUnit unit)，即是可中断的，又是限时阻塞的，即使不中断，也不会一直阻塞，即使处于阻塞中（超时时长还没到），也可以随时中断

对于lockInterruptibly（）方法以及tryLock(long time, TimeUnit unit)，都支持中断，但是需要注意：

在某些实现中可能无法中断锁获取，即使可能，该操作的开销也很大  

Condition

在隐式锁的逻辑中，借助于Java底层机制，每个对象都有一个相关联的锁与监视器

对于synchronized的隐式锁逻辑就是借助于锁与监视器，从而进行线程的同步与通信协作

在显式锁中，Lock接口提供了synchronized的语意，对于监视器的概念，则借助于Condition，但是很显然，Condition也是与锁关联的

Lock接口提供了方法Condition newCondition();

Condition也是一个接口，他定义了相关的监视器方法

在显式锁中，可以定义多个Condition，也就是一个锁，可以对应多个监视器，可以更加细粒度的进行同步协作的处理

总结

Lock接口提供了相对于synchronized关键字，而更为灵活的一种同步手段

它的核心与本质仍旧是为了线程的同步与协作通信

所以它的核心仍旧是锁与监视器，也就是Lock接口与Condition接口

但是灵活是有代价的，所以并不需要在所有的地方都尝试使用显式锁，如果场景满足需要，synchronized仍旧是一种很好的解决方案（也是应该被优先考虑的一种方式）

与synchronized再次对比下

• synchronized是JVM底层实现的，Lock是JDK接口层面的
• synchronized是隐式的，Lock是显式的，需要手动加锁与解锁
• synchronized乌无论如何都会释放，即使出现错误，Lock需要自己保障正确释放
• synchronized是阻塞式的获取锁，Lock可以阻塞获取，可中断，还可以尝试获取，还可以设置超时等待获取
• synchronized无法判断锁的状态，Lock可以进行判断
• synchronized可重入，不可中断，非公平，Lock可重入，可中断、可配置公平性（公平和非公平都可以）
• 如果竞争不激烈，两者的性能是差不多的，可是synchronized的性能还在不断的优化，当竞争资源非常激烈时（即有大量线程同时竞争），此时Lock的性能要远远优于synchronized   
• 等   

对于Lock接口，他仍旧是一个对象，所以他是否可以用来作为锁以及调用监视器方法（用在synchronized（lock）中）？

这逻辑上是没问题的，但是最好不要那么做，因为很容易引起混淆的，不管是维护上还是易读性上都有很大的问题

在lock上调用他的监视器方法，与借助于lock实现线程的同步，本质上是没有什么关系的

尽管看起来Lock是那么的优秀，但是还是要再次提醒，除非synchronized真的不行，否则你应该使用synchronized而不是Lock