【Java多线程进阶】常见的锁策略

前言

众所周知,拳击运动员是要分等级(轻量级、重量级等等)来参加比赛的,在 Java 多线程中 锁(synchronized) 也会根据锁的竞争程度来升级为相关“高等级”锁,为了更好的理解 synchronized 加锁机制,我把锁的相关策略整理出来了,一起来看看吧。

目录

1. 悲观锁与乐观锁

2. 读写锁与互斥锁

3. 重量级锁与轻量级锁

4. 自旋锁与挂起等待锁

4.1 自旋锁

4.2 挂起等待锁

5. 公平锁与非公平锁

6. 可重入锁与不可重入锁

1. 悲观锁与乐观锁

悲观锁:为了保证原子性,因此把数据进行上锁,每一个不同的线程拿数据的时候都会参与锁的竞争,其他线程想必须等待前者拿完数据解锁后才能参与拿数据。

举例,由于维修导致一层楼只剩下一间厕所。因此,线程1进入厕所后,其他线程只能阻塞等待。


乐观锁:假设数据一般情况下不会产生并发冲突,所以在数据进行提交更新的时候,才会正式对数据是否产生并发冲突进行检测,如果发现并发冲突了,则让返回用户错误的信息,让用户决定如何去做。

还是上述上厕所例子,线程1 给其他线返回一个信息,其他线程可根据信息选择换楼层上厕所亦或是等待。

以上的上厕所例子,在楼栋厕所不充足情况下。线程还是盲目选择这栋楼的厕所(使用悲观锁)就会导致阻塞消耗系统资源。在楼栋厕所充足的情况下,线程选择了这栋楼的厕所(使用乐观锁)这样就能很好的利用系统资源。

synchronized 初始情况下使用的是乐观锁,当发现锁竞争激烈时候就会自动转换为悲观锁。就好比一个线程去某一栋楼上厕所,并不知道该楼栋是否厕所充足。充足就不阻塞等待,不充足就阻塞等待。


2. 读写锁与互斥锁

多线程中,线程作为读取方不会产生线程安全问题,当线程作为为写入方和线程作为写入方之间进行交互和,线程作为写入方和线程作为读取方之间进行交互,就会造成互斥。

线程对数据的访问,主要存在三种情况:

  • 线程只是对数据进行读操作,此时自然不会出现线程不安全问题。
  • 多个线程对数据进行写操作,就会出现线程不安全问题。
  • 一个线程对数据进行读操作,另个线程对数据进行写操作,也会出现线程不安全问题。

简单的来说,线程的读操作,就是线程对数据进行访问。线程的写操作,就是线程对数据进行修改。读一下问题不大,但写一下就难免会造成意外。因此,我们有了 读写锁 这个概念。


读写锁,就是把读和写这两个操作分开来加锁这样就能避免互斥。Java 标准库提供了一个 ReentrantReadWriteLock 类,实现了读写锁。

ReentrantReadWriteLock.ReadLock 类表示一个读锁.。这个对象提供了 lock / unlock 方法进行加锁解锁。

ReentrantReadWriteLock.WriteLock 类表示一个写锁.。这个对象也提供了 lock / unlock 方法进行加锁解锁。

  • 读加锁与读加锁之间,不互斥
  • 写加锁与写加锁之间,互斥
  • 读加锁与写加锁之间,互斥

互斥,就会操作线程的挂起等待,一旦线程挂起等待了,就不知道什么时候能够被唤醒了。因此,我们在编写代码的时候尽可能减少互斥。

读写锁特别适用于“频繁读,不频繁写”的场景中。比如,学校的教务系统:

假设计算机软件专业的学生有 300 个同学,这300个同学几乎每天都要课程表为了防止课表更改,这样的一个操作就是频繁读(访问)。

有特殊情况,老师生病了或是怎样,偶尔会调课到其他时间点。这样的操作,就是不频繁写(修改)。

注意synchronized 不是读写锁


3. 重量级锁与轻量级锁

在并发编程中,轻量级锁和重量级锁是两种锁的实现方法,主要用于解决多个线程同时访问共享资源时的同步问题。

轻量级锁通常用于锁竞争不激烈的情况下,通过在线程内部使用CAS操作来进行加锁和解锁,这种方式不需要进行线程的上下文切换,因此性能比重量级锁更高。但是,如果锁竞争激烈的话,轻量级锁的性能优势就不明显了。

重量级锁通常用于锁竞争激烈的情况下,通过将竞争锁的线程挂起并切换到内核态来进行加锁和解锁。由于需要进行线程的上下文切换,因此性能比轻量级锁更低。但是,在锁竞争激烈的情况下,重量级锁的效果要比轻量级锁好得多,因为它可以有效地避免锁争用问题,减少了线程的抢占和切换,从而提高了系统的效率和响应速度。

synchronized 的轻量级锁策略大概都是通过自旋锁的方式实现的,重量级锁则是挂起等待锁。


4. 自旋锁与挂起等待锁

自旋锁 VS 挂起等待锁:

自旋锁,当线程之间进行抢占锁内资源时候,线程1 已经抢占到锁,线程2 则会持续等待 线程1 锁内任务结束后再进行抢占锁资源,在这期间 线程2 持续处于阻塞等待状态。

