请选择 进入手机版 | 继续访问电脑版

[多线程] java多线程Lock接口简介使用与synchronized对比 下篇(三)

编程语言 编程语言 4958 人阅读 | 0 人回复

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

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

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

image.png

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

image.png

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

image.png

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.png

将代码稍作修改,也就是将lock方法修改为lockInterruptibly()方法,其他暂时不变

image.png

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

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

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

image.png

小结

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.png

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

common_log.png 转载务必注明出处:程序员潇然,疯狂的字节X,https://crazybytex.com/thread-82-1-1.html

关注下面的标签,发现更多相似文章

文章被以下专栏收录:

    黄小斜学Java

    疯狂的字节X

  • 目前专注于分享Java领域干货,公众号同步更新。原创以及收集整理,把最好的留下。
    包括但不限于JVM、计算机科学、算法、数据库、分布式、Spring全家桶、微服务、高并发、Docker容器、ELK、大数据等相关知识,一起进步,一起成长。
热门推荐
海康摄像头接入 wvp-GB28181-pro平台测试验
[md]### 简介 开箱即用的28181协议视频平台 `https://github.c
[若依]微服务springcloud版新建增添加一个
[md]若依框架是一个比较出名的后台管理系统,有多个不同版本。
[CXX1300] CMake '3.18.1' was not
[md][CXX1300] CMake '3.18.1' was not found in SDK, PATH, or