当前位置:首页 » 《随便一记》 » 正文

《重学Java高并发》你管这“破玩意儿”叫锁(没有高并发经验的朋友们看过来,该专栏结合笔者的实战来讲高并发)_prestigeding的博客

26 人参与  2021年11月10日 11:03  分类 : 《随便一记》  评论

点击全文阅读


专栏特色:结合10余年的工作经验,在实践中提炼总结高并发经验,将理论落到实处,不仅助力面试,更是真正提高技能。
专栏目录:

  1. 《重学Java高并发》Sempahore的使用场景与常见误区
  2. 《重学Java高并发》手写一个生产者消费者线程模型

正确理解锁是深入理解Java并发的重中之重。

接下来和笔者一步一步进入"Java的锁世界"中来吧,本文将循序渐进的介绍锁的相关知识,从简单到难,从概念到实践思路。

1、锁的种类

首先以一个非常常见的生活场景举例,例如一个三口之家居住在一个二房一厅的房子里,只有一个卫生间,早上一起床,大家是不是都有抢卫生间,这里就会发生一个有意思的事情了,一人在如厕,其他人排队等待的场景。

在这里插入图片描述
这个场景下有如下几个关键的特征:

  • 独占
    “厕所“作为一个资源,在任意时刻只能被一个人占用,为了实现该效果,使用资源之前,需要先获得与该资源关联的锁
  • 当多个线程都需要访问该资源时,必须先获得锁,而且在同一时刻有且只会有一个线程获得锁,那没有获得锁的线程就需要排队等待。是一直等,还是等得不耐烦时就放弃?
  • 当有多人排队时,一个线程将锁释放后,交给谁?什么样的策略?

上面是最常见的锁应用场景,有一个非常响亮的名称:互斥锁、排它锁

1.1 互斥锁

在java领域中,实现互斥锁通常有两种方式:

  • synchronized
  • ReentrantLock

接下来对比两者的不同点,从而来了解互斥锁的基本语义

  • 可重入性
    所谓的可重入性一个线程获取锁后,没有释放之前,继续申请,其伪代码如下所示:
    在这里插入图片描述
    synchronized与ReentrantLock都支持可重入性。

  • 锁只能被锁的拥有者释放
    大家如何基于redis实现分布式锁时,要特别注意这个特质。

  • 申请锁时是否支持超时取消
    申请锁的时候,ReentrantLock能支持设定超时时间,即调用申请锁时如果在指定时间内未获取锁,支持自动停止阻塞跳出,而synchronized不支持

  • 申请锁时是否支持被中断
    ReentrantLock可以通过调用lockInterruptibly方法,可以支持线程中断,即停止继续申请锁,同样synchronized不支持

  • 是否支持公平锁/非公平锁
    所谓的公平锁,是指当拥有锁的线程释放锁后,锁的下一个获取者就是锁等待队列中的第一个元素,而非公平锁并没有这个限制,ReentrantLock支持,而synchronized不支持。

1.2 共享锁

与互斥锁相对应的是共享锁,所谓的共享锁是同一时间可以被多个线程共同申请,一个非常经典的使用场景就是读写锁。

例如在一个缓存场景,在一个商品系统中,为了提供对商品的访问性能,通常会引入一个缓存区(Map)来缓存商品的数据,缓存数据对查询请求(读请求)是可以并行执行的,即多个线程同时查询缓存区的数据,这个是一个非常安全的操作,但不允许多个线程对缓存区进行修改。这里共享锁的意义就发挥出来了。

既然多个线程对缓存区可以同时进行读操作,那为什么还要加共享锁呢?主要的目的是避免写操作与读操作同时进行

只要当前有读操作在进行,写操作就需要排队,请看如下示例图:

在这里插入图片描述
如上图所示:例如 线程T1,T2,T3连续申请共享锁,然后T4申请写锁,再T5申请读锁,那各个线程的并发执行情况如下所示:

  • 线程 T1、T2、T3 将并发执行
  • T4由于是申请的写锁,必须等 T1、T2、T3释放锁后,才能执行。
  • T5虽然申请是共享锁,但由于T4持有写锁,故T5也需要阻塞,直至T4释放锁。

在Java等世界中按锁的排斥性来分基本就包含排它锁与共享锁,其他读写锁、间隙锁等是以锁的粒度这个纬度进行细分。

2、锁的实现原理

在了解了锁的基本语意义之后,我们有必要来阐述一下锁的实现原理。

从某种意义上来说,锁的实现原理就是两个队列:同步阻塞队列、条件等待队列

2.1 阻塞队列

阻塞队列的作用说明如下图所示:
在这里插入图片描述
上面使用来synchronized,其传入的是一个锁对象,如果此时有5个线程同时去执行这段代码,由于锁的互斥性,同一时间只有一个线程能获得锁,其他线程需要排队等待,故需要引入一个队列来存储在这些排队的线程,所以synchronized的实现机制中,会在锁对象中开辟一个队列,用来存储等待获取当前锁的线程

2.2 条件等待队列

Object对象中有一对特殊的方法:wait()/notify()/notifyAll(),大家在前文中应该看到消费者/生产者中示例中,使用过wait,notify方法,示例代码如下:
在这里插入图片描述
wait方法必须在synchronized中调用,并且通常是线程调用锁对象的wait方法,表示当前继续往下执行的条件不足,当前线程需要等待,故需要为锁对象再维护一个个队列,用来存储等待的线程,俗称条件等待队列

当其他线程调用锁对象的notify方法或notifyAll方法,会唤醒等待队列中的线程。

