noteless 头像
noteless

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

前面的介绍中，对于显式锁的概念进行了简单介绍
显式锁的概念，是基于JDK层面的实现，是接口，通过这个接口可以实现同步访问
而不同于synchronized关键字，他是Java的内置特性，是基于JVM的实现
image_5c7f20d6_7841
Lock接口的核心概念很简单，只有如下几个方法
image_5c7f20d6_1834
按照逻辑可以进行如下划分
image_5c7f20d6_415

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()没有任何的反应）
image_5c7f20d6_4536
将代码稍作修改，也就是将lock方法修改为lockInterruptibly（）方法，其他暂时不变
image_5c7f20d6_7bb5
再次运行，你会发现马上就被中断了，而不是傻傻的等待A结束
当然，因为根本都没有获取到锁，所以在finally中尝试unlock时，将会抛出异常，这个暂时不管了，通过这个例子可以看得出来
对于lockInterruptibly方法，这是一个“可中断的锁获取操作”
image_5c7f20d6_1200
小结
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实现线程的同步，本质上是没有什么关系的
image_5c7f20d6_6b7b
尽管看起来Lock是那么的优秀，但是还是要再次提醒，除非synchronized真的不行，否则你应该使用synchronized而不是Lock
 
posted @ 2019-03-07 16:56  noteless  阅读(19057)  评论(0)  编辑  收藏  举报