挂起等待锁,当挂起等待锁遇到这种情况时,发现有线程已经抢占到锁了,则会放弃阻塞等待。直到锁开放了,则再参与抢占锁。

因此,自旋锁有以下优缺点:

  • 优点:时刻占用系统资源,不涉及线程阻塞和调度,一旦锁被释放了,参与锁的竞争。
  • 缺点:当锁内任务比较复杂时,锁被其他线程占有时间过长,那么就会持续消耗系统资源。
  • 挂起等待锁则相反

4.1 自旋锁

自旋锁,按照正常的逻辑,当线程抢占锁时进入阻塞状态,过不了多久锁就被释放了。因此,自旋锁就没必要放弃 CPU 了,一直占用着 CPU 的内存空间。

自旋锁伪代码:

while(枪锁lock == 失败) {}

如果获取锁失败,立即再尝试获取锁,无限循环下去直到获取到锁为止。第一次获取锁失败,往后的获取锁操作会在极短的时间内到来,一旦锁被其他线程释放,就能第一时间获取到锁。这就是轻量级锁的体现(锁的竞争还不太激烈,尝试使用自旋方式加锁)。


4.2 挂起等待锁

当线程获取锁失败后,并不会进行阻塞等待。而随着系统的调度,不占用 CPU 。直到锁开发后,再尝试参与锁竞争。这种情况就是挂起等待锁,也是重量级锁的体现(锁的竞争太激烈了,线程跟随系统的调度)。

举例:

自旋锁与挂起等待锁的现实生活体现:张三是一个普通的男生,如花是一个漂亮的女孩,在此张三作为线程,如花作为锁。

张三开始追求如花,但是如花已经有男朋友了。张三又是个死皮赖脸的人。每天坚持给女孩发信息,期待着某一天如花分手,能得到如花。此时张三就处于自旋锁的状态。

随着竞争的激烈,又有许多人想要追求如花。张三开始动摇了,开始努力敲代码、认真学习不参与追如花的竞争了(随着系统的调度做其他事去了)。如果某一天如花变为单身了,系统会通知张三如花单身了(锁空闲了),张三就又开始参与竞争锁。此时张三的状态就是挂起等待锁状态。


5. 公平锁与非公平锁

公平锁与非公平锁讲究四个字“公平竞争”,假设有三个线程抢占锁资源,当锁被释放后就会出现两种情况:公平竞争锁、非公平竞争锁。

公平锁:遵循先来后到的原则,线程1 进入锁,锁释放后。线程2 进入锁,锁再释放后。线程3 进入锁。整个过程是按照顺序执行的。

非公平锁:由于线程之间抢占资源,导致锁被无序的抢占。这样 3 个线程都有机会优先进入锁。整个过程会造成无序执行。

通过上图我们就能很好的理解,公平锁与非公平锁之间的差异。当然,线程的调度是随机的因此多个线程竞争锁时可以随意进行抢占“手快有,手慢无”(非公平锁)。要想实现公平锁,我们可以使用一些特定的数据结构来达到按顺序使用锁。

在实际开发中,公平锁与非公平锁没有好坏之分,我们按照需求来进行设置。注意,synchronized 属于非公平锁。


6. 可重入锁与不可重入锁

可重入锁即允许一个线程多次获取同一把锁。

不可重入锁是指一旦线程获得了该锁,此时再次请求获取该锁时,系统会将该线程挂起,直到该锁被释放为止。因此,不可重入锁不能再同一线程中重复获取。

可重入锁是指当一个线程获得了该锁之后,在该锁还未释放之前,可以再次获取该锁。这种锁可以防止死锁的发生,因为在获取之后可以在方法中重新获取该锁,从而避免死锁的发生。

Java 中的 synchronized 关键字是一种可重入锁,而 ReentrantLock 是 Java 中常用的可重入锁类,synchronized 不需要手动解锁,而 ReentrantLock 需要手动解锁。

需要注意的是,可重入锁虽然提高了代码的灵活性和可维护性,但同时也可能会带来出现深度嵌套锁的风险,引发死锁或性能下降等问题。因此,在使用可重入锁时需要仔细设计和管理。


谈谈你对synchronized的演变过程的理解?

synchronized 既是悲观锁也是乐观锁,synchronized 即是轻量级锁也是重量级锁,synchronized 即是自旋锁也是挂起等待锁,synchronized 不是读写锁,synchronized 是非公平锁,synchronized是可重入锁。

synchronized 的初始化的时候是一个乐观锁/轻量级锁/自旋锁,随着synchronized的竞争激烈会升级为悲观锁/重量级锁/挂起等待锁,另外轻量级锁是部分基于自旋锁、重量级锁是部分基于挂起等待锁。


在锁的策略中还会引申到“死锁”的概念,在下篇博文中,我会介绍。大家也可以通过下方专栏中搜索多线程相关内容。

🧑‍💻作者:一只爱打拳的程序猿,Java领域新星创作者,阿里云社区优质创作者、专家博主。

📒博客主页:这是博主的主页 

🗃️文章收录于:Java多线程编程 

🗂️JavaSE的学习:JavaSE 

🗂️Java数据结构:数据结构与算法 

 本篇博文到这里就结束了,感谢点赞,评论,收藏,关注~

  • 14
    点赞
  • 15
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 7
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 7
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

一只爱打拳的程序猿

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值