温馨提示:上述还有几个关键点:

  • Object.wait方法,会使当前线程进入等待状态,并且释放锁
  • 通常条件等待会使用while语句,避免条件不满足时被误唤醒,故使用while对条件进行再一次的判断。
  • 当被唤醒后,并不立即去执行while条件判断,而是需要重新去申请锁,即可能会进入到阻塞队列

3、锁的优化思路

我相信作为一个程序员,大家都对锁很敏感,因为性能低下,但锁肯定有其存在的原因,主要解决数据访问的安全性,大家可能会感到惊讶,作为一款高性能的消息中间件(RocketMQ),在消息写入时也使用了锁,其代码如下:
在这里插入图片描述
这是因为RocketMQ是顺序写文件,多个请求同时申请写一个文件,必须排队执行,否则会带来逻辑异常,此时锁是不用不行了。

对锁的优化策略,通常基于如下原则:能不用锁就不使用锁,必须使用锁则尽量保证被锁包裹代码的快速执行、降低锁的粒度。

3.1 优化锁执行时间

当然能不用锁就不用锁,但有些场景是必须使用锁来保证多线程环境下结果的正确性,就以RocketMQ顺序写commitlog文件为例,对同一个文件写入,需要记录当前的写入位置,然后另外一个线程就进行追加,故这个为写入位置是多线程不安全的,故必须引入锁,那RocketMQ作为一款高性能的消息中间件,是如何做到消息发送的高并发,低延迟能力低呢?

核心法宝:控制锁的范围,确保被锁包含的代码执行性能高效,接下来我们看一下RocketMQ消息写入的几个重要步骤:
在这里插入图片描述
并不是需要将上述三个步骤都加锁,而是只对写内存这段加锁即可,这段代码非常高效。

3.2 优化锁的粒度

锁的性能优化是一个永恒的主旨,另外一个核心思路是:降低锁的粒度,提高并发度

接下来我们以JDK中的HashTable与ConcurrentHashMap的实现原理为例,让大家体会一下如何降低锁的粒度从而提高并发度

Hashtable的性能低下是众所周知,因为整个容器就一把锁,因为它的get、put都是被synchronized修饰,synchronized用来修饰非static方法,其锁对象为Hashtable是对象锁。

并发度:同一时间只有一个线程能向该容器添加数据、获取数据。

而jkd1.7及其版本,ConcurrentHashMap的内部数据结构如下图所示:
在这里插入图片描述
可以看出ConcurrentHashMap的设计思路是将整个HashMap分割成多个小的HashMap,然后为每一个HashMap加锁,从而降低锁的粒度,从而提高并发度

在JDK1.8及版本后,ConcurrentHashMap的存储结构又发了很大改变,摒弃分段思想,使用来数组 + Node ,进一步释放读写的并发度,其数据结构如下图所示:

在这里插入图片描述
其中,对每一个链表的Node节点,写操作时会加锁,但在查询时候,并不会对各个Node加锁,提高读操作的并发度;并且会基于CAS机制实现无锁化处理,使用volatile保证可见性。

本文并不准备去剖析ConcurrentHashMap的实现细节,后续专门从源码实现的角度深度剖析,敬请期待,也请持续关注我。

3.3 无锁化设计

锁的存在必然有其使用场景,特别是需要被锁保护的资源众多,即临界区中的逻辑复杂,对其进行拆分会使代码变的臃肿,直接使用锁保护会清晰明了,但评估是否需要引入锁时需要慎重,特别是一些对吞吐量有极高要求的场景,能不用锁就不要用锁.

无锁化设计的基础:CAS,比较和交换。

在Java领域也提供了对应的原子操作工具:CAS,CAS 操作包含三个操作数 —— 内存位置(V)、预期原值(A)和新值(B)。 如果内存位置的值与预期原值相匹配,那么处理器会自动将该位置值更新为新值 。否则,处理器不做任何操作。CAS是CPU指令级命令

CAS简单使用示例如下:
在这里插入图片描述
正如笔者在优化信号量释放逻辑时引入了cas确保一个SempahoreReleaseOnlyOne只会释放一次信号量。

在JUC框架中的ArrayBlockingQueue,LinkedBlockingQueue等队列都支持多个线程同时往队列中写入数据,但其内部都引入了锁。

多个线程往队列中写入数据,一定要加锁?怎么进行无锁化设计呢?

Disruptor框架,实现多线程环境中真正的无锁化设计,极大的提升并发性能。提供了多个线程可以同时并发安全的往同一队列写入数据,而不加锁,是不是很神奇?

由于篇幅的原因,本文并不会为大家揭晓Disruptor是如何实现多个线程在不引入锁的情况下对队列进行并发操作的,兴趣是最好的老师,如果大家有兴趣可以先提前研究,后续将在《重学Java高并发》系列中后续文章中专门详细剖析。


一键三连(关注、点赞、留言)是对我最大的鼓励。

各位技术朋友们,我是《RocketMQ技术内幕》一书作者,CSDN2020博客之星TOP2,热衷于中间件领域的技术分享,维护「中间件兴趣圈」公众号,旨在成体系剖析Java主流中间件,构建完备的分布式架构体系,欢迎大家大家关注我,第一时间获得最新干货文章。
在这里插入图片描述


点击全文阅读


本文链接:http://zhangshiyu.com/post/30726.html

线程  队列  并发  
<< 上一篇 下一篇 >>

  • 评论(0)
  • 赞助本站

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。

关于我们 | 我要投稿 | 免责申明

Copyright © 2020-2022 ZhangShiYu.com Rights Reserved.豫ICP备2022013469号-1