基础知识

想要学习并发,必须首先对线程有一定的知识基础,因此强烈建议先复习一下这部分知识:


在Java基础笔记中,对于Java线程有一定的说明:

https://uesugier11.gitee.io/uesugi-er11/2020/11/14/Java%E5%9F%BA%E7%A1%80/#%E7%BA%BF%E7%A8%8B

https://uesugier11.gitee.io/uesugi-er11/2020/11/14/Java%E5%9F%BA%E7%A1%80/#%E5%A4%9A%E7%BA%BF%E7%A8%8B


如果想在OS层面学习进程线程,在OS笔记中,对这部分有一定的说明:

https://uesugier11.gitee.io/uesugi-er11/2020/09/08/%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F/#%E8%BF%9B%E7%A8%8B%E5%92%8C%E7%BA%BF%E7%A8%8B

对于进程的调度,死锁的相关知识:

https://uesugier11.gitee.io/uesugi-er11/2020/09/08/%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F/#%E5%A4%84%E7%90%86%E6%9C%BA%E8%B0%83%E5%BA%A6%E4%B8%8E%E6%AD%BB%E9%94%81

Java并发 - 核心理论

  • Java异步核心原理分为五个基本性质:共享性、互斥性、原子性、可见性、有序性

共享性

如果所有数据都是线程私有的,那编程的时候就无须考虑并发的情况了 —— 因为无论怎么操作,数据都可以保证正确,不会被其他线程访问。因此,数据具有共享性,是线程安全得不到保证的主要原因之一。那如何保证线程安全(数据一致性)呢,就得引入进程同步。

互斥性

操作系统中,关于进程互斥:https://uesugier11.gitee.io/uesugi-er11/2020/09/08/%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F/#%E5%AE%9E%E7%8E%B0%E8%BF%9B%E7%A8%8B%E4%BA%92%E6%96%A5

资源互斥是指同时只允许一个访问者对其进行访问,具有唯一性排它性

对于数据,我们可以进行读(查看)和写(修改)的操作,则我们应该对执行读写操作的线程分别有不同的限制,因此衍生了两种

  • 共享锁(读锁/S锁):共享 (S) 用于不更改或不更新数据的操作(只读操作),如 SELECT 语句。

    如果事务T对数据A加上共享锁后,则其他事务只能对A再加共享锁,不能加排他锁。获准共享锁的事务只能读数据,不能修改数据。

  • 排它锁(写锁/X锁):用于数据修改操作,例如 INSERT、UPDATE 或 DELETE。确保不会同时同一资源进行多重更新。

    如果事务T对数据A加上排他锁后,则其他事务不能再对A加任任何类型的封锁。获准排他锁的事务既能读数据,又能修改数据。

Java中的保证数据安全性,实现互斥的方法有许多(比如synchronized,类似于操作系统中的管程机制)

原子性

操作系统中与原子性关系最贴切的应该是原语

https://uesugier11.gitee.io/uesugi-er11/2020/09/08/%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F/#%E5%8E%9F%E8%AF%AD

原子性就是指对数据的操作是一个独立的、不可分割的整体。换句话说,就是一次操作,是一个连续不可中断的过程,数据不会执行的一半的时候被其他线程所修改;

列举个例子来体现原子性i++ 这个操作,1)读取整数 i 的值;(2)对 i 进行加一操作;(3)将结果写回内存。

但却可能在多线程场景发生以下情况:

img

保证原子性(即不会被其他操作打断)的方法可以通过上锁去实现:Synchronized或Lock,或者是使用CAS:修改数据之前先比较与之前读取到的值是否一致,如果一致,则进行修改,如果不一致则重新执行(乐观锁)。但CAS在某些场景下不一定有效,比如另一线程先修改了某个值,然后再改回原来值,这种情况下,CAS是无法判断的。

可见性

关于可见性问题的解释:

https://blog.csdn.net/duyabc/article/details/110946997?utm_term=java%E4%BB%80%E4%B9%88%E6%98%AF%E5%8F%AF%E8%A7%81%E6%80%A7&utm_medium=distribute.pc_aggpage_search_result.none-task-blog-2~all~sobaiduweb~default-9-110946997&spm=3001.4430

  • 可见性:一个线程对共享变量的修改,更够及时的被其他线程看到

可见性概念建立在JVM的内存模型上:

img

在JVM内部,为了提高效率,同时运行的每个线程都会有它正在处理的数据的缓存副本,当我们使用synchronzied进行同步的时候,真正被同步的是在不同线程中表示被锁定对象的内存块(副本数据会保持和主内存的同步

简单的说就是在同步块或同步方法执行完后,对被锁定的对象做的任何修改要在释放锁之前写回到主内存中;在进入同步块得到锁之后,被锁定对象的数据是从主内存中读出来的,持有锁的线程的数据副本一定和主内存中的数据视图是同步的

但有可能会出现这么一个问题:假如主内存的更新(通知)不及时,会导致一个线程A明明更新了数据,但线程B得到的还是原来的数据的问题。

解决这个问题可以使用:volatilesynchronized关键字进行解决。

有序性

有序性部分与进程的前驱问题有点类似:

https://uesugier11.gitee.io/uesugi-er11/2020/09/08/%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F/#%E5%AE%9E%E7%8E%B0%E5%89%8D%E8%B6%8B%E5%85%B3%E7%B3%BB

为了提高性能,编译器和处理器可能会对指令做重排序,但是重排序过程不会影响到单线程程序的执行,却会影响到多线程并发执行的正确性。重排序相关内容

Java 中也可通过Synchronized或·Volatile来保证顺序性。

Java内存模型

img

前言

内存模型通过限制处理器优化和使用内存屏障,来保证共享内存的正确性(可见性、有序性、原子性)

Java内存模型(Java Memory Model ,JMM)就是一种符合内存模型规范的,屏蔽了各种硬件和操作系统的访问差异的,保证了Java程序在各种平台下对内存的访问都能保证效果一致的机制及规范。

JMM还通过volatilesynchronizedfinalconcurren包等实现原子性、有序性、可见性。

而由于进程之间进行通信,数据进行同步,都依靠这个JMM。因此学习它就显得尤为重要了。

关于进程通信:

https://uesugier11.gitee.io/uesugi-er11/2020/09/08/%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F/#%E8%BF%9B%E7%A8%8B%E9%80%9A%E4%BF%A1-1

关于进程同步:

https://uesugier11.gitee.io/uesugi-er11/2020/09/08/%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F/#%E8%BF%9B%E7%A8%8B%E5%90%8C%E6%AD%A5-1

并发编程模型基础

在并发编程中,需要了解并会处理这两个关键问题:

线程之间如何通信

 通信是指线程之间以何种机制来交换信息。在命令式编程中,线程之间的通信机制有两种:共享内存和消息传递

  a) 在共享内存的并发模型里,线程之间共享程序的公共状态,通过写-读内存中的公共状态进行隐式通信。(重点)

  b) 在消息传递的并发模型里,线程之间没有公共状态,线程之间必须通过发送消息来显式进行通信。

线程之间如何同步

  同步是指程序中用于控制不同线程间操作发生相对顺序的机制。

  在共享内存的并发模型里,同步是显示进行的。因为程序员必须显式指定某个方法或某段代码需要在线程之间互斥执行。

  在消息传递的并发模型里,由于消息的发送必须在消息的接收之前,因此同步是隐式进行的。

  知道并了解上面两个问题后,对java内存模型的了解,就打下了基础。因为Java的并发模型采用的是共享内存模型,java线程之间的通信总是隐式进行,整个通信过程对程序员完全透明。

硬件内存模型

img

  • 概述

如图:硬件内存模型由CPU - 缓存 - 主存储三层结构组成

现代计算机通常有2个或以上的CPU,单个CPU可能有多个内核。每个CPU内核中都包含一组寄存器,CPU在寄存器中执行操作比在计算机主存储器中快的多

每个CPU之上还存在高速缓存,但高速缓存的层级和位置是不固定的,缓存的位置也各有不同,有的集成了部分缓存到CPU中。 同样,缓存的读写速度也大大快于计算机主存储器。

  • 什么时候需要用到缓存呢?

CPU在程序的执行过程中,经常会频繁的调用相同的数据,比如在一个循环内调用了位于另外一个物理地址的函数,这个函数可能与当前指令的物理位置相距甚远,因为程序使用的物理内存并不是连续的,这就导致了需要花费很多不必要的时间在物理寻址上。但如果在CPU计算之前会将所需要用到的数据先读到缓存中,计算完成之后再一次性写入计算机主存储器,就可以避免频繁访问计算机主存储器造成的资源浪费。

JMM(Java Memory Model)

在Java中,所有实例域、静态域和数组元素都存储在堆内存中, 而堆内存在线程之间是共享的

而虚拟机栈(其中包括局部变量、方法参数定义等..)是线程私有的,不会在线程之间共享,所以它们不会有内存可见性的问题,也不受内存模型的影响。

img

  • 线程与主内存间的抽象关系

    • 线程之间的共享变量存储在主内存(Main memory)

    • 每个线程都有一个私有的本地内存(local memory)或者说是工作内存(Working Memory),本地内存中存储了该线程用以读/写共享变量的副本。

      线程对变量的所有操作(读取、赋值等)都必须在工作内存中进行,而不能直接读写主内存中的变量(volatile变量仍然有工作内存的拷贝,但是由于它特殊的操作顺序性规定,所以看起来如同直接在主内存中读写访问一般)。不同的线程之间也无法直接访问对方工作内存中的变量,线程之间值的传递都需要通过主内存来完成。

    • 本地内存是JMM的一个抽象概念,并不真实存在。它涵盖了缓存,写缓冲区,寄存器以及其他的硬件和编译器优化。线程对共享变量的操作并不会直接访问主内存,而是访问一个中间层,这个中间层包含了主内存中变量的拷贝,同时中间层的访问速度大大快于访问主内存的速度,在一定的操作之后将结果统一写回主内存,这样就大大提高了程序的性能

      (同时也会产生另外一个问题,同一个共享变量在每一个线程之中都会有一份拷贝(对引用类型,并不是拷贝全部数据),产生的线程越多,缓存开销也就越大。)

  • 线程通信问题

上图中,线程A与B想要进行通信(数据交互)的话,要经历:

  1. 线程A把本地内存A中更新过的共享变量刷新到主内存中去。
  2. 线程B到主内存中去读取线程A之前已更新过的共享变量,接着复制一份到本地内存B

img

假设初始时,这三个内存中x的值都为0,线程A在执行时,把更新后的x值临时放在本地内存。当线程A与线程B需要通信时,

  步骤1:线程A首先会把自己本地内存中修改后的x值刷新到主内存中,此时主内存中的x值变为了1。

  步骤2:线程B到主内存中读取线程A更新后的X值,此时线程B的本地内存x的值也变为了1。

  从整体(不考虑重排序,按顺序执行)来看,这两个步骤实质上是线程A在向线程B发送消息,而从整体(不考虑重排序,按顺序执行)来看,这两个步骤实质上是线程A在向线程B发送消息,而且这个通信过程必须要经过主内存。JMM通过控制主内存与每个线程的本地内存之间的交互,提供内存可见性的保证。

重排序

  • 重排序分为三种
  1. 编译器优化的重排序。编译器在不改变单线程程序语义的前提下,可以重新安排语句的执行顺序。
  2. 指令级并行的重排序。现代处理器采用了指令级并行技术(Instruction-Level Parallelism, ILP)来将多条指令重叠执行。如果不存在数据依赖性,处理器可以改变语句对应机器指令的执行顺序。
  3. 内存系统的重排序。由于处理器使用缓存和读/写缓冲区,这使得加载和存储操作看上去可能是在乱序执行。

img

  • 为什么会发生重排序

为什么会重排序,上面这几个阶段里大概提到了,提高并行效率,编译器认为重排序后执行更优,指令级重排序并行效率更好等等。在单个线程的视角看来,重排序不存在任何问题,重排序不改变执行结果

对于语句:int a = 1;int b = 2;int c = a + b;

首先需要明白:重排序的发生前提是具有数据依赖,什么意思呢?int a = 1;int b = a; b的数据依赖于a,那么这两个语句就不会被重排序,a一定会在b语句前执行;

c因为对a和b有数据依赖,因此c不会被重排序,但是a 、b的执行可能被重排序。但在单个线程下,这种重排序不存在任何问题,不论先初始化a、还是先初始化b,c的值都是3

  • 重排序带来的问题

然而重排序可能会导致多线程出现内存可见性的问题,比如:处理器在对内存进行读写操作未必与实际发生的内存读写顺序一致,导致重排序→引发了可见性问题(数据更新不及时)

在这我们不举例处理器的例子,我们还是以代码为例:

现在有两个线程

  1. 线程T1:

    1
    2
    a = 1; //共享变量
    int b = true; //共享变量 boolean b
  2. 线程T2:

    1
    2
    3
    4
    if (b){
    int c = a;
    System.out.println(c);
    }

我们默认b的值是线程T2可读取的,假如b为true,c一定为1吗?(在并发环境中)

按照我们上面的学习,a与b是没有数据依赖关系的,因此运行的顺序的可以被重排序的。假如此时b先与a执行,虽然对T1没什么影响,但是对T2就不一样了。T2可能一直在进行这个if的测试,突然间发现b为true了,而a还没来得及被赋值呢,就进入了T2的if语句中,则此时的c就读不到a的值(1)了。

当代码中存在控制依赖的时候,会影响指令序列执行的并行度。为此,编译器和处理器会采用猜测执行来克服控制相关性对并行度的影响。比如可以提前读取变量,计算,将计算结果临时保存起来,当条件为真的时候,把临时变量写入真的变量中。这个猜测执行其实就是对指令进行了重排序,此处的重排序是破坏了多线程程序的语义的。

happens-before - 重点

概述

img

  • JMM把happens- before要求禁止的重排序分为了下面两类:
  1. 会改变程序执行结果的重排序,JMM要求编译器和处理器必须禁止这种重排序。

  2. 不会改变程序执行结果的重排序,JMM对编译器和处理器不作要求(JMM允许这种重排序)。

    只要不改变程序的执行结果(指的是单线程程序和正确同步的多线程程序),编译器和处理器怎么优化都行。

    比如,如果编译器经过细致的分析后,认定一个锁只会被单个线程访问,那么这个锁可以被消除。

    再比如,如果编译器经过细致的分析后,认定一个volatile变量仅仅只会被单个线程访问,那么编译器可以把这个volatile变量当作一个普通变量来对待。

这些优化既不会改变程序的执行结果,又能提高程序的执行效率。

原则

  • happens-before原则定义
  1. 如果一个操作happens-before另一个操作,那么第一个操作的执行结果将对第二个操作可见,而且第一个操作的执行顺序排在第二个操作之前。 关于可见性
  2. 两个操作之间存在happens-before关系,并不意味着一定要按照happens-before原则制定的顺序来执行。如果重排序之后的执行结果与按照happens-before关系来执行的结果一致,那么这种重排序并不非法。

规则

  • happens-before规则
  1. 程序次序规则:一个线程内,按照代码顺序,书写在前面的操作先行发生于书写在后面的操作;

    一段代码在单线程中执行的结果是有序的。注意是执行结果,因为虚拟机、处理器会对指令进行重排序(重排序后面会详细介绍)。虽然重排序了,但是并不会影响程序的执行结果,所以程序最终执行的结果与顺序执行的结果是一致的。故而这个规则只对【单线程】有效,在【多线程】环境下无法保证正确性。

  2. 锁定规则:一个unLock操作先行发生于后面对同一个锁的Lock操作

    这个规则比较好理解,无论是在单线程环境还是多线程环境,一个锁处于被锁定状态,那么必须先执行unlock操作后面才能进行lock操作。

  3. volatile变量规则:对一个volatile变量的写操作先行发生于后面(时间上)对这个变量的读操作

    这是一条比较重要的规则,它标志着volatile保证了线程可见性。通俗点讲就是如果一个线程先去写一个volatile变量,然后一个线程去读这个变量,那么这个写操作一定是happens-before(先行)于读操作的。

  4. 传递规则:如果操作A先行发生于操作B,而操作B又先行发生于操作C,则可以得出操作A先行发生于操作C;

    提现了happens-before原则具有传递性,即A happens-before B , B happens-before C,那么A happens-before C

  5. 线程

    1. 启动规则:Thread对象的start()方法先行发生于此线程的每个一个动作;

      假定线程A在执行过程中,通过执行ThreadB.start()来启动线程B,那么线程A对共享变量的修改在接下来线程B开始执行后确保对线程B可见。

    2. 中断规则:对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生;

    3. 终结规则:线程中所有的操作都先行发生于线程的终止检测,我们可以通过Thread.join()方法结束、Thread.isAlive()的返回值手段检测到线程已经终止执行;

      假定线程A在执行的过程中,通过制定ThreadB.join()等待线程B终止,那么线程B在终止之前对共享变量的修改在线程A等待返回后可见。

  6. 对象终结规则:一个对象的初始化完成先行发生于他的finalize()方法的开始;

简单来说

程序顺序规则: 对于单个线程中的每个操作,前继操作happens-before于该线程中的任意后续操作。
监视器锁规则: 对一个锁的解锁,happens-before于随后对这个锁的加锁。
volatile变量规则: 对一个volatile域的写,happens-before于任意后续对这个volatile域的读。
传递性: 如果A happens-before B,且B happens-before C,那么A happens-before C。

  • 以上为原生Java满足Happens-before关系的规则,可引申推导出其他六条
  1. 将一个元素放入一个线程安全的队列的操作Happens-Before从队列中取出这个元素的操作
  2. 将一个元素放入一个线程安全容器的操作Happens-Before从容器中取出这个元素的操作
  3. 在CountDownLatch上的倒数操作Happens-Before 于CountDownLatch#await()操作
  4. 释放Semaphore许可的操作Happens-Before获得许可操作
  5. Future表示的任务的所有操作Happens-Before Future#get()操作
  6. 向Execut提交一个Runnable或Callable的操作Happens-Before任务开始执行操作

as-if-serial语义

as-if-serial语义的意思是:不管怎么重排序,单线程程序的执行结果不能被改变。编译器、runtime和处理器都必须遵守as-if-serial语义。所以编译器和处理器不会对存在数据依赖关系的操作做重排序,因为这种重排序会改变执行结果。但是,如果操作之间不存在数据依赖关系,这些操作就可能被编译器和处理器重排序。

下面还是以书中的实例(计算圆的面积)进行说明:

1
2
3
double pi  = 3.14;           // A
double r = 1.0; // B
double area = pi * r * r; // C![]

上面3个操作的数据依赖关系如图所示:

img

A和C之间存在数据依赖关系,同时B和C之间也存在数据依赖关系。因此在最终执行的指令序列中,C不能被重排序到A和B的前面(因为C排到A和B的前面,程序的结果将会被改变)。但A和B之间没有数据依赖关系,编译器和处理器可以重排序A和B之间的执行顺序。

该程序的两种可能执行顺序:

img

as-if-serial语义把单线程程序保护了起来,遵守as-if-serial语义的编译器、runtime和处理器共同为编写单线程程序的程序员创建了一个幻觉:单线程程序是按程序的顺序来执行的。
as-if-serial语义使单线程程序员无需担心重排序会 干扰他们,也无需担心内存可见性问题。

volatile

  • jvm运行时刻内存的分配

前言:一定要注意!Java内存区域(运行时数据区 )不等于Java内存模型(JMM)

Java内存区域是指JVM运行时数据分区域存储,而Java内存模型是定义了线程和主内存之间的抽象关系!


根据[JMM](#JMM(Java Memory Model)我们可以知道线程与主内存之间还存在着一个本地内存(工作内存),在这个内存中保存着变量的副本。

同样的,以类比的思想,jvm运行时刻内存的分配中,有一个内存区域是jvm虚拟机栈,每一个线程运行时都有一个线程栈

线程的工作内存与java的堆、栈并不是一个层次上的内存划分,如果非要类比的话工作内存对应虚拟机栈的部分区域 —— 《深入理解java虚拟机》

线程栈保存了线程运行时候变量值信息。当线程访问某一个对象时候值的时候,首先通过对象的引用找到对应在堆内存的变量的值,然后把堆内存中的变量的具体值load到线程本地内存中,建立一个变量副本,之后线程就不再和对象在堆内存变量值有任何关系,而是直接修改副本变量的值,在修改完之后的某一个时刻(线程退出之前),自动把线程变量副本的值回写到对象在堆中变量。这样在堆中的对象的值就产生变化了

img

  • 问题引入
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public class VolatileTest extends Thread {

boolean flag = false;
int i = 0;

public void run() {
while (!flag) {
i++;
}
}

public static void main(String[] args) throws Exception {
VolatileTest vt = new VolatileTest();
vt.start();
Thread.sleep(2000);
vt.flag = true;
System.out.println("stope" + vt.i);
}
}

上述代码运行流程:

  1. 首先创建 VolatileTest vt = new VolatileTest();
  2. 然后启动线程 vt.start();
  3. 暂停主线程2秒(Main) Thread.sleep(2000);
  4. 这时的vt线程已经开始执行,进行i++;
  5. 主线程暂停2秒结束以后将 vt.flag = true;
  6. 打印语句 System.out.println(“stope” + vt.i); 在此同时由于vt.flag被设置为true,所以vt线程在进行下一次while判断 while (!flag) 返回假 结束循环 vt线程方法结束退出!
  7. 主线程结束

然而输出结果是:stope1620137804,并且程序不会退出。也就是说我们在主线程设置的 vt.flag = true;没有起作用

  • 问题解决 理解

问题:主线程中设置flag = true,然而子线程并未获取到修改后的值,进行判断时的flag仍然为false。

需要结合jvm运行时刻内存的分配去理解

子线程执行过程

  1. 首先子线程(vt线程)运行时,将*变量 flag 与 i *主内存 拷贝到 线程栈内存(即线程工作内存)

  2. 接着执行while循环

    1
    2
    3
    while (!flag) {
    i++;
    }

    需要注意的是:while (!flag) 进行判断的flag 是在线程工作内存当中获取,而不是从 主内存 中获取。

    i++;线程工作内存中的i++; 加完以后将结果写回至 主内存,如此重复。

主线程执行过程

  1. 创建子线程

  2. 启动子线程

  3. 主线程sleep

  4. vt.flag = true;(重点)

    1. 主线程将vt.flag的值从主内存中拷贝到自己的线程工作内存
    2. 然后修改flag=true.
    3. 然后再将新值回到主内存

    这就解释了为什么在主线程(main)中设置了vt.flag = true; 而vt线程在进行判断flag的时候拿到的仍然是false。那就是因为vt线程每次判断flag标记的时候是从它自己的“工作内存中”取值,而并非从主内存中取值!

问题解决

我们在上面主线程的第四步发现了问题了,是由于子线程的取值并不是在主内存中进行,而是在自己的工作内存中获取的,因此,要想解决这个问题也很简单:让vt线程每次判断flag的时候都强制它去主内存中取值

这就是volatile关键字的作用:被加了这个关键字的数据,在被线程修改后,会从本地工作内存被强制的刷新回主内存,也就是让主内存中的变量值变成最新的值。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public class VolatileTest extends Thread {

volatile boolean flag = false;
int i = 0;

public void run() {
while (!flag) {
i++;
}
}

public static void main(String[] args) throws Exception {
VolatileTest vt = new VolatileTest();
vt.start();
Thread.sleep(2000);
vt.flag = true;
System.out.println("stope" + vt.i);
}
}

运行结果:

1
2
3
stope1662380642

Process finished with exit code 0

程序能够正常退出了。

  • bonus

例子:现在让线程1去修改data为1,然而线程2由于可见性问题,并不能读取到变更后的data(也就是线程2读取到的data一直是工作内存中的data(即为0)。因此就需要使用volatile去解决了。

640?wx_fmt=png

而volatile关键字除了能够让本地工作内存中的数据被强制的刷新回主内存外,还有着别的作用

  1. 如果此时别的线程的工作内存中有这个data变量的本地缓存,也就是一个变量副本的话,那么会强制让其他线程的工作内存中的data变量缓存直接失效过期,不允许再次读取和使用了

    640?wx_fmt=png

  2. 如果线程2在代码运行过程中再次需要读取data变量的值,此时尝试从本地工作内存中读取,就会发现这个data = 0已经过期了!

    此时,他就必须重新从主内存中加载data变量最新的值!那么不就可以读取到data = 1这个最新的值了!

    640?wx_fmt=png

  • 总结

volatile主要作用是保证可见性以及有序性。

但是内存模型三大要素缺漏了一个:原子性,也就是说,volatile关键字并不能保证原子性

结合线程理解就是:

  1. volatile主要解决的是一个线程修改变量值之后,其他线程立马可以读到最新的值,是解决这个问题的,也就是可见性!
  2. 多个线程同时修改一个变量的值,那还是可能出现多线程并发的安全问题,导致数据值修改错乱,volatile是不负责解决这个问题的,也就是不负责解决原子性问题

原子性的问题需要去结合锁机制去解决。

Java并发机制底层实现

  • 前言

在OS学习中,我们学习了线程同步的相关知识。

其中有一个临界区的概念

临界区是一个用以访问共享资源的代码块,这个代码块在同一时间内只允许一个线程执行。

在OS中,我们使用了信号量、管程等方法去实现同步。现在学习了Java,就需要用Java中类似的机制去实现。

Java提供了同步机制。当一个线程试图访问一个临界区时,它将使用一种同步机制来查看是不是已有其他线程进入临界区。如果没有其他线程进入临界区,它就可以进入临界区;如果已有线程进入了临界区,它就被同步机制挂起,直到进入的线程离开这个临界区。如果在等待进入临界区的线程不止一个,JVM会随机选择其中的一个,其余的将继续等待。

volatile的实现原理

在前面volatile 部分中,学习了volatile的基本概念,但是没有去学习其底层实现,下面就来看看volatile是如何保证可见性与有序性的

MESI缓存一致性协议

cache line

image-20210515164459977

如图所示,CPU中高速缓存内部结构是一个拉链散列表(与HashMap的底层结构以及原理十分相似)。它分为若干桶,每个桶是一个链表,包含若干缓存条目,每个缓存条目就是一个cache line(64 bytes)。

作用是什么呢?假设程序中读取某一个int变量,CPU并不是只从主存中读取4个字节,而是会一次性读取64个字节,然后放到cpu cache中。因为往往紧挨着的数据,更有可能在接下来会被使用到。

这里类似于IO的磁盘读取,应用到了时间和空间局部性原理

在CPU访问存储设备时,无论是存取数据抑或存取指令,都趋于聚集在一片连续的区域中,这就被称为局部性原理。
时间局部性(Temporal Locality):如果一个信息项正在被访问,那么在近期它很可能还会被再次访问。比如循环、递归、方法的反复调用等。
空间局部性(Spatial Locality):如果一个存储器的位置被引用,那么将来他附近的位置也会被引用。比如顺序执行的代码、连续创建的两个对象、数组等。

  • 进一步可分为三部分

在这里插入图片描述
CPU访问内存时,会通过内存地址解码的三个数据:index(桶编号)、tag(缓存条目的相对编号)、offset(变量在缓存条目中的位置偏移)来获取高速缓存中对应的数据。

这时候可以看到Flag这个标识了,然后就可以引出了状态值的概念,然后就可以引出我们所说的MSEI协议了。

MESI

状态 描述
M 修改 (Modified) 该Cache line有效,数据被修改了,和内存中的数据不一致,数据只存在于本Cache中。
E 独享、互斥 (Exclusive) 该Cache line有效,数据和内存中的数据一致,数据只存在于本Cache中。
S 共享 (Shared) 该Cache line有效,数据和内存中的数据一致,数据存在于很多Cache中。
I 无效 (Invalid) 该Cache line无效。

  • E(独占)状态

image-20210515165217310

只有Core 0访问变量x,它的Cache line状态为E(Exclusive)。

  • S(共享)状态

在这里插入图片描述

3个Core都访问变量x,它们对应的Cache line为S(Shared)状态。

  • M(修改)状态

在这里插入图片描述

Core 0修改了x的值之后,这个Cache line变成了M(Modified)状态

  • I状态

在这里插入图片描述

在一个Core修改x后,相应的,其他Core对应的Cache line变成了I(Invalid)状态。

  • 状态的改变

cache line存在四种状态,状态是动态的,肯定是有一定的操作使得状态发生了改变,那么操作是什么呢?

在这里插入图片描述

  1. Local Read表示本内核读本Cache中的值
  2. Local Write表示本内核写本Cache中的值
  3. Remote Read表示其它内核读其它内核Cache中的值
  4. Remote Write表示其它内核写其它内核Cache中的值
  • 总结

MESI协议为了保证多个CPU cache中共享数据的一致性,定义了cache line的四种状态,而CPU对cache的4种操作可能会产生不一致状态,因此cache控制器监听到本地操作和远程操作的时候,需要对地址一致的cache line状态做出一定的修改,从而保证数据在多个cache之间流转的一致性。

写缓存 - Store Buffer

  • 场景引入

有一个变量在多个核中的缓存存在,那么这个缓存的状态是S(shared)共享的,现在核A想要修改这个变量,首先核A会向所有拥有相同缓存的其他核发送一个请求,告诉其他核中的缓存是I(Invalid)无效的,其他核收到这个信息将自己核中的缓存状态设置为无效之后,返回一个设置完成的消息,这个核A收到这个无效状态修改的消息后,再把自己的状态改为E(Exclusive)独享的,然后修改为M(Modified)进行缓存修改。

思考下:在核A等待其他核返回无效状态修改的消息返回的时候它做了什么?它什么都没做,一直处于阻塞状态。

因此,设计者引入了写缓存(Store Buffer)的无效化队列(Invalidate Queue)来解决这个问题。

  • 概述

写缓存是一个容量极小的高速存储部件,每个核都有自己的写缓存,而且一个核不能够读取到其他核的写缓存(Store Buffer)的内容,相当于一个自己的本地缓存。

如上面的场景,核A修改共享的缓存,先将这个修改操作放入到写缓存(Store Buffer)中,再告诉其他核中的缓存失效了,然后核A继续执行其他指令操作,当接受到了其他核返回无效状态修改的消息之后,才将写缓存(Store Buffer)中的操作写入到核A中的缓存中,这时写操作才算完成。

这样就解决了等待阻塞所带来的性能问题,减少了延时,提高了执行效率。

image-20210515201924136

无效化队列 - Invalidate Queue

修改方为了能够快速进行回应所以,先将无效的操作放到队列里面去,并立刻返回无效状态修改的消息,等当前的操作执行完再回来真正的把缓存里面的值标识为I状态,这个存放无效操作的队列就叫做无效化队列。同时可能也是考虑到了写缓存(Store Buffer)是比较小的高速缓存,如果不能够及时返回会造成写缓存满了,还是需要等待无效状态修改的消息的返回才能继续进行后续的指令,所以就出现了无效化队列和写缓存配合使用。

image-20210515205726015

写缓存与无效化队列的不足性

  • 单核情况

image-20210515203558901

令b=x+1,因为x已经在缓存中读到的为0,b为1,所以判断是false,虽然后来Store Buffer后来将x的值刷新到了缓存中,但是已经晚了

所以为了避免这个问题,Store Buffer设计了一种策略叫做Store Forwarding。就是说核A在读取数据的时候会先看Store Buffer中的数据,如果Store Buffer中有数据,直接使用Store Buffer中的,从而避免使用错误数据。

  • 多核情况
  1. 情况一

    核B在进行判断的时候发现在自己的缓存存在x=0,就直接+1进行了赋值判断,但此时核A刚刚将x=2的操作放到Store Buffer中,所以由于Store Buffer的存在导致多核下不能获取到最新值,所以产生了错误的结果。

    image-20210515205858812

    所以为了解决上面的问题出现了写屏障,写屏障的出现保证屏障两边写的执行是分开的,也就是说需要先将之前Store Buffer中的所有写指令都刷新到缓存之后,才执行后面的写指令。
    具体实现方法是,【先将屏障之前的Store Buffer中所有操作都刷新到缓存中】,将屏障后的所有指令操作也同样放到Store Buffer中,不管后续的操作是什么都往里面放,这样可以提高CPU的执行效率,都通过Store Buffer刷新到了缓存中,达到了数据来源的统一性。

  2. 情况二

    核B在进行判断的时候发现在自己的缓存存在x=0,就直接+1进行了赋值判断,但此时核B刚刚将x的无效操作放到Invalidate Queue中,所以由于Invalidate Queue的存在导致多核下不能获取到最新值,所以产生了错误的结果。

    image-20210515205805900

    所以为了解决上面的问题出现了读屏障,读屏障的出现保证屏障两边读的执行是分开的,也就是说需要先将之前Invalidate Queue中的所有指令处理完之后,才执行后面的指令,保证下一次读取共享变量的时候读到的是最新的变量。

内存屏障

通过上面对错误情况的分析可以知道,内存屏障的出现就是为了解决因为Store Buffer和Invalidate Queue所带来的数据可见性问题,也就是读和写不能实时更新到其他核的问题。内存屏障同时还具备强制将Store Buffer的内容刷到缓存中,强制将Invalidate Queue中的内容设置完毕的作用。

  • 硬件层的内存屏障分为两种:Load (Memory) Barrier读屏障Store (Memory) Barrier写屏障
  • 内存屏障有两个作用:
  1. 阻止屏障两侧的指令重排序;
  2. 强制把写缓冲区/高速缓存中的脏数据等写回主内存,让缓存中相应的数据失效。
  • 对于Load Barrier来说,在指令前插入Load Barrier,可以让高速缓存中的数据失效,强制从新从主内存加载数据

    或者说: 强制将Invalidate Queue中的内容处理完毕,也被称之为smp_rmb

  • 对于Store Barrier来说,在指令后插入Store Barrier,能让写入缓存中的最新数据更新写入主内存,让其他线程可见。

    或者说:强制将Store Buffer中的内容写入到缓存中或者将该指令之后的写操作写入store buffer直到之前的内容被刷入到缓存中,也被称之为smp_wmb

内存屏障分类

  1. 按照可见性保障来划分
    内存屏障可分为:加载屏障(Load Barrier)和存储屏障(Store Barrier)

    加载屏障:StoreLoad屏障可充当加载屏障,作用是刷新处理器缓存,即清空无效化队列,使处理器在读取共享变量时,先从主内存或其他处理器的高速缓存中读取相应变量,更新到自己的缓存中

    存储屏障:StoreLoad屏障可充当存储屏障,作用是冲刷处理器缓存,即将写缓冲器内容写入高速缓存中,使处理器对共享变量的更新写入高速缓存或者主内存中
    这两个屏障一起保证了数据在多处理器之间是可见的。

  2. 按照有序性保障来划分
    内存屏障分为:获取屏障(Acquire Barrier)和释放屏障(Release Barrier)

    获取屏障:相当于LoadLoad屏障与LoadStore屏障的组合。在读操作后插入,禁止该读操作与其后的任何读写操作发生重排序;

    释放屏障:相当于LoadStore屏障与StoreStore屏障的组合。在一个写操作之前插入,禁止该写操作与其前面的任何读写操作发生重排序。

    这两个屏障一起保证了临界区中的任何读写操作不可能被重排序到临界区之外。

Java内存屏障

  • Java四种屏障其实是Load BarrierStore Barrier的两两组合(2 × 2 = 4)

    此处提及的【load → 加载】和【store → 写入】

    • LoadLoad:对于语句 Load1; 【LoadLoad】; Load2,这个屏障的作用是确保在Load2加载代码在要读取的数据之前,保证Load1加载代码要从主内存里面读取的数据读取完毕。

      即:该屏障保证了在屏障前的读取操作效果先于屏障后的读取操作效果发生。在各个不同平台上会插入的编译指令不相同,可能的一种做法是插入也被称之为smp_rmb指令,强制处理完成当前的invalidate queue中的内容

    • StoreStore:对于语句Store1; 【StoreStore】; Store2,这个屏障的作用是保证在Store2存储代码进行写入操作执行前,保证Store1的写入操作已经把数据写入到主内存里面,确认Store1的写入操作对其它处理器可见。

      即:该屏障保证了在屏障前的写操作效果先于屏障后的写操作效果发生。可能的做法是使用smp_wmb指令,而且是使用该指令中,将后续写入数据先写入到store buffer的那种处理方式。因为这种方式消耗比较小

    • LoadStore:对于语句Load1; 【LoadStore】; Store2,这个屏障的作用是保证在Store2存储代码进行写入操作执行前,保证Load1加载代码要从主内存里面读取的数据读取完毕。

      即:该屏障保证了屏障前的读操作效果先于屏障后的写操作效果发生。

    • StoreLoad:对于语句Store1; StoreLoad; Load2,这个屏障的作用是保证load2从主内存里加载数据之前,store1的写入操作已经把数据写入到内存中,确认store1的写入操作对其他处理器可见

      即:该屏障保证了屏障前的写操作效果先于屏障后的读操作效果发生。可能的做法就是插入一个smp_mb指令来完成。StoreLoad屏障是开销最昂贵的一种屏障,其中一部分原因是因为他需要把写缓冲区的所有数据全部刷新到内存

如何保证可见性

可见性的实现依靠了:lock前缀指令 + MESI缓存一致性协议

实现原理 - Lock前缀

被volatile修饰的字段会在其对应的汇编操作指令上加个lock前缀指令,这个指令就可以解决可见性问题。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public class Visable {
private volatile static boolean flag = true;

public static void main(String[] args) throws InterruptedException {

new Thread(()-> {
while(flag) {

}
}).start();

Thread.sleep(2000);

new Thread(() -> {
flag = false;
System.out.println("修改了共享变量flag的值");
}).start();
}
}

其执行结果:

在这里插入图片描述

lock前缀的指令在多核处理器下会引发两件事情

  1. 将当前处理器缓存行的数据写回到系统内存。
  2. 这个写回内存的操作会使在其他CPU里缓存了该内存地址的数据无效。

为了提高处理速度,处理器不直接和内存进行通信,而是先将系统内存的数据读到内部缓存后再进行操作,但是操作完了不知道什么时候写回内存。

而对声明了volatile关键字的变量进行写操作,JVM会向处理器发送一条lock前缀的指令,将这个变量所在的缓存行立即写回系统内存。并且为了保证各个处理器的缓存是一致的,实现了缓存一致性协议,各个处理器通过嗅探在总线上传播的数据来检查自己缓存的值是不是过期了,当处理器发现自己缓存行对应的内存地址被修改,就会将当前处理器的缓存行设置成无效状态,那么下次对这个数据进行操作,就会重新从系统内存中获取最新的值。对应JMM来说就是:

  1. Lock前缀的指令让线程工作内存中的值写回主内存中;
  2. 通过缓存一致性协议,其他线程如果工作内存中存了该共享变量的值,就会失效;
  3. 其他线程会重新从主内存中获取最新的值;

如何保证有序性

可靠性的实现依靠了:内存屏障,禁止了重排序

  • 在每个volatile写操作的前面插入一个StoreStore屏障。
  • 在每个volatile写操作的后面插入一个StoreLoad屏障。
  • 在每个volatile读操作的后面插入一个LoadLoad屏障。
  • 在每个volatile读操作的后面插入一个LoadStore屏障。

image-20210515162606107

CAS

CAS概述

使用锁时,线程获取锁是一种悲观锁策略,即假设每一次执行临界区代码都会产生冲突,所以当前线程获取到锁的时候同时也会阻塞其他线程获取该锁。而CAS操作(又称为无锁操作)是一种乐观锁策略,它假设所有线程访问共享资源的时候不会出现冲突,既然不会出现冲突自然而然就不会阻塞其他线程的操作。

因此,线程就不会出现阻塞停顿的状态。那么,如果出现冲突了怎么办?无锁操作是使用CAS(compare and swap / 比较与替换)又叫做比较交换来鉴别线程是否出现冲突,出现冲突就重试当前操作直到没有冲突为止。

  • 悲观锁:会阻塞其他线程
  • 乐观锁:不会阻塞其他线程,如果发生冲突,采用死循环的方式一直重试,直到更新成功。

是一种无锁算法

CAS操作过程

CAS比较交换的过程可以通俗的理解为CAS(V,O,N),包含三个值分别为:V 内存地址存放的实际值;O 预期的值(旧值);N 更新的新值

  • 当V和O相同时,也就是说旧值和内存中实际的值相同表明该值没有被其他线程更改过,即该旧值O就是目前来说最新的值了,自然而然可以将新值N赋值给V。
  • 反之,V和O不相同,表明该值已经被其他线程改过了则该旧值O不是最新版本的值了,所以不能将新值N赋给V,返回V即可。当多个线程使用CAS操作一个变量是,只有一个线程会成功,并成功更新,其余会失败。失败的线程会重新尝试,当然也可以选择挂起线程

CAS的实现需要硬件指令集的支撑,在JDK1.5后虚拟机才可以使用处理器提供的CMPXCHG指令实现。

Synchronized VS CAS

元老级的Synchronized(未优化前)最主要的问题是:在存在线程竞争的情况下会出现线程阻塞和唤醒锁带来的性能问题,因为这是一种互斥同步(阻塞同步)。而CAS并不是武断的间线程挂起,当CAS操作失败后会进行一定的尝试,而非进行耗时的挂起唤醒的操作,因此也叫做非阻塞同步。这是两者主要的区别。

CAS应用场景

在J.U.C包中利用CAS实现类有很多,可以说是支撑起整个concurrency包的实现,在Lock实现中会有CAS改变state变量,在atomic包中的实现类也几乎都是用CAS实现。具体实现后续详细聊;

CAS存在的问题

1. ABA问题
因为CAS会检查旧值有没有变化,这里存在这样一个有意思的问题。比如一个旧值A变为了成B,然后再变成A,刚好在做CAS时检查发现旧值并没有变化依然为A,但是实际上的确发生了变化。解决方案可以沿袭数据库中常用的乐观锁方式,添加一个版本号可以解决。原来的变化路径A->B->A就变成了1A->2B->3C。java这么优秀的语言,当然在java 1.5后的atomic包中提供了AtomicStampedReference来解决ABA问题,解决思路就是这样的。

2. 自旋时间过长

使用CAS时非阻塞同步,也就是说不会将线程挂起,会自旋(无非就是一个死循环)进行下一次尝试,如果这里自旋时间过长对性能是很大的消耗。如果JVM能支持处理器提供的pause指令,那么在效率上会有一定的提升。

3. 只能保证一个共享变量的原子操作

原子性:原子性问题指的是多线程并发的情况下,当我们要进行数据的读取与修改时,可能会因为线程同时读取数据,导致进行了重复修改的情况,但是我们希望每个线程进行读取修改操作是连贯的、原子性的,在A线程进行读取修改的时候,不允许其他线程进行读取修改,而一定要等到A线程完成修改后,其他线程再去进行读取修改。比如我们要将数字0累加到10,在多线程的情况下,可能会因为线程A在读完数字但是还没有进行修改的时候,线程B也来读了数字,导致线程A的原子性被打破,使得它们累加后得到的数据是一样的,这就破坏了原子性。

当对一个共享变量执行操作时CAS能保证其原子性,如果对多个共享变量进行操作,CAS就不能保证其原子性。有一个解决方案是利用对象整合多个共享变量,即一个类中的成员变量就是这几个共享变量。然后将这个对象做CAS操作就可以保证其原子性。atomic中提供了AtomicReference来保证引用对象之间的原子性。

Java对象头 monitor

Java对象头和monitor是实现synchronized的基础

Java对象头

概述

JVM中,对象在内存中的布局分为三块区域:对象头、实例数据和对齐填充

image-20210426161645623

  • 实例数据:存放类的属性数据信息,包括父类的属性信息,如果是数组的实例部分还包括数组的长度,这部分内存按4字节对齐。

  • 对齐填充:由于虚拟机要求对象起始地址必须是8字节的整数倍。填充数据不是必须存在的,仅仅是为了字节对齐

  • 对象头

    • 普通对象

      在这里插入图片描述

    • 数组对象

      在这里插入图片描述

对象头的组成

Mark Word

Mark Word用于存储对象自身的运行时数据,如哈希码(HashCode)、GC分代年龄、锁状态标志、线程持有的锁、偏向线程 ID、偏向时间戳等等

  • 32位JVM 的Mark Word的默认存储结构

对象头信息是与对象自身定义的数据无关的额外存储成本,但是考虑到虚拟机的空间效率,Mark Word被设计成一个非固定的数据结构以便在极小的空间内存存储尽量多的数据,它会根据对象的状态复用自己的存储空间,也就是说,Mark Word会随着程序的运行发生变化。

img

  • 具体结构

    在这里插入图片描述

  • 锁标记位(lock):该标记的值不同,则Mark word表示的含义不同

    在这里插入图片描述

    • 无锁:无锁状态时,存储的是对象的hashcode值
    • 偏向锁:偏向锁时,前23位存储偏向的线程ID,并将倒数第三位置为1,表示偏向锁。
    • 轻量级锁:轻量级锁时,存储的是 指向JVM栈中的锁记录Lock Record的指针
    • 重量级锁:当自旋次数超过10次时,将转换成重量级锁,重量级锁存储的是 指向重量级锁Monitor的指针
  • 是否为偏向锁(biased_lock):对象是否启用偏向锁标记,只占1个二进制位。为1时表示对象启用偏向锁,为0时表示对象没有偏向锁。

  • 对象分代年龄(age):4位的Java对象年龄。在GC中,如果对象在Survivor区复制一次,年龄增加1。当对象达到设定的阈值时,将会晋升到老年代。默认情况下,并行GC的年龄阈值为15,并发GC的年龄阈值为6。由于age只有4位,所以最大值为15,这就是-XX:MaxTenuringThreshold选项最大值为15的原因。

  • identity_hashcode: 25位的对象标识Hash码,采用延迟加载技术。调用方法System.identityHashCode()计算,并会将结果写到该对象头中。当对象被锁定时,该值会移动到管程Monitor中。

  • thread: 持有偏向锁的线程ID。

  • epoch:偏向时间戳。

  • ptr_to_lock_record:指向栈中锁记录的指针。

  • ptr_to_heavyweight_monitor:指向管程Monitor的指针。

class pointer

这一部分用于存储对象的类型指针,该指针指向它的类元数据,JVM通过这个指针确定对象是哪个类的实例。该指针的位长度为JVM的一个字大小,即32位的JVM为32位,64位的JVM为64位。

为了节约内存可以使用选项+UseCompressedOops开启指针压缩,其中,oop即ordinary object pointer普通对象指针。开启该选项后,下列指针将压缩至32位:

  1. 每个Class的属性指针(即静态变量)
  2. 每个对象的属性指针(即对象变量)
  3. 普通对象数组的每个元素指针

当然,也不是所有的指针都会压缩,一些特殊类型的指针JVM不会优化,比如指向PermGen的Class对象指针(JDK8中指向元空间的Class对象指针)、本地变量、堆栈元素、入参、返回值和NULL指针等。

array length

如果对象是一个数组,那么对象头还需要有额外的空间用于存储数组的长度,这部分数据的长度也随着JVM架构的不同而不同:32位的JVM上,长度为32位;64位JVM则为64位。64位JVM如果开启+UseCompressedOops选项,该区域长度也将由64位压缩至32位。

monitor

monitor是什么?它是一个同步工具,是一种同步机制,通常被描述为一个【对象】;

monitor概念其实我们早就接触过了,它就是OS中的【管程】;

Monitor是一个对象,这代表着什么?在Java世界中,一切皆对象,那么所有的Java对象其实都是monitor,或者说所有的对象都可以去关联一个Monitor对象。(这也是为什么上面需要学习Java对象头,因为结合monitor我们就可以通过设置标识位做到线程同步了)

  • Monitor概念

Monitor 是线程私有的数据结构,每一个线程都有一个可用monitor record列表,同时还有一个全局的可用列表

每一个被锁住的对象都会和一个monitor关联(对象头的MarkWord中的LockWord指向monitor的起始地址

同时monitor中有一个Owner字段存放拥有该锁的线程的唯一标识,表示该锁被这个线程占用

  • Monitor结构图

这里写图片描述

  1. Owner:初始时为NULL表示当前没有任何线程拥有该monitor record,当线程成功拥有该锁后保存线程唯一标识,当锁被释放时又设置为NULL;
  2. EntryQ:关联一个系统互斥锁(semaphore),阻塞所有试图锁住monitor record失败的线程。
  3. RcThis:表示blocked或waiting在该monitor record上的所有线程的个数。
  4. Nest:用来实现重入锁的计数。
  5. HashCode:保存从对象头拷贝过来的HashCode值(可能还包含GC age)。
  6. Candidate:用来避免不必要的阻塞或等待线程唤醒,因为每一次只有一个线程能够成功拥有锁,如果每次前一个释放锁的线程唤醒所有正在阻塞或等待的线程,会引起不必要的上下文切换(从阻塞到就绪然后因为竞争锁失败又被阻塞)从而导致性能严重下降。Candidate只有两种可能的值0表示没有需要唤醒的线程1表示要唤醒一个继任线程来竞争锁。

synchronized(内置锁)

概述

Java中最常用的同步机制就是synchronized关键字,它是一种基于语言的粗略锁(也就是说本质其实也是一把锁),能够作用于对象、函数、Class上。

synchronized是一种互斥锁:意味着一次只能允许一个线程进入被锁住的代码块

synchronized是一种内置锁/监视器锁:Java中每个对象都有一个内置锁(监听器monitor,可理解为锁标记),synchronized就是通过使用对象的内置锁(监听器)来将代码块(方法)锁定的。(这部分内容结合monitor的相关知识好理解一点)

用处

  • synchronized保证了线程的原子性。(被保护的代码块是一次被执行的,没有任何线程会同时访问)
  • synchronized还保证了可见性。(当执行完synchronized之后,修改后的变量对其他的线程是可见的)

Java中的synchronized,通过使用内置锁,来实现对变量的同步操作,进而实现了对变量操作的原子性和其他线程对变量的可见性,从而确保了并发情况下的线程安全。

一句话来说:

synchronized修饰的区域看作是一个临界区,临界区内只能有一个线程在访问,当访问线程退出临界区,另一个线程才能访问临界区资源。

原理

  • synchronized原理 - 指令层面
1
2
3
4
5
6
7
public class SynchronizedDemo {
public void method() {
synchronized (this) {
System.out.println("Method 1 start");
}
}
}

反编译结果:

img


这里出现了两个关键指令【monitorenter】和【monitorexit】

【monitorenter】

每个对象有一个监视器锁(monitor)。当monitor被占用时就会处于锁定状态,线程执行monitorenter指令时尝试获取monitor的所有权(类似于操作系统中的P操作),过程如下:

  1. 如果monitor的进入数为0,则该线程进入monitor,然后将进入数设置为1,该线程即为monitor的所有者。
  2. 如果线程已经占有该monitor,只是重新进入,则进入monitor的进入数加1.
  3. 如果其他线程已经占用了monitor,则该线程进入阻塞状态,直到monitor的进入数为0,再重新尝试,获取monitor的所有权。

【monitorexit】

注意:执行monitorexit的线程必须是objectref所对应的monitor的所有者。

该指令执行时,monitor的进入数减1,如果减1后进入数为0,那线程退出monitor,不再是这个monitor的所有者。(类似于OS中的V操作)其他被这个monitor阻塞的线程可以尝试去获取这个 monitor 的所有权。


结合这两个指令的含义,我们能够推断出Synchronized的实现原理:Synchronized的语义底层是通过一个monitor的对象来完成类似于OS中的PV操作,达到线程同步。

  • synchronized实现原理 - 底层/字节码层面
1
2
3
4
5
public class SynchronizedMethod {
public synchronized void method() {
System.out.println("Hello World!");
}
}

反编译结果:

img

从字节码中可以看出,synchronized修饰的方法并没有monitorenter指令和monitorexit指令,取得代之的确实是ACC_SYNCHRONIZED标识,该标识指明了该方法是一个同步方法,JVM通过该ACC_SYNCHRONIZED标识访问标志来辨别一个方法是否声明为同步方法,从而执行相应的同步调用

具体实现:

当方法调用时,调用指令将会检查方法的 ACC_SYNCHRONIZED 访问标志是否被设置,如果设置了,执行线程将先获取monitor,获取成功之后才能执行方法体,方法执行完后再释放monitor。

使用

  • 使用synchronized实现同步

使用synchronized关键字声明的方法 成为了 临界区。这样做,就使得临界区被创建出来了,由之前所学可以知道,同一个对象的临界区,在同一时间只有一个允许被访问。

用synchronized关键字声明的静态方法,同时只能被一个执行线程访问,但是其他线程可以访问这个对象的非静态方法。即:两个线程可以同时访问一个对象的两个不同的synchronized方法,其中一个是静态方法,一个是非静态方法

synchronized作用于实例方法

修饰实例方法,作用于当前【实例对象】加锁,进入同步代码前要获得当前【实例对象】的锁

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
public class AccountingSync implements Runnable{
//共享资源(临界资源)
static int i=0;

/**
* synchronized 修饰实例方法
*/
public synchronized void increase(){
i++;
}
@Override
public void run() {
for(int j=0;j<1000000;j++){
increase();
}
}
public static void main(String[] args) throws InterruptedException {
AccountingSync instance=new AccountingSync();
Thread t1=new Thread(instance);
Thread t2=new Thread(instance);
t1.start();
t2.start();
t1.join();
t2.join();
System.out.println(i);
}
/**
* 输出结果:
* 2000000
*/
}

代码解释:

我们使用static关键字构造了一个临界资源:static int i=0;

同时,构建了一个实例方法

1
2
3
public synchronized void increase(){
i++;
}

i++的操作并不具备原子性(先读i的值,对i进行++操作,后写回新值),如果第二个线程在第一个线程读取旧值和写回新值期间读取i的域值,那么第二个线程就会与第一个线程一起看到同一个值,并执行相同值的加1操作,这也就造成了线程安全失败,因此对于increase方法必须使用synchronized修饰,以便保证线程安全。

synchronized修饰的是实例方法increase(),即:当前线程上的锁作用于实例对象instance

当一个线程正在访问一个对象的 synchronized 实例方法,那么其他线程不能访问该对象的其他 synchronized 方法,毕竟一个对象只有一把锁,当一个线程获取了该对象的锁之后,其他线程无法获取该对象的锁,所以无法访问该对象的其他synchronized实例方法,但是其他线程还是可以访问该实例对象的其他非synchronized方法。


如果是一个线程 A 需要访问实例对象 obj1 的 synchronized 方法 f1(当前对象锁是obj1),另一个线程 B 需要访问实例对象 obj2 的 synchronized 方法 f2(当前对象锁是obj2),这样是允许的,因为两个实例对象锁并不同相同,此时如果两个线程操作数据并非共享的,线程安全是有保障的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
public class AccountingSyncBad implements Runnable{
static int i=0;
public synchronized void increase(){
i++;
}
@Override
public void run() {
for(int j=0;j<1000000;j++){
increase();
}
}
public static void main(String[] args) throws InterruptedException {
//new新实例
Thread t1=new Thread(new AccountingSyncBad());
//new新实例
Thread t2=new Thread(new AccountingSyncBad());
t1.start();
t2.start();
//join含义:当前线程A等待thread线程终止之后才能从thread.join()返回
t1.join();
t2.join();
System.out.println(i);
}
}

代码解释

这段代码中创建了两个新实例:AccountingSyncBad

1
2
3
4
//new新实例
Thread t1=new Thread(new AccountingSyncBad());
//new新实例
Thread t2=new Thread(new AccountingSyncBad());

然后启动两个不同的线程对共享变量i进行操作

1
2
3
4
5
6
7
8
9
public synchronized void increase(){
i++;
}
@Override
public void run() {
for(int j=0;j<1000000;j++){
increase();
}
}

但结果却不会是2000000,因为虽然我们使用synchronized修饰了increase方法,但却new了两个不同的实例对象,这也就意味着存在着两个不同的实例对象锁,因此t1和t2都会进入各自的对象锁,也就是说t1和t2线程使用的是不同的锁,因此线程安全是无法保证的

解决方案:

将synchronized作用于静态的increase方法,这样的话,对象锁就当前类对象,由于无论创建多少个实例对象,但对于的类对象拥有只有一个,所有在这样的情况下对象锁就是唯一的。


synchronized作用于静态方法

修饰静态方法,作用于当前【类对象/class对象】加锁,进入同步代码前要获得当前【类对象/class对象】的锁

果一个线程A调用一个实例对象的非static synchronized方法,而线程B需要调用这个实例对象所属类的静态 synchronized方法,是允许的,不会发生互斥现象,是因为:

  • 访问静态 synchronized 方法占用的当前类的class对象

  • 而访问非静态 synchronized 方法占用的是当前实例对象(this)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
public class AccountingSyncClass implements Runnable{
static int i=0;

/**
* 作用于静态方法,锁是当前class对象,也就是
* AccountingSyncClass类对应的class对象
*/
public static synchronized void increase(){
i++;
}

/**
* 非静态,访问时锁不一样不会发生互斥
*/
public synchronized void increase4Obj(){
i++;
}

@Override
public void run() {
for(int j=0;j<1000000;j++){
increase();
}
}
public static void main(String[] args) throws InterruptedException {
//new新实例
Thread t1=new Thread(new AccountingSyncClass());
//new新实例
Thread t2=new Thread(new AccountingSyncClass());
//启动线程
t1.start();t2.start();

t1.join();t2.join();
System.out.println(i);
}
}

代码解释:

由于synchronized关键字修饰的是静态increase方法,与修饰实例方法不同的是,其锁对象是当前类的class对象。注意代码中的increase4Obj方法实例方法,其对象锁是当前实例对象,如果别的线程调用该方法,将不会产生互斥现象,毕竟锁对象不同,但我们应该意识到这种情况下可能会发现线程安全问题(操作了共享静态变量i)。


synchronized同步代码块

修饰代码块,指定加锁对象,对【给定对象(括号中的对象)】加锁,进入同步代码库前要获得【给定对象(括号中的对象)】的锁

  • 使用场景

在某些情况下,我们编写的方法体可能比较大,同时存在一些比较耗时的操作,而需要同步的代码又只有一小部分,如果直接对整个方法进行同步操作,可能会得不偿失,此时我们可以使用同步代码块的方式对需要同步的代码进行包裹,这样就无需对整个方法进行同步操作了

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public class AccountingSync implements Runnable{
static AccountingSync instance=new AccountingSync();
static int i=0;
@Override
public void run() {
//省略其他耗时操作....
//使用同步代码块对变量i进行同步操作,锁对象为instance
synchronized(instance){
for(int j=0;j<1000000;j++){
i++;
}
}
}
public static void main(String[] args) throws InterruptedException {
Thread t1=new Thread(instance);
Thread t2=new Thread(instance);
t1.start();t2.start();
t1.join();t2.join();
System.out.println(i);
}
}


代码解释:

将synchronized作用于一个给定的实例对象instance,即当前实例对象就是锁对象,每次当线程进入synchronized包裹的代码块时就会要求当前线程持有instance实例对象锁,如果当前有其他线程正持有该对象锁,那么新到的线程就必须等待,这样也就保证了每次只有一个线程执行i++;操作。


另外一种写法,用this对象(代表当前实例)或者直接用当前类的class对象作为锁

1
2
3
4
5
6
7
8
9
10
11
12
13
//this,当前实例对象锁
synchronized(this){
for(int j=0;j<1000000;j++){
i++;
}
}

//class对象锁
synchronized(AccountingSync.class){
for(int j=0;j<1000000;j++){
i++;
}
}

锁/锁优化

前言

在Java早期版本中,synchronized属于重量级锁,效率低下,因为监视器锁(monitor)是依赖于底层的操作系统的Mutex Lock来实现的,而操作系统实现线程之间的切换时需要从用户态转换到核心态,这个状态之间的转换需要相对比较长的时间,时间成本相对较高,这也是为什么早期的synchronized效率低的原因。庆幸的是在Java 6之后Java官方对从JVM层面对synchronized较大优化,所以现在的synchronized锁效率也优化得很不错了,Java 6之后,为了减少获得锁和释放锁所带来的性能消耗,引入了轻量级锁和偏向锁,接下来我们将简单了解一下Java官方在JVM层面对synchronized锁的优化。

概述

锁的状态总共有四种,无锁状态、偏向锁、轻量级锁和重量级锁。随着锁的竞争,锁可以从偏向锁升级到轻量级锁,再升级的重量级锁,但是锁的升级是单向的,也就是说只能从低到高升级,不会出现锁的降级,这种策略是为了提高获得锁和释放锁的效率

偏向锁

  • 概述

向锁是Java 6之后加入的新锁,它是一种针对加锁操作的优化手段,经过研究发现,在大多数情况下,锁不仅不存在多线程竞争,而且总是由同一线程多次获得

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
import java.util.ArrayList;
import java.util.List;

public class SyncDemo1 {

public static void main(String[] args) {
SyncDemo1 syncDemo1 = new SyncDemo1();
for (int i = 0; i < 100; i++) {
syncDemo1.addString("test:" + i);
}
}

private List<String> list = new ArrayList<>();

public synchronized void addString(String s) {
list.add(s);
}

}

在这个demo中为了保证对list操纵时线程安全,对addString方法加了synchronized的修饰,但实际使用时却只有一个线程调用到该方法,对于轻量级锁而言,每次调用addString时,加锁解锁都有一个CAS操作;对于重量级锁而言,加锁也会有一个或多个CAS操作。

因此为了减少同一线程获取锁(会涉及到一些CAS操作,耗时)的代价,或者说为了提高一个对象在一段很长的时间内都只被一个线程用做锁对象场景下的性能,我们引入了偏向锁

  • 思想

如果一个线程获得了锁,那么锁就进入偏向模式,此时Mark Word 的结构也变为偏向锁结构,当这个线程再次请求锁时,无需再做任何同步操作,即获取锁的过程,这样就省去了大量有关锁申请的操作,从而也就提供程序的性能

  • 具体执行
  1. 对象创建

    当JVM启用了偏向锁模式(1.6以上默认开启),当新创建一个对象的时候,如果该对象所属的class没有关闭偏向锁模式(默认所有class的偏向模式都是是开启的,可通过参数关闭),那新创建对象mark word将是可偏向状态,此时mark word中thread id0:表示未偏向任何线程,也叫做匿名偏向(anonymously biased)

  2. 加锁/获取锁过程

    1. 检测Mark Word是否为可偏向状态。即访问Mark Word中偏向锁的标识是否设置成1,锁标志位是否为01——确认为可偏向状态。

    2. 假如是可偏向状态,则测试线程ID是否指向当前线程,如果是,会往当前线程的栈中添加一条Displaced Mark Word为空的Lock Record中,进入步骤(5);如果线程ID不指向当前线程,则进入步骤(3)。

      (当该对象第一次被线程获得锁的时候,发现是匿名偏向状态(即thread id = 0),则会用CAS指令,将mark word中的thread id由0改成当前线程Id。如果成功,则代表获得了偏向锁,继续执行同步块中的代码。在以后只要不发生竞争,这个对象就归该线程所持有。失败的话,进入步骤(4))

      当被偏向的线程再次进入同步块时,操纵的是线程私有的栈,因此不需要用到CAS指令;由此可见偏向锁模式下,当被偏向的线程再次尝试获得锁时,仅仅进行几个简单的操作就可以了,在这种情况下,synchronized关键字带来的性能开销基本可以忽略

    3. 如果线程ID并未指向当前线程,则通过CAS操作竞争锁。如果竞争成功,则将Mark Word中线程ID设置为当前线程ID(竞争成功的线程将获得偏向锁的所有权),然后执行(5);如果竞争失败,执行(4)。

    4. 进行撤销偏向锁的操作】通过CAS竞争锁失败,证明当前存在多线程竞争情况,当到达全局安全点(safepoint),之前获得偏向锁的线程被挂起,对该线程进行状态判断。

      1. 若线程仍存活且还在同步块:锁升级为轻量级锁。
      2. 如果偏向的线程已经不存活或者不在同步块中:则将对象头的mark word改为无锁状态(unlocked),偏向锁不升级,并且环形
    5. 执行同步代码块

    由此可见:偏向锁升级的时机为:当锁已经发生偏向后,只要有另一个线程尝试获得偏向锁,则该偏向锁就会升级成轻量级锁。当然这个说法不绝对,因为还有批量重偏向这一机制。

  1. 解锁/偏向锁释放过程

    偏向锁只有遇到其他线程尝试竞争偏向锁时,持有偏向锁的线程才会释放锁,线程不会主动去释放偏向锁。偏向锁的撤销,需要等待全局安全点safe point(在这个时间点上没有字节码正在执行)

    1. 它会首先暂停拥有偏向锁的线程,判断锁对象是否处于被锁定状态
    2. 撤销偏向锁后恢复到未锁定(标志位为“01”)或轻量级锁(标志位为“00”)的状态。
  • 偏向锁的获取/解锁流程图解

image-20210429174346151

  • 锁状态的转换流程

img

1)一个对象刚开始实例化的时候,没有任何线程来访问它的时候。它是可偏向的,意味着,它现在认为只可能有一个线程来访问它,所以当第一个线程来访问它的时候,它会偏向这个线程,此时,对象持有偏向锁。偏向第一个线程,这个线程在修改对象头成为偏向锁的时候使用CAS操作,并将对象头中的ThreadID改成自己的ID,之后再次访问这个对象时,只需要对比ID,不需要再使用CAS在进行操作。

2) 一旦有第二个线程访问这个对象,因为偏向锁不会主动释放,所以第二个线程可以看到对象时偏向状态,这时表明在这个对象上已经存在竞争了。检查原来持有该对象锁的线程是否依然存活,如果挂了,则可以将对象变为无锁状态,然后重新偏向新的线程。如果原来的线程依然存活,则马上执行那个线程的操作栈,检查该对象的使用情况,如果仍然需要持有偏向锁,则偏向锁升级为轻量级锁,(偏向锁就是这个时候升级为轻量级锁的),此时轻量级锁由原持有偏向锁的线程持有,继续执行其同步代码,而正在竞争的线程会进入自旋等待获得该轻量级锁;如果不存在使用了,则可以将对象回复成无锁状态,然后重新偏向。

3)轻量级锁认为竞争存在,但是竞争的程度很轻,一般两个线程对于同一个锁的操作都会错开,或者说稍微等待一下(自旋),另一个线程就会释放锁。 但是当自旋超过一定的次数,或者一个线程在持有锁,一个在自旋,又有第三个来访时,轻量级锁膨胀为重量级锁,重量级锁使除了拥有锁的线程以外的线程都阻塞,防止CPU空转。

批量重偏向与撤销

  • 概述

对于偏向锁的加锁解锁过程,当只有一个线程反复进入同步块时,偏向锁带来的性能开销基本可以忽略,但是当有其他线程尝试获得锁时,就需要等到safe point时将偏向锁撤销为无锁状态或升级为轻量级/重量级锁。

想一想,如果说运行时的场景本身存在多线程竞争的,那偏向锁的存在不仅不能提高性能,而且会导致性能下降,那么有没有一种方法可以改变这种情况呢?JVM替我们想到了这个问题的解决方案 —— 引入了批量重偏向/撤销的机制。

  • 批量重偏向

一个线程创建了大量对象并执行了初始的同步操作,之后在另一个线程中将这些对象作为锁进行之后的操作。

举个例子:在不存在锁竞争的条件下,如果同一个类有50个对象偏向线程t1,而线程t2又分别对这50个对象进行循环加锁,此时t2加锁的前19个对象会膨胀为轻量锁,等到第20个对象时,JVM会预测这个类后面的所有对象都要偏向t2,所以再加锁时,就不会执行锁膨胀了,而是重偏向到线程t2

具体实现

以class为单位,为每个class维护一个偏向锁撤销计数器,每一次该class的对象发生偏向撤销操作时,该计数器+1,当这个值达到重偏向阈值(默认20)时,JVM就认为该class的偏向锁有问题,因此会进行批量重偏向。每个class对象会有一个对应的epoch字段,每个处于偏向锁状态对象的mark word中也有该字段,其初始值为创建该对象时,class中的epoch的值。每次发生批量重偏向时,就将该值+1,同时遍历JVM中所有线程的栈,找到该class所有正处于加锁状态的偏向锁,将其epoch字段改为新值。下次获得锁时,发现当前对象的epoch值和class的epoch不相等,那就算当前已经偏向了其他线程,也不会执行撤销操作,而是直接通过CAS操作将其mark word的Thread Id 改成当前线程Id。

  • 批量撤销(批量撤销偏向锁)

存在明显多线程竞争的场景下使用偏向锁是不合适的,例如生产者/消费者队列。

举个例子:

  • 假设有80个A类的对象实例,开始时全部偏向线程t1,然后t2线程对第1-40个对象又进行了加锁处理

    • 此时根据批量重定向机制,1-19个对象先是会膨胀为轻量级锁,退出同步块后变为无锁;

    • 而第20-40个对象会因为触发批量重定向,锁状态变为偏向t2线程的偏向锁。

    • 这时t3线程来了,它对第21-43个对象进行加锁处理(注意t3线程的前20个对象不能跟t2线程的前20个对象重合),这时由于t2线程撤销偏向锁撤销了19次(JVM会按20次计算),t3线程撤销偏向锁撤销了19次(JVM会按20次计算),总共撤销的次数达到了40的阈值

      此时JVM会判定为这个A类的对象有问题(不断的切换偏向线程会降低执行效率),从第21-43,都会变为轻量级锁,不再进行重偏向操作,而且会对这个A类的对象关闭偏向的设置,即往后再newA类的对象时,不会进入偏向锁状态,只能走无锁 - 轻量级锁 - 重量级锁的膨胀过程。所以批量撤销全称应该为:批量撤销偏向锁

img

一言蔽之:当达到重偏向阈值(20)后,若class计数器还在继续增长,那么其达到批量撤销的阈值后(默认40),JVM认为该class的使用场景是存在多线程竞争的,就标记该class为不可偏向,之后,对于该class的锁,直接走轻量级锁的逻辑。

轻量级锁

  • 背景

JVM的开发者发现在很多情况下,在Java程序运行时,同步块中的代码都是不存在竞争的,即不同的线程交替的执行同步块中的代码。我们应该减少传统的重量级锁带来的性能消耗(重量级锁使用操作系统互斥量去实现同步)。

当关闭偏向锁功能或者多个线程竞争偏向锁将会导致偏向锁升级为轻量级锁

  • Lock Record

线程在执行同步块之前,JVM会先在当前的线程的栈帧中创建一个Lock Record,其包括一个用于存储对象头中的 mark word(官方称之为Displaced Mark Word)以及一个指向对象的指针。下图右边的部分就是一个Lock Record

image-20210428201217469

  • 加锁过程

下列代码中:有2个方法同步代码块,利用同一个对象加锁

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
static final Object obj = new Object();

public static void method1() {
synchronized ( obj ) {
//同步块A
method2();
}

}

public static void method2() {
synchronized (obj) {
//do something...
}
}
  1. 创建锁记录(Lock Record)对象,每个线程的栈帧都会包含一个锁记录对象,内部可以存储锁定对象的mark word(不再一开始就使用Monitor)

    image-20210428203105992

  2. 执行到synchronized ( obj )

    1. 锁记录(Lock Record)中的Object reference指向锁对象(Object)
    2. JVM利用CAS去操作尝试用Displaced Mark Word去替换对象头中的Mark Word如果成功了,就表示竞争到锁了,标志位从01更新为00(表示此对象处于轻量级锁状态)

    image-20210428203519196

    下图为CAS替换成功后的状态,对象头中存储了锁记录地址和状态 00,表示由该线程给对象加锁

    image-20210428204323729

  3. 假如CAS替换失败,则表示两种情况

    1. 若是其他线程已经持有了该Object的轻量级锁,就代表着有竞争,下面就进入锁膨胀过程

    2. 若是自己执行了Synchronized锁重入,就设置Lock Record第一部分(Displaced Mark Word)为null,起到了一个重入计数器的作用(即添加一条Lock Record作为重入的计数)

      image-20210428204857790

    此时,将会发生锁膨胀(轻量级锁 升级为 重量级锁)

  • 解锁过程
  1. 首先.遍历线程栈,找到所有obj字段等于当前锁对象的Lock Record

  2. 如果Lock RecordDisplaced Mark Word为null,代表这是一次重入,就重置锁记录(将obj设置为null),表示重入计数 -1

    image-20210428205823619

  3. 如果Lock RecordDisplaced Mark Word不为null,则利用CAS指令将对象头mark word恢复成为Displaced Mark Word

    (这里也可以解释,为什么获得锁时,我们将Lock Record中的Displaced Mark Word与对象头中的Mark Word进行交换操作了,在解锁的时候可以还原状态嘛)

    1. 如果成功,则表示解锁成功
    2. 如果失败,说明轻量级锁进行锁膨胀/已经升级为重量级锁,就不能按照轻量级锁去办事,下面就会进入重量级锁解锁过程
  • 轻量级锁的获取和释放过程

image-20210429180918744

锁膨胀

在上述轻量级锁的获取步骤中,我们提及了一个锁膨胀的概念,其发生在其他线程为相同对象加上了轻量级锁,这个时候就需要进行锁膨胀了,即将轻量级锁升级为重量级锁

重量级锁是依赖对象内部的monitor锁来实现的,而monitor又依赖操作系统的MutexLock(互斥锁)来实现的,所以重量级锁也被成为互斥锁。

而最为我们所熟知的重量级锁就是Synchronized了

  • 引入

如下图所示,T1想要对对象进行轻量级加锁时,发现T0先它一步,已经给该对象加上了轻量级锁(发现后两位是00)

image-20210428211813089

  • 锁膨胀过程

以上述情况为例

获取锁

  1. 为Objcet对象申请Monitor锁(最后两位改成10),让Object指向重量级锁的地址

  2. 接着T1线程进入Monitor的*EnrtyList *发生阻塞

    image-20210428212641730

释放锁

当T0退出同步块进行解锁的时候,会使用CASDisplaced Mark Word的值还原给对象头,但这一步能成功吗?不能,因为此时对象的后两位是10,是重量级锁。之前轻量级锁那一套在这里不管用了,接下来就会进入重量级锁的解锁流程

  1. 首先按照Monitor的地址找到Monitor对象
  2. 设置Owner为Null
  3. 唤醒EnrtyList中阻塞的线程

自旋锁

  • 引入

由于线程的阻塞和唤醒需要CPU从用户态转为核心态,频繁的阻塞和唤醒对CPU来说是一件负担很重的工作,势必会给系统的并发性能带来很大的压力。而同时我们发现在许多应用上面,对象锁的锁状态只会持续很短一段时间,为了这一段很短的时间频繁地阻塞和唤醒线程是非常不值得的——因此我们引入了自旋锁

  • 概述

所谓自旋锁,就是让该线程等待一段时间,不会被立即挂起,看持有锁的线程是否会很快释放锁。怎么等待呢?执行一段无意义的循环即可(自旋)。

使用场景:当重量级锁竞争的时候可以使用自旋进行优化处理,如果当前线程自旋成功了(即这时候持锁的线程已经退出了同步块,释放了锁 ),这个时候当前的线程就可以避免阻塞,减少CPU切换,提高系统并发性。

  • 自旋成功情况

image-20210429154732197

  • 自旋失败情况

image-20210429154840307

  • 注意点

自旋等待不能替代阻塞。虽然它可以避免线程切换带来的开销,但是它占用了处理器的时间。如果持有锁的线程很快就释放了锁,那么自旋的效率就非常好,反之,自旋的线程就会白白消耗掉处理的资源,它不会做任何有意义的工作。(占有处理器,却不做任何事)。这会带来性能上的浪费。

因此,自旋不能无限自旋,自旋的次数必须要有一个限度,如果自旋超过了定义的时间仍然没有获取到锁,则应该被挂起。

自旋是会占用处理机的时间的,自旋的思想是先等待一下,让执行同步块的线程跑一下,看看自旋后的线程能不能过会能不能用上处理机,因此单核CPU使用自旋有意义吗?没有。因此单核CPU自旋就是浪费,只有多核CPU自旋才能够发挥优势

自旋锁在JDK 1.4.2中引入,默认关闭,但是可以使用-XX:+UseSpinning开开启,在JDK1.6中默认开启。同时自旋的默认次数为10次,可以通过参数-XX:PreBlockSpin来调整

适应自旋锁

  • 引入

在学习自旋锁相关知识时,我们发现:如果通过参数-XX:preBlockSpin来调整自旋锁的自旋次数,会带来诸多不便。假如我将参数调整为10,但是系统很多线程都是等你刚刚退出的时候就释放了锁(假如你多自旋一两次就可以获取锁),这种情况就显得我们很蠢。

于是JDK1.6引入自适应的自旋锁,让虚拟机会变得越来越聪明。

  • 概述

所谓自适应就意味着自旋的次数不再是固定的,它是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。它怎么做呢?线程如果自旋成功了,那么下次自旋的次数会更加多,因为虚拟机认为既然上次成功了,那么此次自旋也很有可能会再次成功,那么它就会允许自旋等待持续的次数更多。反之,如果对于某个锁,很少有自旋能够成功的,那么在以后要或者这个锁的时候自旋的次数会减少甚至省略掉自旋过程,以免浪费处理器资源。
有了自适应自旋锁,随着程序运行和性能监控信息的不断完善,虚拟机对程序锁的状况预测会越来越准确,虚拟机会变得越来越聪明。

锁转换流程图

img

锁消除

  • 概述

为了保证数据的完整性,我们在进行操作时需要对这部分操作进行同步控制,但是在有些情况下,JVM检测到不可能存在共享数据竞争,这是JVM会对这些同步锁进行锁消除;

  • 依据

锁消除的依据是逃逸分析的数据支持。这也是jvm的语法糖的一种,是编译器的一种优化措施。

锁消除可以节省毫无意义的请求锁的时间。变量是否逃逸,对于虚拟机来说需要使用数据流分析来确定。

  • 例子

有时候,我们虽然没有显示使用锁,但是我们在使用一些JDK的内置API时,如StringBuffer、Vector、HashTable等,这个时候会存在隐形的加锁操作。比如StringBuffer的append()方法,Vector的add()方法:

1
2
3
4
5
6
7
8
public void vectorTest(){
Vector<String> vector = new Vector<String>();
for(int i = 0 ; i < 10 ; i++){
vector.add(i + "");
}

System.out.println(vector);
}

在运行这段代码时,JVM可以明显检测到变量vector没有逃逸出方法vectorTest()之外,所以JVM可以大胆地将vector内部的加锁操作消除。

锁粗化

  • 概述

我们知道在使用同步锁的时候,需要让同步块的作用范围尽可能小,即仅在共享数据的实际作用域中才进行同步,这样做的目的是为了使需要同步的操作数量尽可能缩小,如果存在锁竞争,那么等待锁的线程也能尽快拿到锁。

大部分情况下,这些都是正确的。但是,如果一些列的联系操作都是同一个对象反复加上和解锁,甚至加锁操作是出现在循环体中的,那么即使没有线程竞争,频繁地进行互斥同步操作也导致不必要的性能损耗。

  • 例子

类似锁消除的concatString()方法。如果StringBuffer sb = new StringBuffer();定义在方法体之外,那么就会有线程竞争,但是每个append()操作都对同一个对象反复加锁解锁,那么虚拟机探测到有这样的情况的话,会把加锁同步的范围扩展到整个操作序列的外部,即扩展到【第一个append()操作之前和最后一个append()操作之后】,这样的一个锁范围扩展的操作就称之为锁粗化

用上述的锁消除的代码为例的话:

JVM检测到对同一个对象(vector)连续加锁、解锁操作,会合并一个更大范围的加锁、解锁操作,即加锁解锁操作会移到for循环之外。

  • 总结

将多个连续的加锁、解锁操作连接在一起,扩展成一个范围更大的锁

final

final基础

final基础在java基础部分有学习过:https://uesugier11.gitee.io/uesugi-er11/2020/11/14/Java%E5%9F%BA%E7%A1%80/#final

多线程中的final

final域重排序规则

final域为基本类型

先看一段示例性的代码:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public class FinalDemo {
private int a; //普通域
private final int b; //final域
private static FinalDemo finalDemo;

public FinalDemo() {
a = 1; // 1. 写普通域
b = 2; // 2. 写final域
}

public static void writer() {
finalDemo = new FinalDemo();
}

public static void reader() {
FinalDemo demo = finalDemo; // 3.读对象引用
int a = demo.a; //4.读普通域
int b = demo.b; //5.读final域
}
}

假设线程A在执行writer()方法,线程B执行reader()方法。

写final域重排序规则

写final域的重排序规则禁止对final域的写重排序到构造函数之外,这个规则的实现主要包含了两个方面:

  1. JMM禁止编译器把final域的写重排序到构造函数之外;
  2. 编译器会在final域写之后,构造函数return之前,插入一个storestore屏障(关于内存屏障可以看这篇文章)。这个屏障可以禁止处理器把final域的写重排序到构造函数之外。

我们再来分析writer方法,虽然只有一行代码,但实际上做了两件事情:

  1. 构造了一个FinalDemo对象;
  2. 把这个对象赋值给成员变量finalDemo。

我们来画下存在的一种可能执行时序图,如下:

final域写可能的存在的执行时序

由于a,b之间没有数据依赖性,普通域(普通变量)a可能会被重排序到构造函数之外,线程B就有可能读到的是普通变量a初始化之前的值(零值),这样就可能出现错误。而final域变量b,根据重排序规则,会禁止final修饰的变量b重排序到构造函数之外,从而b能够正确赋值,线程B就能够读到final变量初始化后的值。

因此,写final域的重排序规则可以确保:在对象引用为任意线程可见之前,对象的final域已经被正确初始化过了,而普通域就不具有这个保障。比如在上例,线程B有可能就是一个未正确初始化的对象finalDemo。

读final域重排序规则

读final域重排序规则为:在一个线程中,初次读对象引用和初次读该对象包含的final域,JMM会禁止这两个操作的重排序。(注意,这个规则仅仅是针对处理器),处理器会在读final域操作的前面插入一个LoadLoad屏障。实际上,读对象的引用和读该对象的final域存在间接依赖性,一般处理器不会重排序这两个操作。但是有一些处理器会重排序,因此,这条禁止重排序规则就是针对这些处理器而设定的。

read()方法主要包含了三个操作:

  1. 初次读引用变量finalDemo;
  2. 初次读引用变量finalDemo的普通域a;
  3. 初次读引用变量finalDemo的final域b;

假设线程A写过程没有重排序,那么线程A和线程B有一种的可能执行时序为下图:

final域读可能存在的执行时序

读对象的普通域被重排序到了读对象引用的前面就会出现线程B还未读到对象引用就在读取该对象的普通域变量,这显然是错误的操作。而final域的读操作就“限定”了在读final域变量前已经读到了该对象的引用,从而就可以避免这种情况。

读final域的重排序规则可以确保:在读一个对象的final域之前,一定会先读这个包含这个final域的对象的引用。

final域为引用类型

我们已经知道了final域是基本数据类型的时候重排序规则是怎么的了?如果是引用数据类型呢?我们接着继续来探讨。

对final修饰的对象的成员域写操作

针对引用数据类型,final域写针对编译器和处理器重排序增加了这样的约束:在构造函数内对一个final修饰的对象的成员域的写入,与随后在构造函数之外把这个被构造的对象的引用赋给一个引用变量,这两个操作是不能被重排序的。注意这里的是“增加”也就说前面对final基本数据类型的重排序规则在这里还是使用。这句话是比较拗口的,下面结合实例来看。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
public class FinalReferenceDemo {
final int[] arrays;
private FinalReferenceDemo finalReferenceDemo;

public FinalReferenceDemo() {
arrays = new int[1]; //1
arrays[0] = 1; //2
}

public void writerOne() {
finalReferenceDemo = new FinalReferenceDemo(); //3
}

public void writerTwo() {
arrays[0] = 2; //4
}

public void reader() {
if (finalReferenceDemo != null) { //5
int temp = finalReferenceDemo.arrays[0]; //6
}
}
}

针对上面的实例程序,线程线程A执行wirterOne方法,执行完后线程B执行writerTwo方法,然后线程C执行reader方法。下图就以这种执行时序出现的一种情况来讨论(耐心看完才有收获)。

写final修饰引用类型数据可能的执行时序

由于对final域的写禁止重排序到构造方法外,因此1和3不能被重排序。由于一个final域的引用对象的成员域写入不能与随后将这个被构造出来的对象赋给引用变量重排序,因此2和3不能重排序。

对final修饰的对象的成员域读操作

JMM可以确保线程C至少能看到写线程A对final引用的对象的成员域的写入,即能看下arrays[0] = 1,而写线程B对数组元素的写入可能看到可能看不到。JMM不保证线程B的写入对线程C可见,线程B和线程C之间存在数据竞争,此时的结果是不可预知的。如果可见的,可使用锁或者volatile。

关于final重排序的总结

按照final修饰的数据类型分类:

基本数据类型:

  1. final域写:禁止final域写构造方法重排序,即禁止final域写重排序到构造方法之外,从而保证该对象对所有线程可见时,该对象的final域全部已经初始化过。
  2. final域读:禁止初次读对象的引用读该对象包含的final域的重排序。

引用数据类型:

额外增加约束:禁止在构造函数对一个final修饰的对象的成员域的写入与随后将这个被构造的对象的引用赋值给引用变量 重排序

final实现原理

上面我们提到过,写final域会要求编译器在final域写之后,构造函数返回前插入一个StoreStore屏障。读final域的重排序规则会要求编译器在读final域的操作前插入一个LoadLoad屏障。

很有意思的是,如果以X86处理为例,X86不会对写-写重排序,所以StoreStore屏障可以省略。由于不会对有间接依赖性的操作重排序,所以在X86处理器中,读final域需要的LoadLoad屏障也会被省略掉。也就是说,以X86为例的话,对final域的读/写的内存屏障都会被省略!具体是否插入还是得看是什么处理器

为什么final引用不能从构造函数中 “逸出”

这里还有一个比较有意思的问题:上面对final域写重排序规则可以确保我们在使用一个对象引用的时候该对象的final域已经在构造函数被初始化过了。但是这里其实是有一个前提条件的,也就是:在构造函数,不能让这个被构造的对象被其他线程可见,也就是说该对象引用不能在构造函数中“逸出”。以下面的例子来说:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public class FinalReferenceEscapeDemo {
private final int a;
private FinalReferenceEscapeDemo referenceDemo;

public FinalReferenceEscapeDemo() {
a = 1; //1
referenceDemo = this; //2
}

public void writer() {
new FinalReferenceEscapeDemo();
}

public void reader() {
if (referenceDemo != null) { //3
int temp = referenceDemo.a; //4
}
}
}

可能的执行时序如图所示:

final域引用可能的执行时序

假设一个线程A执行writer方法另一个线程执行reader方法。因为构造函数中操作1和2之间没有数据依赖性,1和2可以重排序,先执行了2,这个时候引用对象referenceDemo是个没有完全初始化的对象,而当线程B去读取该对象时就会出错。尽管依然满足了final域写重排序规则:在引用对象对所有线程可见时,其final域已经完全初始化成功。但是,引用对象“this”逸出,该代码依然存在线程安全的问题。

Lock体系

cocurrent包结构层次

在针对并发编程中,Doug Lea大师为我们提供了大量实用,高性能的工具类,针对这些代码进行研究会让我们队并发编程的掌握更加透彻也会大大提升我们队并发编程技术的热爱。这些代码在java.util.concurrent包下。如下图,即为concurrent包的目录结构图。

concurrent目录结构.png

其中包含了两个子包:atomic以及lock,另外在concurrent下的阻塞队列以及executors,这些就是concurrent包中的精华,之后会一一进行学习。而这些类的实现主要是依赖于volatile以及CAS,从整体上来看concurrent包的整体实现图如下图所示:

concurrent包实现整体示意图.png

Lock简介

我们下来看concurent包下的lock子包。锁是用来控制多个线程访问共享资源的方式,一般来说,一个锁能够防止多个线程同时访问共享资源。

在Lock接口出现之前,java程序主要是靠synchronized关键字实现锁功能的,而java SE5之后,并发包中增加了lock接口,它提供了与synchronized一样的锁功能。

虽然它失去了像synchronize关键字隐式加锁解锁的便捷性,但是却拥有了锁获取和释放的可操作性,可中断的获取锁以及超时获取锁等多种synchronized关键字所不具备的同步特性。通常使用显示使用lock的形式如下:

1
2
3
4
5
6
7
Lock lock = new ReentrantLock();
lock.lock();
try{
.......
}finally{
lock.unlock();
}

需要注意的是synchronized同步块执行完成或者遇到异常是锁会自动释放,而lock必须调用unlock()方法释放锁,因此在finally块中释放锁

Lock接口API

我们现在就来看看lock接口定义了哪些方法:

void lock(); //获取锁
void lockInterruptibly() throws InterruptedException;//获取锁的过程能够响应中断
boolean tryLock();//非阻塞式响应中断能立即返回,获取锁放回true反之返回fasle
boolean tryLock(long time, TimeUnit unit) throws InterruptedException;//超时获取锁,在超时内或者未中断的情况下能够获取锁
Condition newCondition();//获取与lock绑定的等待通知组件,当前线程必须获得了锁才能进行等待,进行等待时会先释放锁,当再次获取锁时才能从等待中返回

上面是lock接口下的五个方法,也只是从源码中英译中翻译了一遍,感兴趣的可以自己的去看看。那么在locks包下有哪些类实现了该接口了?先从最熟悉的ReentrantLock说起。

public class ReentrantLock implements Lock, java.io.Serializable

很显然ReentrantLock实现了lock接口,接下来我们来仔细研究一下它是怎样实现的。

当你查看源码时你会惊讶的发现ReentrantLock并没有多少代码,另外有一个很明显的特点是:基本上所有的方法的实现实际上都是调用了其静态内存类Sync中的方法,而Sync类继承了AbstractQueuedSynchronizer(AQS)

可以看出要想理解ReentrantLock关键核心在于对队列同步器AbstractQueuedSynchronizer(简称同步器)的理解。

AbstractQueuedSynchronizer(AQS)

简介

  • AQS - 抽象 队列 同步器;简称同步器

关于AQS在源码中有十分具体的解释:

Provides a framework for implementing blocking locks and related
synchronizers (semaphores, events, etc) that rely on
first-in-first-out (FIFO) wait queues.  This class is designed to
be a useful basis for most kinds of synchronizers that rely on a
single atomic {@code int} value to represent state. Subclasses
must define the protected methods that change this state, and which
define what that state means in terms of this object being acquired
or released.  Given these, the other methods in this class carry
out all queuing and blocking mechanics. Subclasses can maintain
other state fields, but only the atomically updated {@code int}
value manipulated using methods {@link #getState}, {@link
#setState} and {@link #compareAndSetState} is tracked with respect
to synchronization.

<p>Subclasses should be defined as non-public internal helper
classes that are used to implement the synchronization properties
of their enclosing class.  Class
{@code AbstractQueuedSynchronizer} does not implement any
synchronization interface.  Instead it defines methods such as
{@link #acquireInterruptibly} that can be invoked as
appropriate by concrete locks and related synchronizers to
implement their public methods.

同步器是用来构建锁和其他同步组件的基础框架

  • 它的实现方式(同步状态 + 等待队列)
    • 依赖一个int成员变量来表示同步状态
    • 再通过一个FIFO队列构成等待队列

它的子类必须重写AQS的几个protected修饰的用来改变同步状态的方法,其他方法主要是实现了排队和阻塞机制。

状态的更新使用getState,setState以及compareAndSetState(也就是我们常说的CAS)这三个方法

子类被推荐定义为自定义同步组件的静态内部类,同步器自身没有实现任何同步接口,它仅仅是定义了若干同步状态的获取和释放方法来供自定义同步组件的使用,同步器既支持独占式获取同步状态,也可以支持共享式获取同步状态,这样就可以方便的实现不同类型的同步组件。

同步器是实现锁(也可以是任意同步组件)的关键,在锁的实现中聚合同步器,利用同步器实现锁的语义。

  • 理解二者的关系

锁是面向【使用者】,它定义了使用者与锁交互的接口,隐藏了实现细节;同步器是面向锁的【实现者】,它简化了锁的实现方式,屏蔽了同步状态的管理,线程的排队,等待和唤醒等底层操作。锁和同步器很好的隔离了使用者和实现者所需关注的领域。

AQS模板方法设计模式

  • AQS的设计是使用【模板方法设计模式】,它将一些方法开放给子类进行重写,而同步器给同步组件所提供模板方法又会重新调用被子类所重写的方法

举个例子,AQS中需要重写的方法tryAcquire:

1
2
3
protected boolean tryAcquire(int arg) {
throw new UnsupportedOperationException();
}

ReentrantLock中NonfairSync(继承AQS,本质是一个锁)会重写该方法为:

1
2
3
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}

而AQS中的模板方法acquire():

1
2
3
4
5
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}

会调用tryAcquire方法,而此时当继承AQS的NonfairSync调用模板方法acquire时就会调用已经被NonfairSync重写的tryAcquire方法。这就是使用AQS的方式,在弄懂这点后会lock的实现理解有很大的提升。

  • 总结

可以归纳总结为这么几点:

  1. 同步组件(这里不仅仅指锁,还包括CountDownLatch等)的实现依赖于同步器AQS,在同步组件实现中,使用AQS的方式被推荐定义继承AQS的静态内存类;
  2. AQS采用模板方法进行设计,AQS的protected修饰的方法需要由继承AQS的子类进行重写实现,当调用AQS的子类的方法时就会调用被重写的方法;
  3. AQS负责同步状态的管理,线程的排队,等待和唤醒这些底层操作,而Lock等同步组件主要专注于实现同步语义;
  4. 在重写AQS的方式时,使用AQS提供的getState(),setState(),compareAndSetState()方法进行修改同步状态

AQS可重写的方法如下图(摘自《java并发编程的艺术》一书):

AQS可重写的方法.png

在实现同步组件时AQS提供的模板方法如下图:

AQS提供的模板方法.png

AQS提供的模板方法可以分为3类:

  1. 独占式获取与释放同步状态;
  2. 共享式获取与释放同步状态;
  3. 查询同步队列中等待线程情况;

同步组件通过AQS提供的模板方法实现自己的同步语义。

AQS底层细节

AQS模板方法

在同步组件的实现中,AQS是核心部分,同步组件的实现者通过使用AQS提供的模板方法实现同步组件语义,AQS则实现了对同步状态的管理,以及对阻塞线程进行排队,等待通知等等一些底层的实现处理。

AQS的核心也包括了这些方面:同步队列,独占式锁的获取和释放,共享锁的获取和释放以及可中断锁,超时等待锁获取这些特性的实现,而这些实际上则是AQS提供出来的模板方法,归纳整理如下:

独占式锁:

void acquire(int arg):独占式获取同步状态,如果获取失败则插入同步队列进行等待;
void acquireInterruptibly(int arg):与acquire方法相同,但在同步队列中进行等待的时候可以检测中断;
boolean tryAcquireNanos(int arg, long nanosTimeout):在acquireInterruptibly基础上增加了超时等待功能,在超时时间内没有获得同步状态返回false;
boolean release(int arg):释放同步状态,该方法会唤醒在同步队列中的下一个节点

共享式锁:

void acquireShared(int arg):共享式获取同步状态,与独占式的区别在于同一时刻有多个线程获取同步状态;
void acquireSharedInterruptibly(int arg):在acquireShared方法基础上增加了能响应中断的功能;
boolean tryAcquireSharedNanos(int arg, long nanosTimeout):在acquireSharedInterruptibly基础上增加了超时等待的功能;
boolean releaseShared(int arg):共享式释放同步状态

要想掌握AQS的底层实现,其实也就是对这些模板方法的逻辑进行学习。在学习这些模板方法之前,我们得首先了解下AQS中的同步队列是一种什么样的数据结构,因为同步队列是AQS对同步状态的管理的基石。

同步队列

当共享资源被某个线程占有,其他请求该资源的线程将会阻塞,从而进入同步队列。

就数据结构而言,队列的实现方式无外乎两者一是通过数组的形式,另外一种则是链表的形式。AQS中的同步队列则是通过链式方式进行实现。接下来,很显然我们至少会抱有这样的疑问:

  1. 节点的数据结构是什么样的?
  2. 是单向还是双向?
  3. 是带头结点的还是不带头节点的?
  • Node类 属性

在AQS有一个静态内部类Node,其中有这样一些属性:

volatile int waitStatus //节点状态
volatile Node prev //当前节点/线程的前驱节点
volatile Node next; //当前节点/线程的后继节点
volatile Thread thread;//加入同步队列的线程引用
Node nextWaiter;//等待队列中的下一个节点

  • 节点状态

节点的状态有以下这些:

int CANCELLED = 1//节点从同步队列中取消
int SIGNAL = -1//后继节点的线程处于等待状态,如果当前节点释放同步状态会通知后继节点,使得后继节点的线程能够运行;
int CONDITION = -2//当前节点进入等待队列中
int PROPAGATE = -3//表示下一次共享式同步状态获取将会无条件传播下去
int INITIAL = 0;//初始状态

现在我们知道了节点的数据结构类型,并且每个节点拥有其前驱和后继节点,很显然这是一个双向队列

同样的我们可以用一段demo看一下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
public class LockDemo {
private static ReentrantLock lock = new ReentrantLock();

public static void main(String[] args) {
for (int i = 0; i < 5; i++) {
Thread thread = new Thread(() -> {
//调用lock方法
lock.lock();
try {
Thread.sleep(10000);
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
//别忘了解锁
lock.unlock();
}
});
thread.start();
}
}
}

实例代码中开启了5个线程,先获取锁之后再睡眠10S中,实际上这里让线程睡眠是想模拟出当线程无法获取锁时进入同步队列的情况。

通过debug,当Thread-4(在本例中最后一个线程)获取锁失败后进入同步时,AQS时现在的同步队列如图所示:

LockDemo debug下 .png

Thread-0先获得锁后进行睡眠,其他线程(Thread-1,Thread-2,Thread-3,Thread-4)获取锁失败进入同步队列,同时也可以很清楚的看出来每个节点有两个域:prev(前驱)和next(后继),并且每个节点用来保存获取同步状态失败的线程引用以及等待状态等信息。

另外AQS中有两个重要的成员变量:

1
2
3
4
//头指针
private transient volatile Node head;
//尾指针
private transient volatile Node tail;

也就是说AQS实际上通过头尾指针来管理同步队列,同时实现包括获取锁失败的线程进行入队,释放锁时对同步队列中的线程进行通知等核心方法。其示意图如下:

队列示意图.png

通过对源码的理解以及做实验的方式,现在我们可以清楚的知道这样几点:

  1. 节点的数据结构,即AQS的静态内部类Node,节点的等待状态等信息
  2. 同步队列是一个双向队列,AQS通过持有头尾指针管理同步队列

那么,节点如何进行入队和出队是怎样做的了?实际上这对应着锁的获取和释放两个操作:获取锁失败进行入队操作,获取锁成功进行出队操作。

独占锁

独占锁的获取

在上面的demo中我们使用了Lock.lock()上了锁,其本质是获取独占锁,获取失败就将当前线程加入同步队列,成功则线程执行

lock()方法实际上会调用AQS的acquire()方法

1
2
3
4
5
6
7
public final void acquire(int arg) {
//先看同步状态是否获取成功,如果成功则方法结束返回
//若失败则先调用addWaiter()方法再调用acquireQueued()方法
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}

acquire根据当前获得同步状态成功与否做了两件事情:

  1. 成功,则方法结束返回
  2. 失败,则先调用addWaiter()然后在调用acquireQueued()方法。

获取同步状态失败,入队操作

当线程获取独占式锁失败后就会将当前线程加入同步队列,那么加入队列的方式是怎样的了?

我们接下来就应该去研究一下addWaiter()和acquireQueued()。addWaiter()源码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
private Node addWaiter(Node mode) {
// 1. 将当前线程构建成Node类型
Node node = new Node(Thread.currentThread(), mode);
// Try the fast path of enq; backup to full enq on failure
// 2. 当前尾节点是否为null?
Node pred = tail;
if (pred != null) {
// 2.2 将当前节点尾插入的方式插入同步队列中
node.prev = pred;
if (compareAndSetTail(pred, node)) {
pred.next = node;
return node;
}
}
// 2.1. 当前同步队列尾节点为null,说明当前线程是第一个加入同步队列进行等待的线程
enq(node);
return node;
}

分析可以看上面的注释。程序的逻辑主要分为两个部分:

1. 当前同步队列的尾节点为null,调用方法enq()插入;

2. 当前队列的尾节点不为null,则采用尾插入(compareAndSetTail()方法)的方式入队。

另外还会有另外一个问题:如果 if (compareAndSetTail(pred, node))为false怎么办?会继续执行到enq()方法,同时很明显compareAndSetTail是一个CAS操作,通常来说如果CAS操作失败会继续自旋(死循环)进行重试。

因此,经过我们这样的分析,enq()方法可能承担两个任务:

  1. 处理当前同步队列尾节点为null时进行入队操作;
  2. 如果CAS尾插入节点失败后负责自旋进行尝试。
  • enq()源码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
private Node enq(final Node node) {
for (;;) {
Node t = tail;
if (t == null) { // Must initialize
//1. 构造头结点
if (compareAndSetHead(new Node()))
tail = head;
} else {
// 2. 尾插入,CAS操作失败自旋尝试
node.prev = t;
if (compareAndSetTail(t, node)) {
t.next = node;
return t;
}
}
}
}

在上面的分析中我们可以看出在第1步中会先创建头结点,说明同步队列是带头结点的链式存储结构

  • 带头结点与不带头结点区别

带头结点与不带头结点相比,会在入队和出队的操作中获得更大的便捷性,因此同步队列选择了带头结点的链式存储结构。

  • 队列初始化时机

那么带头节点的队列初始化时机是什么?自然而然是在tail为null时,即当前线程是第一次插入同步队列。compareAndSetTail(t, node)方法会利用CAS操作设置尾节点,如果CAS操作失败会在for (;;)for死循环中不断尝试,直至成功return返回为止。

  • enq方法总结

因此,对enq()方法可以做这样的总结:

  1. 在当前线程是第一个加入同步队列时,调用compareAndSetHead(new Node())方法,完成链式队列的头结点的初始化
  2. 自旋不断尝试CAS尾插入节点直至成功为止

现在我们已经很清楚获取独占式锁失败的线程包装成Node然后插入同步队列的过程了。

那么紧接着会有下一个问题 —— 在同步队列中的节点(线程)会做什么事情了来保证自己能够有机会获得独占式锁呢?

带着这样的问题我们就来看看acquireQueued()方法,从方法名就可以很清楚,这个方法的作用就是排队获取锁的过程,源码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
final boolean acquireQueued(final Node node, int arg) {
boolean failed = true;
try {
boolean interrupted = false;
for (;;) {
// 1. 获得当前节点的先驱节点
final Node p = node.predecessor();
// 2. 当前节点能否获取独占式锁
// 2.1 如果当前节点的先驱节点是头结点并且成功获取同步状态,即可以获得独占式锁
if (p == head && tryAcquire(arg)) {
//队列头指针用指向当前节点
setHead(node);
//释放前驱节点
p.next = null; // help GC
failed = false;
return interrupted;
}
// 2.2 获取锁失败,线程进入等待状态等待获取独占式锁
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
cancelAcquire(node);
}
}

程序逻辑通过注释已经标出,整体来看这是一个这又是一个自旋的过程(for (;;)),代码首先获取当前节点的先驱节点,如果先驱节点是头结点的并且成功获得同步状态的时候(if (p == head && tryAcquire(arg))),当前节点所指向的线程能够获取锁

反之,获取锁失败进入等待状态。整体示意图为下图:

自旋获取锁整体示意图.png

获取锁成功,出队操作

获取锁的节点出队的逻辑是:

1
2
3
4
5
6
//队列头结点引用指向当前节点
setHead(node);
//释放前驱节点
p.next = null; // help GC
failed = false;
return interrupted;

setHead()方法为:

1
2
3
4
5
private void setHead(Node node) {
head = node;
node.thread = null;
node.prev = null;
}

将当前节点通过setHead()方法设置为队列的头结点,然后将之前的头结点的next域设置为null并且pre域也为null,即与队列断开,无任何引用,这样做方便GC时能够将内存进行回收。示意图如下:

当前节点引用线程获取锁,当前节点设置为队列头结点.png

那么当获取锁失败的时候会调用shouldParkAfterFailedAcquire()方法和parkAndCheckInterrupt()方法,看看他们做了什么事情。

shouldParkAfterFailedAcquire()方法源码为:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
int ws = pred.waitStatus;
if (ws == Node.SIGNAL)
/*
* This node has already set status asking a release
* to signal it, so it can safely park.
*/
return true;
if (ws > 0) {
/*
* Predecessor was cancelled. Skip over predecessors and
* indicate retry.
*/
do {
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);
pred.next = node;
} else {
/*
* waitStatus must be 0 or PROPAGATE. Indicate that we
* need a signal, but don't park yet. Caller will need to
* retry to make sure it cannot acquire before parking.
*/
compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
}
return false;
}
  • 方法逻辑

shouldParkAfterFailedAcquire()方法主要逻辑是使用compareAndSetWaitStatus(pred, ws, Node.SIGNAL)使用CAS将节点状态由INITIAL设置成SIGNAL,表示当前线程阻塞。

当compareAndSetWaitStatus设置失败则说明shouldParkAfterFailedAcquire方法返回false,然后会在acquireQueued()方法中for (;;)死循环中会继续重试,直至compareAndSetWaitStatus设置节点状态位为SIGNAL时shouldParkAfterFailedAcquire返回true时才会执行方法parkAndCheckInterrupt()方法

该方法的源码为:

1
2
3
4
5
private final boolean parkAndCheckInterrupt() {
//使得该线程阻塞
LockSupport.park(this);
return Thread.interrupted();
}

该方法的关键是会调用LookSupport.park()方法(关于LookSupport会在以后的文章进行讨论),该方法是用来阻塞当前线程的。因此到这里就应该清楚了,acquireQueued()在自旋过程中主要完成了两件事情:

  1. 如果当前节点的前驱节点是头节点,并且能够获得同步状态的话,当前线程能够获得锁该方法执行结束退出
  2. 获取锁失败的话,先将节点状态设置成SIGNAL,然后调用LookSupport.park方法使得当前线程阻塞
  • 整体流程图

未命名文件 (1)

独占锁的释放

独占锁的释放就相对来说比较容易理解了,废话不多说先来看下源码:

1
2
3
4
5
6
7
8
9
public final boolean release(int arg) {
if (tryRelease(arg)) {
Node h = head;
if (h != null && h.waitStatus != 0)
unparkSuccessor(h);
return true;
}
return false;
}

这段代码逻辑就比较容易理解了,如果同步状态释放成功(tryRelease返回true)则会执行if块中的代码,当head指向的头结点不为null,并且该节点的状态值不为0的话才会执行unparkSuccessor()方法。

  • unparkSuccessor方法源码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
private void unparkSuccessor(Node node) {
/*
* If status is negative (i.e., possibly needing signal) try
* to clear in anticipation of signalling. It is OK if this
* fails or if status is changed by waiting thread.
*/

//获取当前节点状态
int ws = node.waitStatus;

// 如果当前节点的状态小于0,那么就用CAS去设置成0
if (ws < 0)
compareAndSetWaitStatus(node, ws, 0);

/*
* Thread to unpark is held in successor, which is normally
* just the next node. But if cancelled or apparently null,
* traverse backwards from tail to find the actual
* non-cancelled successor.
*/

//获取头节点的后继节点(也就是我们真正要去唤醒的节点)
Node s = node.next;

//如果后继结点为空 || 后继结点状态 > 0 (为取消状态) 这两种都代表着后继结点都是无效的节点
if (s == null || s.waitStatus > 0) {
s = null;

//从尾结点开始查找状态不是取消的可用节点
for (Node t = tail; t != null && t != node; t = t.prev)
if (t.waitStatus <= 0)
s = t;
}
if (s != null)
//后继节点不为null时唤醒该线程,去竞争同步锁
LockSupport.unpark(s.thread);
}

源码的关键信息请看注释,首先获取头节点的后继节点,当后继节点的时候会调用LookSupport.unpark()方法,该方法会唤醒该节点的后继节点所包装的线程。因此,每一次锁释放后就会唤醒队列中该节点的后继节点所引用的线程,从而进一步可以佐证获得锁的过程是一个FIFO(先进先出)的过程。

到现在我们终于啃下了一块硬骨头了,通过学习源码的方式非常深刻的学习到了独占式锁的获取和释放的过程以及同步队列。

  • 独占锁总结

AQS的本质是去维护一个CLH同步队列,具体细节如下:

  1. 线程获取锁失败,线程被封装成Node进行入队操作,核心方法在于addWaiter()和enq(),同时enq()完成对同步队列的头结点初始化工作以及CAS操作失败的重试;
  2. 线程获取锁是一个自旋的过程,当且仅当 当前节点的前驱节点是头结点.并且成功获得同步状态时,节点出队即该节点引用的线程获得锁,否则,当不满足条件时就会调用LookSupport.park()方法使得线程阻塞
  3. 释放锁的时候会唤醒后继节点;

总体来说:在获取同步状态时,AQS维护一个同步队列,获取同步状态失败的线程会加入到队列中进行自旋;移除队列(或停止自旋)的条件是前驱节点是头结点并且成功获得了同步状态。在释放同步状态时,同步器会调用unparkSuccessor()方法唤醒后继节点。

独占锁特性学习

可中断式获取锁(acquireInterruptibly方法)

我们知道lock相较于synchronized有一些更方便的特性,比如能响应中断以及超时等待等特性,现在我们依旧采用通过学习源码的方式来看看能够响应中断是怎么实现的。

可响应中断式锁可调用方法lock.lockInterruptibly();而该方法其底层会调用AQS的acquireInterruptibly方法

  • 源码
1
2
3
4
5
6
7
8
public final void acquireInterruptibly(int arg)
throws InterruptedException {
if (Thread.interrupted())
throw new InterruptedException();
if (!tryAcquire(arg))
//线程获取锁失败
doAcquireInterruptibly(arg);
}

在获取同步状态失败后就会调用doAcquireInterruptibly方法:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
private void doAcquireInterruptibly(int arg)
throws InterruptedException {
//将节点插入到同步队列中
final Node node = addWaiter(Node.EXCLUSIVE);
boolean failed = true;
try {
for (;;) {
final Node p = node.predecessor();
//获取锁出队
if (p == head && tryAcquire(arg)) {
setHead(node);
p.next = null; // help GC
failed = false;
return;
}
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
//线程中断抛异常
throw new InterruptedException();
}
} finally {
if (failed)
cancelAcquire(node);
}
}

关键信息请看注释,现在看这段代码就很轻松了吧:),与acquire方法逻辑几乎一致、唯一的区别是当parkAndCheckInterrupt返回true时即线程阻塞时该线程被中断,代码抛出被中断异常。

  • 流程图

image-20210519202012102

超时等待式获取锁(tryAcquireNanos()方法)

通过调用lock.tryLock(timeout,TimeUnit)方式达到超时等待获取锁的效果,该方法会在三种情况下才会返回:

  1. 在超时时间内,当前线程成功获取了锁;
  2. 当前线程在超时时间内被中断;
  3. 超时时间结束,仍未获得锁返回false。

我们仍然通过采取阅读源码的方式来学习底层具体是怎么实现的,该方法会调用AQS的方法tryAcquireNanos(),源码为:

1
2
3
4
5
6
7
8
public final boolean tryAcquireNanos(int arg, long nanosTimeout)
throws InterruptedException {
if (Thread.interrupted())
throw new InterruptedException();
return tryAcquire(arg) ||
//实现超时等待的效果
doAcquireNanos(arg, nanosTimeout);
}

很显然这段源码最终是靠doAcquireNanos方法实现超时等待的效果,该方法源码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
private boolean doAcquireNanos(int arg, long nanosTimeout)
throws InterruptedException {
if (nanosTimeout <= 0L)
return false;
//1. 根据超时时间和当前时间计算出截止时间
final long deadline = System.nanoTime() + nanosTimeout;
final Node node = addWaiter(Node.EXCLUSIVE);
boolean failed = true;
try {
for (;;) {
final Node p = node.predecessor();
//2. 当前线程获得锁出队列
if (p == head && tryAcquire(arg)) {
setHead(node);
p.next = null; // help GC
failed = false;
return true;
}
// 3.1 重新计算超时时间
nanosTimeout = deadline - System.nanoTime();
// 3.2 已经超时返回false
if (nanosTimeout <= 0L)
return false;
// 3.3 线程阻塞等待
if (shouldParkAfterFailedAcquire(p, node) &&
nanosTimeout > spinForTimeoutThreshold)
LockSupport.parkNanos(this, nanosTimeout);
// 3.4 线程被中断抛出被中断异常
if (Thread.interrupted())
throw new InterruptedException();
}
} finally {
if (failed)
cancelAcquire(node);
}
}

程序逻辑如图所示:

超时等待式获取锁(doAcquireNanos()方法)

程序逻辑同独占锁可响应中断式获取基本一致,唯一的不同在于获取锁失败后,对超时时间的处理上:

  1. 在第1步会先计算出按照现在时间和超时时间计算出理论上的截止时间,比如当前时间是8h10min,超时时间是10min,那么根据deadline = System.nanoTime() + nanosTimeout计算出刚好达到超时时间时的系统时间就是8h 10min+10min = 8h 20min。
  2. 然后根据deadline - System.nanoTime()就可以判断是否已经超时了,比如,当前系统时间是8h 30min很明显已经超过了理论上的系统时间8h 20min,deadline - System.nanoTime()计算出来就是一个负数,自然而然会在3.2步中的If判断之间返回false。
  3. 如果还没有超时即3.2步中的if判断为true时就会继续执行3.3步通过LockSupport.parkNanos使得当前线程阻塞,同时在3.4步增加了对中断的检测,若检测出被中断直接抛出被中断异常。

共享锁

共享锁的获取(acquireShared()方法)

在聊完AQS对独占锁的实现后,我们继续一鼓作气的来看看共享锁是怎样实现的?共享锁的获取方法为acquireShared,源码为:

1
2
3
4
5
public final void acquireShared(int arg) {
if (tryAcquireShared(arg) < 0)
//获取锁失败,则自旋获取同步状态
doAcquireShared(arg);
}

这段源码的逻辑很容易理解,在该方法中会首先调用tryAcquireShared方法,tryAcquireShared返回值是一个int类型,当返回值为大于等于0的时候方法结束说明获得成功获取锁,否则,表明获取同步状态失败即所引用的线程获取锁失败,会执行doAcquireShared方法,

该方法的源码为:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
private void doAcquireShared(int arg) {
// 添加共享模式节点到队列之中
final Node node = addWaiter(Node.SHARED);
boolean failed = true;
try {
boolean interrupted = false;
// 自旋获取同步状态
for (;;) {
// 当前节点的前驱结点
final Node p = node.predecessor();
// 若前驱结点为head结点
if (p == head) {
// 尝试去获取共享同步状态
int r = tryAcquireShared(arg);
// 返回值>=0,表示获取同步锁成功了
if (r >= 0) {
// 当该节点的前驱节点是头结点且成功获取同步状态
// 那么接下来就会将把当前结点设置为头结点,释放共享同步状态,唤醒下一个节点
setHeadAndPropagate(node, r);
p.next = null; // help GC
if (interrupted)
selfInterrupt();
failed = false;
return;
}
}

//阻塞线程
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
cancelAcquire(node);
}
}

共享锁的获取逻辑几乎和独占式锁的获取一模一样,这里的自旋过程中能够退出的条件是当前节点的前驱节点是头结点并且tryAcquireShared(arg)返回值大于等于0(表示获得了锁)即能成功获得同步状态

共享锁的释放(releaseShared()方法)
  • 背景

setHeadAndPropagate(node, r);方法中,代码功能分为两部分:

  1. 设置头结点
  2. 释放同步状态,唤醒下一个节点,其中的释放同步状态就使用了releaseShared方法

共享锁的释放在AQS中会调用方法releaseShared

1
2
3
4
5
6
7
public final boolean releaseShared(int arg) {
if (tryReleaseShared(arg)) {
doReleaseShared();
return true;
}
return false;
}

当成功释放同步状态之后即tryReleaseShared会继续执行doReleaseShared方法:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
private void doReleaseShared() {
/*
* Ensure that a release propagates, even if there are other
* in-progress acquires/releases. This proceeds in the usual
* way of trying to unparkSuccessor of head if it needs
* signal. But if it does not, status is set to PROPAGATE to
* ensure that upon release, propagation continues.
* Additionally, we must loop in case a new node is added
* while we are doing this. Also, unlike other uses of
* unparkSuccessor, we need to know if CAS to reset status
* fails, if so rechecking.
*/
// 自旋释放共享同步状态
for (;;) {
Node h = head;
// 若头结点不为空 且 头结点不等于尾结点 说明存在【有效】node节点 (因为我们是带头结点的链表)
if (h != null && h != tail) {
int ws = h.waitStatus;
// 若头结点状态为signal,表示存在需要唤醒的后继结点
if (ws == Node.SIGNAL) {
//将头结点状态更新为 0(初始值状态),因为头结点此时没用了,需要去释放同步锁了
if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
// continue为了保证替换成功
continue; // loop to recheck cases
// 唤醒后继结点
unparkSuccessor(h);
}
// 如果状态为初始值状态0,那么久设置成PROPAGATE状态
// 作用: 确保在释放同步状态的时候能去通知后继结点
else if (ws == 0 &&
!compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
continue; // loop on failed CAS
}
if (h == head) // loop if head changed
break;
}
}

这段方法跟独占式锁释放过程有点点不同,在共享式锁的释放过程中,对于能够支持多个线程同时访问的并发组件,必须保证多个线程能够安全的释放同步状态,这里采用的CAS保证,当CAS操作失败continue,在下一次循环中进行重试。

ReentrantLock - 可重入锁

ReentrantLock简介

ReentrantLock重入锁,是基于AQS同时实现Lock接口的一个类,在并发编程的时候实现公平锁和非公平锁两种方式对共享资源进行同步。

重入性,表示能够对共享资源能够重复加锁,即当前线程获取该锁再次获取不会被阻塞。

在java关键字synchronized隐式支持重入性,synchronized通过获取自增,释放自减的方式实现重入。

要想完完全全的弄懂ReentrantLock的话,主要也就是ReentrantLock同步语义的学习:

  1. 重入性的实现原理
  2. 公平锁和非公平锁

重入性的实现原理

要想支持重入性,就要解决两个问题:

1. 在线程获取锁的时候,如果已经获取锁的线程是当前线程的话则直接再次获取成功;

2. 由于锁会被获取n次,那么只有锁在被释放同样的n次之后,该锁才算是完全释放成功。

通过[AQS](# AbstractQueuedSynchronizer(AQS)的学习,我们知道,同步组件主要是通过重写AQS的几个protected方法来表达自己的同步语义。针对第一个问题,我们来看看ReentrantLock是怎样实现的,以非公平锁为例,判断当前线程能否获得锁为例,核心方法为nonfairTryAcquire

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
final boolean nonfairTryAcquire(int acquires) {

//获取当前线程
final Thread current = Thread.currentThread();
//获取state变量值
int c = getState();
//1. 如果该锁未被任何线程占有,该锁能被当前线程获取
if (c == 0) {
if (compareAndSetState(0, acquires)) {
//占用锁成功,设置独占线程为当前线程
setExclusiveOwnerThread(current);
return true;
}
}
//2.若被占有,检查占有线程是否是当前线程
else if (current == getExclusiveOwnerThread()) {
// 3. 再次获取,计数加一
int nextc = c + acquires;
if (nextc < 0) // overflow
throw new Error("Maximum lock count exceeded");

// 更新state值为新的重入次数
setState(nextc);
return true;
}
return false;
}

这段代码的逻辑也很简单,具体请看注释。为了支持重入性,在第二步增加了处理逻辑,如果该锁已经被线程所占有了,会继续检查占有线程是否为当前线程,如果是的话,同步状态加1返回true,表示可以再次获取成功。每次重新获取都会对同步状态进行加一的操作,那么释放的时候处理思路是怎样的了?(依然还是以非公平锁为例)核心方法为tryRelease:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
protected final boolean tryRelease(int releases) {
//1. 同步状态减1
int c = getState() - releases;
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
boolean free = false;
if (c == 0) {
//2. 只有当同步状态为0时,锁成功被释放,返回true
free = true;
setExclusiveOwnerThread(null);
}
// 3. 锁未被完全释放,返回false
setState(c);
return free;
}

代码逻辑看注释

  • 注意点

需要注意的是,重入锁的释放必须得等到同步状态为0时锁才算成功释放,否则锁仍未释放。如果锁被获取n次,释放了n-1次,该锁未完全释放返回false,只有被释放n次才算成功释放,返回true。因此,return的值并不是代表有没有释放成功,而是代表有没有完全释放!

到现在我们可以理清ReentrantLock重入性的实现了,也就是理解了同步语义的第一条。

公平锁与非公平锁

  1. ReentrantLock支持两种锁:公平锁非公平锁何谓公平性,是针对获取锁而言的,如果一个锁是公平的,那么锁的获取顺序就应该符合请求上的绝对时间顺序,满足FIFO

公平锁 VS 非公平锁

  1. 公平锁每次获取到锁为同步队列中的第一个节点,保证请求资源时间上的绝对顺序,而非公平锁有可能刚释放锁的线程下次继续获取该锁,则有可能导致其他线程永远无法获取到锁,造成“饥饿”现象

  2. 公平锁为了保证时间上的绝对顺序,需要频繁的上下文切换,而非公平锁会降低一定的上下文切换,降低性能开销。因此,ReentrantLock默认选择的是非公平锁,则是为了减少一部分上下文切换,保证了系统更大的吞吐量

  • 公平锁:按照请求锁的顺序分配,拥有稳定获得锁的机会,但是性能可能比非公平锁低
  • 非公平锁:不按照请求锁的顺序分配,不一定拥有获得锁的机会,但是性能可能比公平锁高
  • 非公平锁源码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
/**
* Sync object for non-fair locks
*/
static final class NonfairSync extends Sync {
private static final long serialVersionUID = 7316153563782823691L;

/**
* Performs lock. Try immediate barge, backing up to normal
* acquire on failure.
*/
final void lock() {
// 通过CAS获取锁(一次机会,并不是无限自旋获取)
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
// CAS获取失败了,则调用AQS的acquire方法获取锁
acquire(1);
}

protected final boolean tryAcquire(int acquires) {
// 调用非公平锁,插队获取
return nonfairTryAcquire(acquires);
}
}
  • 公平锁源码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
/**
* Sync object for fair locks
*/
static final class FairSync extends Sync {
private static final long serialVersionUID = -3000897897090466540L;

// 调用父类AQS的acquire方法
final void lock() {
acquire(1);
}

/**
* Fair version of tryAcquire. Don't grant access unless
* recursive call or no waiters or is first.
*/
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
if (!hasQueuedPredecessors() &&
compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
}

ReentrantLock的构造方法无参时是构造非公平锁,源码为:

1
2
3
public ReentrantLock() {
sync = new NonfairSync();
}

另外还提供了另外一种方式,可传入一个boolean值,true时为公平锁,false时为非公平锁,源码为:

1
2
3
public ReentrantLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
}

在上面非公平锁获取时(nonfairTryAcquire方法)只是简单的获取了一下当前状态做了一些逻辑处理,并没有考虑到当前同步队列中线程等待的情况。我们来看看公平锁的处理逻辑是怎样的,核心方法为:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
protected final boolean tryAcquire(int acquires) {
// 获取当前线程
final Thread current = Thread.currentThread();
// 获取线程状态
int c = getState();
// 锁状态空闲
if (c == 0) {
// 通过CAS原子性更改state,更改成功,表示成功获取锁,将当前线程设置为独占线程
// 判断当前同步队列中有没有排在当前线程之前的线程
if (!hasQueuedPredecessors() &&
compareAndSetState(0, acquires)) {
// 尝试获取锁
setExclusiveOwnerThread(current);
return true;
}
}
// 锁状态不空闲,再判断是不是独占线程(因为可能是一个线程多个锁,可重入锁嘛)
else if (current == getExclusiveOwnerThread()) {
// 进行状态的累加
int nextc = c + acquires;
// 判断重入次数,如果<0,则表示超出次数了(int 最大值2147483647)
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
}

这段代码的逻辑与nonfairTryAcquire基本上一致,唯一的不同在于增加了hasQueuedPredecessors的逻辑判断,方法名就可知道该方法用来判断当前节点在同步队列中是否有前驱节点的判断,如果有前驱节点说明有线程比当前线程更早的请求资源,根据公平性,当前线程请求资源失败。

如果当前节点没有前驱节点的话,再才有做后面的逻辑判断的必要性。公平锁每次都是从同步队列中的第一个节点获取到锁,而非公平性锁则不一定,有可能刚释放锁的线程能再次获取到锁

ReentrantReadWriteLock - 读写锁

ReadLock

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
public static class ReadLock implements Lock, java.io.Serializable {

private static final long serialVersionUID = -5992448646407690164L;

//同步类
private final Sync sync;

protected ReadLock(ReentrantReadWriteLock lock) {
sync = lock.sync;
}

//调用同步器 获取共享锁
public void lock() {
sync.acquireShared(1);
}

//
public void lockInterruptibly() throws InterruptedException {
sync.acquireSharedInterruptibly(1);
}

public boolean tryLock() {
return sync.tryReadLock();
}


public boolean tryLock(long timeout, TimeUnit unit)
throws InterruptedException {
return sync.tryAcquireSharedNanos(1, unit.toNanos(timeout));
}

public void unlock() {
sync.releaseShared(1);
}


public Condition newCondition() {
throw new UnsupportedOperationException();
}

public String toString() {
int r = sync.getReadLockCount();
return super.toString() +
"[Read locks = " + r + "]";
}
}

读锁的获取

它的各种代码都与AQS的没太大变化,我们关心一下其独特的部分:tryAcquireShared方法

  • 源码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
protected final int tryAcquireShared(int unused) {
/*
* Walkthrough:
* 1. If write lock held by another thread, fail.
* 2. Otherwise, this thread is eligible for
* lock wrt state, so ask if it should block
* because of queue policy. If not, try
* to grant by CASing state and updating count.
* Note that step does not check for reentrant
* acquires, which is postponed to full version
* to avoid having to check hold count in
* the more typical non-reentrant case.
* 3. If step 2 fails either because thread
* apparently not eligible or CAS fails or count
* saturated, chain to version with full retry loop.
*/
Thread current = Thread.currentThread();
int c = getState();
//1. 如果写锁已经被获取并且获取写锁的线程不是当前线程的话
if (exclusiveCount(c) != 0 &&
getExclusiveOwnerThread() != current)
// 当前线程获取读锁失败返回-1
return -1;
// 如果写锁没有被霸占,则将高16位移到低16位。
int r = sharedCount(c); c >>> 16
// !readerShouldBlock() 和写锁的逻辑一样(根据公平与否策略和队列是否含有等待节点)
// 不能大于 65535,且 CAS 修改成功
if (!readerShouldBlock() &&
r < MAX_COUNT &&
//2. 当前线程获取读锁
compareAndSetState(c, c + SHARED_UNIT)) {
//3. 下面的代码主要是新增的一些功能,比如getReadHoldCount()方法
//返回当前获取读锁的次数
// 如果锁次数为0,表示读锁空闲,获取成功
if (r == 0) {
// 把读锁交给当前线程
firstReader = current;
// 锁计数为1
firstReaderHoldCount = 1;
// 如果锁不是空闲的,且当前线程是第一个读线程,代表着重入;
} else if (firstReader == current) {
// 持有的读锁数量自增1
firstReaderHoldCount++;
} else { // 如果都不是,就代表不是第一个节点
// cachedHoldCounter 代表的是最后一个获取读锁的线程的计数器。
HoldCounter rh = cachedHoldCounter;
// 如果最后一个线程计数器是 null 或者不是当前线程,那么就新建一个 HoldCounter 对象
if (rh == null || rh.tid != getThreadId(current))
// 给当前线程新建一个 HoldCounter
cachedHoldCounter = rh = readHolds.get();
// 如果不是 null,且 count 是 0,就将上个线程的 HoldCounter 覆盖本地的。
else if (rh.count == 0)
readHolds.set(rh);
// 对 count 加一
rh.count++;
}
// 返回大于0的数,表示获取到了共享锁
return 1;
}
//4. 处理在第二步中CAS操作失败的自旋已经实现重入性
return fullTryAcquireShared(current);
}

大体流程:

  1. step1:如果写锁被获取,直接获取资源acquire失败(返回 -1)。
  2. step2:写锁没被获取,则首先根据 queue policy(公平锁或非公平锁) 判断一下要不要阻塞。不需要阻塞则有其次,通过修改 原子state 来尝试获取资源,成功则要修改一下重入计数
  3. step3:上面的都失败了,则进入到fullTryAcquireShared中。
  • exclusiveCount(c) 与 sharedCount(c)

exclusiveCount(c)方法,其源码为:

1
2
3
4
5
        static final int SHARED_SHIFT   = 16;
static final int EXCLUSIVE_MASK = (1 << SHARED_SHIFT) - 1;
...
/** Returns the number of exclusive holds represented in count */
static int exclusiveCount(int c) { return c & EXCLUSIVE_MASK; }

这个函数表达的意思是:

c & EXCLUSIVE_MASK != 0c 是我们的 原子state,如果 cEXCLUSIVE_MASK 按位与后不为零,代表无权获取资源,即已经有线程持有了写锁。

其中EXCLUSIVE_MASK为: static final int EXCLUSIVE_MASK = (1 << SHARED_SHIFT) - 1; EXCLUSIVE _MASK为1左移16位然后减1,即为0x0000FFFF(二进制的1111 1111,即十进制的255)。

而exclusiveCount方法是将同步状态(state为int类型)与0x0000FFFF相与,即取同步状态的低16位。那么低16位代表什么呢?根据exclusiveCount方法的注释为独占式获取的次数即写锁被获取的次数,现在就可以得出来一个结论同步状态的低16位用来表示写锁的获取次数

位与图示

那么问题就来了,为什么高位不需要做判断呢?别急,往下看。

sharedCount(c)方法,其源码为:

1
static int sharedCount(int c)    { return c >>> SHARED_SHIFT; }

该方法是获取读锁被获取的次数,是将同步状态(int c)右移16次,即取同步状态的高16位,现在我们可以得出另外一个结论同步状态的高16位用来表示读锁被获取的次数。读写锁是怎样实现分别记录读锁和写锁的状态的,现在这个问题的答案就已经被我们弄清楚了,其示意图如下图所示:

读写锁的读写状态设计.png

读写锁共用一个 原子state,但读锁控制高 16 位,写锁控制低 16 位。 对于写锁来说,低 16 位都为 0 代表没有持锁,只要有一个 1 ,则代表某线程已经持有写锁。

  • fullTryAcquireShared方法

这个方法与tryAcquireShared高度类似,代码逻辑在注释中:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
final int fullTryAcquireShared(Thread current) {
/*
* 这段代码与tryAcquireShared中的代码有部分重复,但整体更简单。
*/
HoldCounter rh = null;
// 死循环
for (;;) {
int c = getState();
//判断是不是有线程持有写锁了
if (exclusiveCount(c) != 0) {
// 若不是当前线程持有写锁,则获取读锁失败,反之,如果持有写锁的是当前线程,那么就会进入下面的逻辑。
if (getExclusiveOwnerThread() != current)
return -1;
// 如果写锁空闲,且可以获取读锁。
} else if (readerShouldBlock()) {
// 这里的代码逻辑是用于处理【读锁重入】的

// 第一个读线程是当前线程
if (firstReader == current) {
// 如果不是当前线程
} else {
if (rh == null) {
// cachedHoldCounter 代表的是最后一个获取读锁的线程的计数器。
rh = cachedHoldCounter;
// 如果最后一个读计数器所属线程不是当前线程。
if (rh == null || rh.tid != getThreadId(current)) {
// 从 ThreadLocal 中取出计数器。get方法会执行初始化
rh = readHolds.get();
// 如果count == 0,表示是由上一行代码初始化的,进行remove操作
if (rh.count == 0)
readHolds.remove();
}
}

if (rh.count == 0)
// return -1,去排队
return -1;
}
}
// 如果读锁次数达到 65535 ,抛出异常
if (sharedCount(c) == MAX_COUNT)
throw new Error("Maximum lock count exceeded");
// 尝试对 state 加 65536, 也就是设置读锁,实际就是对高16位加一。
if (compareAndSetState(c, c + SHARED_UNIT)) {
// 如果读锁是空闲的
if (sharedCount(c) == 0) {
// 设置第一个读锁
firstReader = current;
// 计数器为 1
firstReaderHoldCount = 1;
// 如果不是空闲的,查看第一个线程是否是当前线程。
} else if (firstReader == current) {
// 这里代表着锁重入
firstReaderHoldCount++;// 更新计数器
} else {// 如果不是当前线程
if (rh == null)
// cachedHoldCounter 代表的是最后一个获取读锁的线程的计数器。
rh = cachedHoldCounter;
// 如果最后一个读计数器所属线程不是当前线程。
if (rh == null || rh.tid != getThreadId(current))
// 自己创建一个,get方法会执行初始化
rh = readHolds.get();

else if (rh.count == 0)
readHolds.set(rh);
// 对计数器 ++
rh.count++;
// 更新缓存计数器。
cachedHoldCounter = rh; // cache for release
}
// 返回大于0的数,表示获取到了锁
return 1;
}
}
}
  • firstReader 是获取读锁的第一个线程。如果只有一个线程获取读锁,很明显,使用这样一个变量速度更快。
  • firstReaderHoldCountfirstReader的计数器。同上。
  • cachedHoldCounter是最后一个获取到读锁的线程计数器,每当有新的线程获取到读锁,这个变量都会更新。这个变量的目的是:当最后一个获取读锁的线程重复获取读锁,或者释放读锁,就会直接使用这个变量,速度更快,相当于缓存。
  • 图解流程

    发现了没?我们获取读锁的时候根本不关心读锁有没有被获取,因此从这点也可以知道读锁的共享锁,也就是允许 读 - 读 的场景,而不允许 读 -写 的场景。

img

读锁的释放

读锁释放的实现主要通过方法tryReleaseShared

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
protected final boolean tryReleaseShared(int unused) {
Thread current = Thread.currentThread();
// 前面还是为了实现getReadHoldCount等新功能
if (firstReader == current) {
// assert firstReaderHoldCount > 0;
//如果计数器等于1,那么此次解锁之后就不会再持有锁了
if (firstReaderHoldCount == 1)
// firstReader 置为null,留给后面的线程用
firstReader = null;
else
//如果不为1,表示被重入了,就减-1
firstReaderHoldCount--;
} else {
HoldCounter rh = cachedHoldCounter;
// 判断 cachedHoldCounter 中是否缓存的是当前线程,不是的话就需要用get,到ThreadLoacl中获取
if (rh == null || rh.tid != getThreadId(current))
rh = readHolds.get();
int count = rh.count;
if (count <= 1) {
// 将 ThreadLoacl remove掉,防止内存泄漏,因为此时当前线程已经不再持有锁了
readHolds.remove();
if (count <= 0)
// 防止有些人lock一次,unlock很多次,导致count变为负数
throw unmatchedUnlockException();
}
// 线程持有读锁的数量 - 1
--rh.count;
}
for (;;) {
int c = getState();
// 读锁释放 将同步状态减去读状态即可
// 即:nextc 为 state高16位减1 后的值
int nextc = c - SHARED_UNIT;
if (compareAndSetState(c, nextc))
// Releasing the read lock has no effect on readers,
// but it may allow waiting writers to proceed if
// both read and write locks are now free.
// nextc == 0,表示state 32位全部为0 ,表示读锁写锁全为空
// 若返回true,则帮助唤醒后继节点中获取写锁的线程
return nextc == 0;
}
}

回想一下重入锁,重入锁每次释放资源使得 原子state - -,当 原子state 为零时,则唤醒队列中下一个等待的线程。

读锁实际上也是如此,但要注意读锁是有两个状态来维护锁的层级和持有共享锁的线程数量的:

  • 一个是 HoldCounter 负责重入计数,
  • 一个是 原子state高位,负责记录有多少个线程持有了共享锁。

也就是说,我们释放资源release时,需要首先使得 HoldCounter--,直到其为零,再去操作 原子state高位。

最后,直到原子state高位归零了,就去唤醒下一个等待的线程。

WriteLock

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
public static class WriteLock implements Lock, java.io.Serializable {
private static final long serialVersionUID = -4992448646407690164L;
private final Sync sync;
protected WriteLock(ReentrantReadWriteLock lock) {
sync = lock.sync;
}

public void lock() {
sync.acquire(1);
}

public void lockInterruptibly() throws InterruptedException {
sync.acquireInterruptibly(1);
}


public boolean tryLock( ) {
return sync.tryWriteLock();
}


public boolean tryLock(long timeout, TimeUnit unit)
throws InterruptedException {
return sync.tryAcquireNanos(1, unit.toNanos(timeout));
}


public void unlock() {
sync.release(1);
}


public Condition newCondition() {
return sync.newCondition();
}


public String toString() {
Thread o = sync.getOwner();
return super.toString() + ((o == null) ?
"[Unlocked]" :
"[Locked by thread " + o.getName() + "]");
}

public boolean isHeldByCurrentThread() {
return sync.isHeldExclusively();
}

public int getHoldCount() {
return sync.getWriteHoldCount();
}
}

写锁的获取

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
protected final boolean tryAcquire(int acquires) {
/*
* Walkthrough:
* 1. If read count nonzero or write count nonzero
* and owner is a different thread, fail.
* 2. If count would saturate, fail. (This can only
* happen if count is already nonzero.)
* 3. Otherwise, this thread is eligible for lock if
* it is either a reentrant acquire or
* queue policy allows it. If so, update state
* and set owner.
*/
Thread current = Thread.currentThread();
// 1. 获取写锁当前的同步状态
int c = getState();
// 2. 获取写锁获取的次数,即state中写锁(状态)的值
int w = exclusiveCount(c);
if (c != 0) {
// (Note: if c != 0 and w == 0 then shared count != 0)
// 翻译:state不为0,写状态为0,则表示读状态不为0,表示读锁已被获取
// 3.1 当读锁已被读线程获取或者当前线程不是已经获取写锁的线程的话(判断是不是重入的)防止 读 - 写,和写 - 写
if (w == 0 || current != getExclusiveOwnerThread())
// 当前线程获取写锁失败,返回false
return false;
// 写锁拥有的是state的【低16位】,这里进行校验是否大于其16位能表示的数据范围
if (w + exclusiveCount(acquires) > MAX_COUNT)
throw new Error("Maximum lock count exceeded");
// Reentrant acquire
// 代码进行到这里,能保证写锁状态不为0,且当前线程是已经获取写锁的线程,即支持可重入
// 3.2 当前线程获取写锁,支持可重复加锁
setState(c + acquires);
return true;
}
// writerShouldBlock 非公平锁永远返回false,即可以插入获取,不必阻塞
// 而公平锁则需要检验前一个节点是否为头结点
// 3.3 写锁未被任何线程获取,当前线程可获取写锁
if (writerShouldBlock() ||
!compareAndSetState(c, c + acquires))
return false;
// 设置为当前线程持有
setExclusiveOwnerThread(current);
return true;
}

现在我们回过头来看写锁获取方法tryAcquire,其主要逻辑为:当读锁已经被读线程获取或者写锁已经被其他写线程获取,则写锁获取失败;否则,获取成功并支持重入,增加写状态。

写锁的释放

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// 写锁的释放是线程安全的,因为写锁是独占锁,具有排他性(一次只能有一个线程拥有)
protected final boolean tryRelease(int releases) {
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
//1. 同步状态减去写状态
int nextc = getState() - releases;
//2. 当前写状态是否为0,为0则释放写锁(这里的 0,是包括可重入的,即所有的写锁都是被释放了的
boolean free = exclusiveCount(nextc) == 0;
if (free)
setExclusiveOwnerThread(null);
//3. 不为0则更新同步状态
setState(nextc);
// 返回 true的话,会进行唤醒后继节点的操作
return free;
}

这里需要注意的是,减少写状态int nextc = getState() - releases;只需要用当前同步状态直接减去写状态的原因正是我们刚才所说的写状态是由同步状态的低16位表示的

锁降级

  • 锁降级指的是写锁降级成为读锁

    • 如果当前线程拥有写锁,然后将其释放,最后再获取读锁,这种分段完成的过程不能称之为锁降级。
    • 锁降级是指把持住(当前拥有的)写锁,再获取到读锁,随后释放(先前拥有的)写锁的过程。

    (有锁降级,那有没有锁升级呢?答案是没有的)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
public void processData() {
readLock.lock();
if (!update) { // update使用volatile修饰,使得其他线程均能实时访问
// 必须先释放读锁(如果不释放读锁就去获取写锁就会发生死锁)
readLock.unlock();
// 然后获取写锁(锁降级从获取写锁开始)
writeLock.lock();
try {
if (!update) {
// 准备数据的流程(略)
update = true;
}
readLock.lock(); // 持有写锁的同时,获取读锁
} finally {
writeLock.unlock(); // 释放写锁
}
// 锁降级完成,写锁降级为读锁
}
try {
// ֵ使用数据的流程(略)
} finally {
readLock.unlock();
}
}

细节解析:

  1. update变量用volatile修饰,使得所有访问 processData() 方法的线程都能够感知到变化,保证了可见性
  2. 只有一个线程能够获取到写锁,其他线程会被阻塞在读锁和写锁的lock()方法上。
  3. 当前线程获取写锁完成数据准备之后,再获取读锁,随后释放写锁,完成锁降级。
  • 问题:

    • 锁降级中的读锁的获取是否是必须?

    • 是必须的,为了保证数据的可见性。怎么保证呢?假如现在有一个线程A他拥有写锁,现在要释放该写锁。但他不先去获得读锁,就直接释放了写锁。这就导致了一个问题,有另一个线程B,它获取了你释放掉的写锁,去修改了数据,但A线程是无法感知到这个数据被修改了的,就会导致一些错误。

      但假如遵循锁降级步骤,释放写锁前获得了读锁,那么线程B在获取该写锁的时候就会阻塞,直到线程A把数据处理完了,真正释放了读锁后,才能轮到线程B去进行相应的写锁获取流程。

Condition

简介

  • Condition用途

当多个线程需要访问一个共享资源时,需要给共享资源加锁。 当一个线程释放锁时,所有等待锁的线程都会尝试去获取锁。 但是如果想只让部分等待锁的线程去获取锁时,就需要用到Condition

  • 整体分析

从整体上来看Object的wait和notify/notify是与对象监视器配合完成线程间的等待/通知机制,而Condition与Lock配合完成等待通知机制,前者是java底层级别的,后者是语言级别的,具有更高的可控制性和扩展性

Condition具体实现在AbstractQueuedSynchronizer类中。这个类中管理了一个阻塞队列和N多个条件队列。

阻塞队列记录了等待获取锁的线程,头结点记录了当前正在运行的线程。

条件队列记录了由Condition.await()阻塞的线程,一个Lock可以有多个Condition,每个Condition是一个队列。

Condition是AbstractQueuedSynchronizer的一个内部类ConditionObject,所以创建的Condition对象是可以访问整个AbstractQueuedSynchronizer对象的属性的,通过这样将Condition与Lock相关联。

原理分析

等待队列

  • 前言

Condition是AQS的内部类,准确的来说创建一个condition对象是通过lock.newCondition(),而这个方法实际上是会new出一个ConditionObject对象,而这个ConditionObject对象是AQS的一个内部类。

前面我们说过,Condition是要和lock配合使用的也就是condition和Lock是绑定在一起的,而lock的实现原理又依赖于AQS,自然而然ConditionObject作为AQS的一个内部类无可厚非。

  • 等待队列

每个Condition对象都包含一个条件队列 (等待队列)。

等待队列是一个FIFO的队列,在队列中的每个节点Node都包含了一个线程引用,该线程就是在Condition对象上等待的线程。

详细来说的话:如果是独占式锁的话,所有获取锁失败的线程的尾插入到同步队列,同样的,Condition内部也是使用同样的方式,内部维护了一个 等待队列,所有调用condition.await方法的线程会加入到等待队列中,并且线程状态转换为等待状态。

  • ConditionObject中两个成员变量
1
2
3
4
5
6
/** First node of condition queue. */
// 首节点
private transient Node firstWaiter;
/** Last node of condition queue. */
// 尾结点
private transient Node lastWaiter;

这样我们就可以看出来ConditionObject通过持有等待队列的头尾指针来管理等待队列。

  • 等待队列为单向队列

值得注意的是Node类复用了在AQS中的Node类,而Node类有这样一个属性:

1
2
//后继节点
Node nextWaiter;

这说明 ,等待队列是一个单向队列,而学习AQS的时候我们学习到了,同步队列是双向队列

image-20210522212045608

  • 一个Lock可以持有多个等待队列

我们可以多次调用lock.newCondition()方法创建多个condition对象,也就是一个lock可以持有多个等待队列。而在之前利用Object的方式实际上是指在对象Object对象监视器上只能拥有一个同步队列和一个等待队列,而并发包中的Lock拥有一个同步队列和多个等待队列

需要注意概念混淆的问题:同步队列是在同步的环境下才有的概念,一个对象(即一个锁)永远只对应一个同步队列。

AQS持有多个Condition.png

如图所示,ConditionObject是AQS的内部类,因此每个ConditionObject能够访问到AQS提供的方法,相当于每个Condition都拥有所属同步器的引用。

那么为什么每个并发包的同步器需要有多个等待队列呢?有什么作用呢?

因为AQS可以实现排他锁(ReentrantLock)和非排他锁(ReentrantReadWriteLock——读写锁),读写锁就是一个需要多个等待队列的锁。等待队列(Condition)用来保存被阻塞的线程的。因为读写锁是一对锁,所以需要两个等待队列来分别保存被阻塞的读锁和被阻塞的写锁。

await实现原理

  • await流程

当调用condition.await()方法后会使得当前获取lock的线程进入到等待队列,并且释放锁

注意点:当该方法返回时,当前线程一定获取了同步状态(锁);

具体原因是当通过signal()等系列方法,线程才会从await()方法返回,而唤醒该线程后会加入同步队列

  • await源码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
public final void await() throws InterruptedException {
if (Thread.interrupted())//当前线程如果中断抛出异常
throw new InterruptedException();
// 1. 将当前线程包装成Node,尾插入到等待队列中 - 这里的等待队列是一个【单向链表】
Node node = addConditionWaiter();
// 2. 释放当前线程所占用的lock(用await之前当前线程是占有锁的)
// 在释放的过程中会唤醒同步队列中的下一个节点
int savedState = fullyRelease(node);
int interruptMode = 0;
// isOnSyncQueue用于判断线程是否在同步队列中,第一次判断为false,因为线程已经释放了
// 释放完毕后,遍历AQS队列,看当前节点是否在同步队列中,
// 如果不在,说明它还没有竞争锁的资格,继续等待 ;直到被加入到队列(singal)
while (!isOnSyncQueue(node)) {
// 3. 当前线程进入到等待状态
LockSupport.park(this);
// 线程被挂起,阻塞在这个位置
   // 判断线程被打断后,退出循环。
// 该方法的返回值代表当前线程是否在 park 的时候被中断唤醒
if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
break;
}
// 4. 自旋等待获取到同步状态(即获取到lock)
// 下面是细节:
//被唤醒后,重新开始正式竞争锁,如果竞争不到还是会将自己沉睡,等待唤醒重新开始竞争
//acquireQueued: 该方法的功能是循环的尝试获取锁, 如果返回false就表示拿到锁了
// interruptMode !=THROW_IE 表示这个线程没有成功将node入队,但signal执行了enq方法让其入队了 ,将这个变量设置成 REINTERRUPT
if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
interruptMode = REINTERRUPT;
// 如果 node 的下一个等待者不是 null, 则进行清理,清理 Condition 队列上的节点
if (node.nextWaiter != null) // clean up if cancelled
unlinkCancelledWaiters();
// 5. 处理被中断的情况
if (interruptMode != 0)
reportInterruptAfterWait(interruptMode);
}

代码整体流程:

当当前线程调用condition.await()方法后,会使得当前线程释放lock然后加入到等待队列中,直至被signal/signalAll后会使得当前线程从等待队列中移至到同步队列中去,直到获得了lock后才会从await方法返回,或者在等待时被中断会做中断处理

  • 细节/问题

那么关于这个实现过程我们会有这样几个问题:

  1. 是怎样将当前线程添加到等待队列中去的?
  2. 释放锁的过程?
  3. 怎样才能从await方法退出?

要回答这几个问题,我们就需要去注意这几个方法:

addConditionWaiter unlinkCancelledWaiters() fullyRelease(Node node) isOnSyncQueue(Node node)

  • addConditionWaiter方法 - 线程添加到等待队列
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
private Node addConditionWaiter() {
Node t = lastWaiter;
// If lastWaiter is cancelled, clean out.
// 翻译:如果尾节点被cancel了,则先遍历整个链表,清除所有被cancel的节点
if (t != null && t.waitStatus != Node.CONDITION) {
// 清空所有等待队列中 状态不为Condition的节点
unlinkCancelledWaiters();
// 将最新的尾结点赋值
t = lastWaiter;
}
//将当前线程包装成Node
Node node = new Node(Thread.currentThread(), Node.CONDITION);
if (t == null)
firstWaiter = node;
else
//尾插入
t.nextWaiter = node;
//更新lastWaiter
lastWaiter = node;
return node;
}

这段代码的流程是:

首先判断尾结点状态,如果尾结点已经中断的话,那么我们就不应该把当前线程包装成节点,接在它的后面,因此需要调用unlinkCancelledWaiters去剔除等待队列中所有的已经中断或已经释放同步状态的线程节点。

接着,将当前节点包装成Node,如果等待队列的firstWaiter为null的话(等待队列为空队列),则将firstWaiter指向当前的Node,

否则,更新lastWaiter(尾节点)即可,即通过尾插入的方式将当前线程封装的Node插入到等待队列中即可,同时可以看出等待队列是一个不带头结点的链式队列,之前我们学习AQS时知道同步队列是一个带头结点的链式队列,这是两者的一个区别。

将当前节点插入到等待对列之后,会使当前线程释放lock,由fullyRelease方法实现

  • unlinkCancelledWaiters()方法
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
private void unlinkCancelledWaiters() {
//获取等待队列中的头节点
Node t = firstWaiter;
Node trail = null;
//遍历等待队列,将已经中断的线程节点从等待队列中移除。
while (t != null) {
Node next = t.nextWaiter;
if (t.waitStatus != Node.CONDITION) {
t.nextWaiter = null;
if (trail == null)
firstWaiter = next;
else
trail.nextWaiter = next;
if (next == null)//重新定义lastWaiter的指向
lastWaiter = trail;
}
else
trail = t;
t = next;
}
}

方法流程:

img

  • fullyRelease方法 - 释放锁的方法
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
final int fullyRelease(Node node) {
boolean failed = true;
try {
int savedState = getState();
if (release(savedState)) {
//成功释放同步状态
failed = false;
return savedState;
} else {
//不成功释放同步状态抛出异常
throw new IllegalMonitorStateException();
}
} finally {
if (failed)
node.waitStatus = Node.CANCELLED;
}
}

代码逻辑:

调用AQS的模板方法release方法释放AQS的同步状态并且唤醒在同步队列中头结点的后继节点引用的线程,如果释放成功则正常返回,若失败的话就抛出异常。

  • isOnSyncQueue(Node node)

该方法主要用于判断当前线程节点是否在【同步队列】中。具体代码如下所示:

1
2
3
4
5
6
7
8
9
10
final boolean isOnSyncQueue(Node node) {
//判断当前节点 waitStatus ==Node.CONDITION或者当前节点上一节点为空,则不在同步队列中
if (node.waitStatus == Node.CONDITION || node.prev == null)
return false;
//如果当前节点拥有下一个节点,则在同步队列中。
if (node.next != null) // If has successor, it must be on queue
return true;
//如果以上条件都不满足,则遍历同步队列。检查是否在同步队列中。
return findNodeFromTail(node);
}

如果你还记得AQS中的同步队列,那么你应该知道同步队列中的Node节点才会使用其内部的prenext字段,那么在同步队列中因为只使用了nextWaiter字段,所以我们就能很简单的通过这两个字段是否为==null,来判断是否在同步队列中。

当然也有可能有一种特殊情况:有可能需要阻塞的线程节点还没有加入到同步队列中,那么这个时候我们需要遍历同步队列来判断是该线程节点是否已存在。

具体代码如下所示:

1
2
3
4
5
6
7
8
9
private boolean findNodeFromTail(Node node) {
for (Node p = tail;;) {
if (p == node)
return true;
if (p == null)
return false;
p = p.prev;
}
}

这里为什么是从尾结点向前遍历呢?思考一下,这个方法是用于找哪种线程节点的呢?是找那种还没有加入到同步队列中的线程,这种线程是独立的一个节点,它并没有被连接在任何一个在同步队列中的线程后面,因此,我们需要从后往前找,找到一个node.next == null的,就代表他不在同步队列中,反之,他在同步队列中。

  • 如何从await方法退出

学习了上面几个方法,我们也可以回答这第三个问题了;

1
2
3
4
5
6
while (!isOnSyncQueue(node)) {
// 3. 当前线程进入到等待状态
LockSupport.park(this);
if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
break;
}

很显然,当线程第一次调用condition.await()方法时,会进入到这个while()循环中,然后通过LockSupport.park(this)方法使得当前线程进入等待状态,那么要想退出这个await方法第一个前提条件自然而然的是要先退出这个while循环,出口就只剩下两个地方:

1. 逻辑走到break退出while循环;

2. while循环中的逻辑判断为false

那么下面就分点讨论这两种情况该如何实现:

  1. 当前等待的线程被中断后,代码就会走到 break处退出
  2. 当前节点被移动到了【同步队列】中(即另外线程调用的condition的signal或者signalAll方法),此时while循环中判断结果就会为false,结束循环

总结下,就是当前线程被中断或者调用condition.signal/condition.signalAll方法当前节点移动到了同步队列后 ,这是当前线程退出await方法的前提条件。当退出while循环后就会调用acquireQueued(node, savedState),这个方法在介绍AQS的底层实现时说过了,该方法的作用是在自旋过程中线程不断尝试获取同步状态,直至成功(线程获取到lock)。这样也说明了退出await方法必须是已经获得了condition引用(关联)的lock

  • 图解阻塞流程

img

  1. 将该线程节点从同步队列中移除,并释放其同步状态。
  2. 构造新的阻塞节点,加入到等待队列中。

signal/signalAll实现原理

调用condition的signal或者signalAll方法可以将等待队列中等待时间最长的节点移动到同步队列中,使得该节点能够有机会获得lock。

按照等待队列是先进先出(FIFO)的,所以等待队列的头节点必然会是等待时间最长的节点,也就是每次调用condition的signal方法是将头节点移动到同步队列中。

signal源码

1
2
3
4
5
6
7
8
9
public final void signal() {
//1. 先检测当前线程是否已经获取lock
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
//2. 获取等待队列中第一个节点,将其移入同步队列,接着对该结点进行操作
Node first = firstWaiter;
if (first != null)
doSignal(first);
}

这里涉及到了两个方法:

  1. isHeldExclusively()方法
  2. doSignal(first)方法

下面对这两个方法进行学习

  • isHeldExclusively()方法

isHeldExclusively()方法是AQS中的方法,默认交给其子类实现,主要用于判断当前调用singal()方法的线程,是否在同步队列中,且已经获取了同步状态。具体代码如下所示:

1
2
3
protected boolean isHeldExclusively() {
throw new UnsupportedOperationException();
}
  • doSignal(first)方法
1
2
3
4
5
6
7
8
9
10
private void doSignal(Node first) {
do {
//(1)将等待队列中的首节点从等待队列中移除,并重新制定firstWaiter的指向
if ( (firstWaiter = first.nextWaiter) == null)
lastWaiter = null;
first.nextWaiter = null;
} while (!transferForSignal(first) &&
//(2)将等待队列中的首节点,加入同步队列中,并重新唤醒该节点
(first = firstWaiter) != null);
}
  1. 将等待队列中的首节点从等待队列中移除,并设置firstWaiter的指向为首节点的下一个节点

    img

  2. 通过 transferForSignal(Node node)方法,将等待队列中的首节点,加入到同步队列中去,然后重新唤醒该线程节点。

  • transferForSignal(Node node)方法
1
2
3
4
5
6
7
8
9
10
11
12
13
final boolean transferForSignal(Node node) {

//(1)将该线程节点的状态设置为初始状态,如果失败则表示当前线程已经中断了
if (!node.compareAndSetWaitStatus(Node.CONDITION, 0))
return false;
//(2)将该节点放入同步队列中,
Node p = enq(node);
int ws = p.waitStatus;
//(3)获取当前节点的状态并判断,尝试将该线程节点状态设置为Singal,如果失败则唤醒线程
if (ws > 0 || !p.compareAndSetWaitStatus(ws, Node.SIGNAL))
LockSupport.unpark(node.thread);
return true;
}

关键逻辑请看注释,这段代码主要做了两件事情

  1. 将头结点的状态更改为CONDITION;
  2. 调用enq方法,将该节点尾插入到同步队列中;
  3. 当将该线程节点放入同步队列后,获取当前节点的状态并判断,如果该节点的waitStatus>0或者通过compareAndSetWaitStatus(ws, Node.SIGNAL)将该节点的状态设置为Singal,如果失败则通过LockSupport.unpark(node.thread)唤醒线程。
  • 结论

调用condition的signal的前提条件是当前线程已经获取了lock,该方法会使得等待队列中的头节点即等待时间最长的那个节点移入到同步队列,而移入到同步队列后才有机会使得等待线程被唤醒,即从await方法中的LockSupport.park(this)方法中返回,从而才有机会使得调用await方法的线程成功退出

  • 图解流程

img

await与signal结合

await和signal和signalAll方法就像一个开关控制着线程A(等待方)和线程B(通知方):

condition下的等待通知机制.png

如图,线程awaitThread先通过lock.lock()方法获取锁成功后调用了condition.await方法进入等待队列,而另一个线程signalThread通过lock.lock()方法获取锁成功后调用了condition.signal或者signalAll方法,使得线程awaitThread能够有机会移入到同步队列中,当其他线程释放lock后使得线程awaitThread能够有机会获取lock,从而使得线程awaitThread能够从await方法中退出执行后续操作。如果awaitThread获取lock失败会直接进入到同步队列

代码例子

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
public class AwaitSignal {
private static ReentrantLock lock = new ReentrantLock();
private static Condition condition = lock.newCondition();
private static volatile boolean flag = false;

public static void main(String[] args) {
Thread waiter = new Thread(new waiter());
waiter.start();
Thread signaler = new Thread(new signaler());
signaler.start();
}

static class waiter implements Runnable {

@Override
public void run() {
lock.lock();
try {
while (!flag) {
System.out.println(Thread.currentThread().getName() + "当前条件不满足等待");
try {
condition.await();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
System.out.println(Thread.currentThread().getName() + "接收到通知条件满足");
} finally {
lock.unlock();
}
}
}

static class signaler implements Runnable {

@Override
public void run() {
lock.lock();
try {
flag = true;
condition.signalAll();
} finally {
lock.unlock();
}
}
}
}

输出结果为:

Thread-0当前条件不满足等待
Thread-0接收到通知,条件满足

  • 代码流程

开启了两个线程waiter和signaler,waiter线程开始执行的时候由于条件不满足,执行condition.await方法使该线程进入等待状态同时释放锁,signaler线程获取到锁之后更改条件,并通知所有的等待线程后释放锁。这时,waiter线程获取到锁,并由于signaler线程更改了条件此时相对于waiter来说条件满足,继续执行。

LockSupport

  • 源码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
public class LockSupport {
private LockSupport() {} // Cannot be instantiated.

private static void setBlocker(Thread t, Object arg) {
UNSAFE.putObject(t, parkBlockerOffset, arg);
}

/**
* 返回提供给最近一次尚未解除阻塞的 park 方法调用的 blocker 对象。
* 如果该调用不受阻塞,则返回 null。
* 返回的值只是一个瞬间快照,即由于未解除阻塞或者在不同的 blocker 对象上受阻而具有的线程。
*/
public static Object getBlocker(Thread t) {
if (t == null)
throw new NullPointerException();
return UNSAFE.getObjectVolatile(t, parkBlockerOffset);
}

/**
* 如果给定线程的许可尚不可用,则使其可用。
* 如果线程在 park 上受阻塞,则它将解除其阻塞状态。
* 否则,保证下一次调用 park 不会受阻塞。
* 如果给定线程尚未启动,则无法保证此操作有任何效果。
* @param thread: 要执行 unpark 操作的线程;该参数为 null 表示此操作没有任何效果。
*/
public static void unpark(Thread thread) {
if (thread != null)
UNSAFE.unpark(thread);
}

/**
* 为了线程调度,在许可可用之前阻塞当前线程。
* 如果许可可用,则使用该许可,并且该调用立即返回;
* 否则,为线程调度禁用当前线程,并在发生以下三种情况之一以前,使其处于休眠状态:
* 1. 其他某个线程将当前线程作为目标调用 unpark
* 2. 其他某个线程中断当前线程
* 3. 该调用不合逻辑地(即毫无理由地)返回
*/
public static void park() {
UNSAFE.park(false, 0L);
}

/**
* 和park()方法类似,不过增加了等待的相对时间
*/
public static void parkNanos(long nanos) {
if (nanos > 0)
UNSAFE.park(false, nanos);
}

/**
* 和park()方法类似,不过增加了等待的绝对时间
*/
public static void parkUntil(long deadline) {
UNSAFE.park(true, deadline);
}

/**
* 和park()方法类似,只不过增加了暂停的同步对象
* @param blocker 导致此线程暂停的同步对象
* @since 1.6
*/
public static void park(Object blocker) {
Thread t = Thread.currentThread();
setBlocker(t, blocker);
UNSAFE.park(false, 0L);
setBlocker(t, null);
}

/**
* parkNanos(long nanos)方法类似,只不过增加了暂停的同步对象
* @param blocker 导致此线程暂停的同步对象
* @since 1.6
*/
public static void parkNanos(Object blocker, long nanos) {
if (nanos > 0) {
Thread t = Thread.currentThread();
setBlocker(t, blocker);
UNSAFE.park(false, nanos);
setBlocker(t, null);
}
}

/**
* parkUntil(long deadline)方法类似,只不过增加了暂停的同步对象
* @param blocker 导致此线程暂停的同步对象
* @since 1.6
*/
public static void parkUntil(Object blocker, long deadline) {
Thread t = Thread.currentThread();
setBlocker(t, blocker);
UNSAFE.park(true, deadline);
setBlocker(t, null);
}

static final int nextSecondarySeed() {
int r;
Thread t = Thread.currentThread();
if ((r = UNSAFE.getInt(t, SECONDARY)) != 0) {
r ^= r << 13; // xorshift
r ^= r >>> 17;
r ^= r << 5;
}
else if ((r = java.util.concurrent.ThreadLocalRandom.current().nextInt()) == 0)
r = 1; // avoid zero
UNSAFE.putInt(t, SECONDARY, r);
return r;
}

// Hotspot implementation via intrinsics API
private static final sun.misc.Unsafe UNSAFE;
private static final long parkBlockerOffset;
private static final long SEED;
private static final long PROBE;
private static final long SECONDARY;
static {
try {
UNSAFE = sun.misc.Unsafe.getUnsafe();
Class<?> tk = Thread.class;
parkBlockerOffset = UNSAFE.objectFieldOffset
(tk.getDeclaredField("parkBlocker"));
SEED = UNSAFE.objectFieldOffset
(tk.getDeclaredField("threadLocalRandomSeed"));
PROBE = UNSAFE.objectFieldOffset
(tk.getDeclaredField("threadLocalRandomProbe"));
SECONDARY = UNSAFE.objectFieldOffset
(tk.getDeclaredField("threadLocalRandomSecondarySeed"));
} catch (Exception ex) { throw new Error(ex); }
}
}

并发容器

ConcurrentHashMap

ConcurrentHashMap简介

在使用HashMap时在多线程情况下扩容会出现CPU接近100%的情况,因为Hashmap并不是线程安全的,通常我们可以使用在java体系中古老的hashtable类,该类基本上所有的方法都采用synchronized进行线程安全的控制,可想而知,在高并发的情况下,每次只有一个线程能够获取对象监视器锁,这样的并发性能的确不令人满意。

另外一种方式通过Collections的Map<K,V> synchronizedMap(Map<K,V> m)将hashmap包装成一个线程安全的map。比如SynchronzedMap的put方法源码为:

1
2
3
public V put(K key, V value) {
synchronized (mutex) {return m.put(key, value);}
}

实际上SynchronizedMap实现依然是采用synchronized独占式锁进行线程安全的并发控制的。同样,这种方案的性能也是令人不太满意的。

相对于hashmap来说,ConcurrentHashMap就是线程安全的map,其中利用了锁分段的思想提高了并发度

  • JDK 1.6版本关键要素
  1. segment继承了ReentrantLock充当锁的角色,为每一个segment提供了线程安全的保障;
  2. segment维护了哈希散列表的若干个桶,每个桶由HashEntry构成的链表。
  • JDK 1.8版本关键要素

1.8版本舍弃了segment,并且大量使用了synchronized,以及CAS无锁操作以保证ConcurrentHashMap操作的线程安全性。

至于为什么不用ReentrantLock而是Synchronzied呢?实际上,synchronzied做了很多的优化,包括偏向锁,轻量级锁,重量级锁,可以依次向上升级锁状态,但不能降级,因此,使用synchronized相较于ReentrantLock的性能会持平甚至在某些情况更优,具体的性能测试可以去网上查阅一些资料。

另外,底层数据结构改变为采用数组+链表+红黑树的数据形式。(之前是数组 + 链表的形式)

关键属性 & 类

在了解ConcurrentHashMap的具体方法实现前,我们需要系统的来看一下几个关键的地方。

ConcurrentHashMap的关键属性

  1. table
    volatile Node<K,V>[] table://装载Node的数组,作为ConcurrentHashMap的数据容器,采用懒加载的方式,直到第一次插入数据的时候才会进行初始化操作,数组的大小总是为2的幂次方。

  2. nextTable
    volatile Node<K,V>[] nextTable; //扩容时使用,平时为null,只有在扩容的时候才为非null

  3. sizeCtl
    volatile int sizeCtl;

    (Ctl的意思Control,从sizeControl也可以明白这个变量的作用了)

    sizeCtl为0,代表数组未初始化, 且数组的初始容量为16

    sizeCtl为正数,如果数组未初始化,那么其记录的是数组的初始容量,如果数组已经初始化,那么其记录的是数组的扩容阈值(数组的初始容量*0.75【加载因子】)

    sizeCtl为-1,表示数组正在进行初始化,如果为-N则表示当前正有N-1个线程进行扩容操作;

    sizeCtl小于0,并且不是-1,表示数组正在扩容, -(1+n),表示此时有n个线程正在共同完成数组的扩容操作

  4. sun.misc.Unsafe U
    在ConcurrentHashMapde的实现中可以看到大量的U.compareAndSwapXXXX的方法去修改ConcurrentHashMap的一些属性。这些方法实际上是利用了CAS算法保证了线程安全性,这是一种乐观策略,假设每一次操作都不会产生冲突,当且仅当冲突发生的时候再去尝试。而CAS操作依赖于现代处理器指令集,通过底层CMPXCHG指令实现。CAS(V,O,N)核心思想为:若当前变量实际值V与期望的旧值O相同,则表明该变量没被其他线程进行修改,因此可以安全的将新值N赋值给变量;若当前变量实际值V与期望的旧值O不相同,则表明该变量已经被其他线程做了处理,此时将新值N赋给变量操作就是不安全的,在进行重试。而在大量的同步组件和并发容器的实现中使用CAS是通过sun.misc.Unsafe类实现的,该类提供了一些可以直接操控内存和线程的底层操作,可以理解为java中的“指针”。该成员变量的获取是在静态代码块中:

    1
    2
    3
    4
    5
    6
    7
    8
    static {
    try {
    U = sun.misc.Unsafe.getUnsafe();
    .......
    } catch (Exception e) {
    throw new Error(e);
    }
    }

ConcurrentHashMap中关键内部类

  1. Node
    Node类实现了Map.Entry接口,主要存放key-value对,并且具有next域

    1
    2
    3
    4
    5
    6
    7
    static class Node<K,V> implements Map.Entry<K,V> {
    final int hash;
    final K key;
    volatile V val;
    volatile Node<K,V> next;
    ......
    }

另外可以看出很多属性都是用volatile进行修饰的,也就是为了保证内存可见性。

  1. TreeNode
    树节点,继承于承载数据的Node类。而红黑树的操作是针对TreeBin类的,从该类的注释也可以看出,也就是TreeBin会将TreeNode进行再一次封装

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    **
    * Nodes for use in TreeBins
    */
    static final class TreeNode<K,V> extends Node<K,V> {
    TreeNode<K,V> parent; // red-black tree links
    TreeNode<K,V> left;
    TreeNode<K,V> right;
    TreeNode<K,V> prev; // needed to unlink next upon deletion
    boolean red;
    ......
    }
  2. TreeBin
    这个类并不负责包装用户的key、value信息,而是包装的很多TreeNode节点。实际的ConcurrentHashMap“数组”中,存放的是TreeBin对象,而不是TreeNode对象。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    static final class TreeBin<K,V> extends Node<K,V> {
    TreeNode<K,V> root;
    volatile TreeNode<K,V> first;
    volatile Thread waiter;
    volatile int lockState;
    // values for lockState
    static final int WRITER = 1; // set while holding write lock
    static final int WAITER = 2; // set when waiting for write lock
    static final int READER = 4; // increment value for setting read lock
    ......
    }
  3. ForwardingNode
    在扩容时才会出现的特殊节点,其key,value,hash全部为null。并拥有nextTable指针引用新的table数组。

    1
    2
    3
    4
    5
    6
    7
    8
    static final class ForwardingNode<K,V> extends Node<K,V> {
    final Node<K,V>[] nextTable;
    ForwardingNode(Node<K,V>[] tab) {
    super(MOVED, null, null, null);
    this.nextTable = tab;
    }
    .....
    }

CAS关键操作

在上面我们提及到在ConcurrentHashMap中会大量使用CAS修改它的属性和一些操作。因此,在理解ConcurrentHashMap的方法前我们需要了解下面几个常用的利用CAS算法来保障线程安全的操作。

  1. tabAt

    1
    2
    3
    static final <K,V> Node<K,V> tabAt(Node<K,V>[] tab, int i) {
    return (Node<K,V>)U.getObjectVolatile(tab, ((long)i << ASHIFT) + ABASE);
    }

    该方法用来获取table数组中索引为i的Node元素。

  2. casTabAt

    1
    2
    3
    4
    static final <K,V> boolean casTabAt(Node<K,V>[] tab, int i,
    Node<K,V> c, Node<K,V> v) {
    return U.compareAndSwapObject(tab, ((long)i << ASHIFT) + ABASE, c, v);
    }

    利用CAS操作设置table数组中索引为i的元素

  3. setTabAt

    1
    2
    3
    static final <K,V> void setTabAt(Node<K,V>[] tab, int i, Node<K,V> v) {
    U.putObjectVolatile(tab, ((long)i << ASHIFT) + ABASE, v);
    }

    该方法用来设置table数组中索引为i的元素

容器初始化方法

实例构造器方法

在jdk8的ConcurrentHashMap中一共有5个构造方法,这四个构造方法中都没有对内部的数组做初始化, 只是对一些变量的初始值做了处理

jdk8的ConcurrentHashMap的数组初始化是在第一次添加元素时完成

1
2
3
4
5
6
7
8
9
10
// 1. 构造一个空的map,即table数组还未初始化,初始化放在第一次插入数据时,默认大小为16
ConcurrentHashMap()
// 2. 给定map的大小
ConcurrentHashMap(int initialCapacity)
// 3. 给定一个map
ConcurrentHashMap(Map<? extends K, ? extends V> m)
// 4. 给定map的大小以及加载因子
ConcurrentHashMap(int initialCapacity, float loadFactor)
// 5. 给定map大小,加载因子以及并发度(预计同时操作数据的线程)
ConcurrentHashMap(int initialCapacity,float loadFactor, int concurrencyLevel)
  • 无参构造方法
1
2
3
//没有维护任何变量的操作,如果调用该方法,数组长度默认是16
public ConcurrentHashMap() {
}
  • 带参构造方法
1
2
3
4
5
6
7
8
9
10
11
12
13
//传递进来一个初始容量,ConcurrentHashMap会基于这个值计算一个比这个值大的2的幂次方数作为初始容量
// 比如你传32,右移1位(除以2)得到16,最后的sizeCtl = (32 + 16 + 1)→ 向上取最近的2的n次方 = 49 → 向上取最近的2的n次方 = 64
public ConcurrentHashMap(int initialCapacity) {
//1. 小于0直接抛异常
if (initialCapacity < 0)
throw new IllegalArgumentException();
//2. 判断是否超过了允许的最大值,超过了话则取最大值,否则再对该值进一步处理
int cap = ((initialCapacity >= (MAXIMUM_CAPACITY >>> 1)) ?
MAXIMUM_CAPACITY :
tableSizeFor(initialCapacity + (initialCapacity >>> 1) + 1));
//3. 赋值给sizeCtl
this.sizeCtl = cap;
}

注意,调用这个方法,得到的初始容量和我们之前讲的HashMap以及jdk7的ConcurrentHashMap不同,即使你传递的是一个2的幂次方数,该方法计算出来的初始容量依然是比这个值大的2的幂次方数

  • tableSizeFor源码
1
2
3
4
5
6
7
8
9
10
11
12
13
/**
* Returns a power of two table size for the given desired capacity.
* See Hackers Delight, sec 3.2
*/
private static final int tableSizeFor(int c) {
int n = c - 1;
n |= n >>> 1;
n |= n >>> 2;
n |= n >>> 4;
n |= n >>> 8;
n |= n >>> 16;
return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : n + 1;
}

通过注释就很清楚了,该方法会将调用构造器方法时指定的大小转换成一个2的幂次方数,也就是说ConcurrentHashMap的大小一定是2的幂次方,比如,当指定大小为18时,为了满足2的幂次方特性,实际上concurrentHashMapd的大小为2的5次方(32)。

另外,需要注意的是,调用构造器方法的时候并未构造出table数组(可以理解为ConcurrentHashMap的数据容器),只是算出table数组的长度,当第一次向ConcurrentHashMap插入数据的时候才真正的完成初始化创建table数组的工作

  • 带加载因子构造方法
1
2
3
4
//调用四个参数的构造
public ConcurrentHashMap(int initialCapacity, float loadFactor) {
this(initialCapacity, loadFactor, 1);
}
  • 给定一个Map构造方法
1
2
3
4
5
6
//基于一个Map集合,构建一个ConcurrentHashMap
//初始容量为16
public ConcurrentHashMap(Map<? extends K, ? extends V> m) {
this.sizeCtl = DEFAULT_CAPACITY;
putAll(m);
}
  • 给定Map大小,加载因子以及并发度构造方法
1
2
3
4
5
6
7
8
9
10
11
12
//计算一个大于或者等于给定的容量值,该值是2的幂次方数作为初始容量
public ConcurrentHashMap(int initialCapacity,
float loadFactor, int concurrencyLevel) {
if (!(loadFactor > 0.0f) || initialCapacity < 0 || concurrencyLevel <= 0)
throw new IllegalArgumentException();
if (initialCapacity < concurrencyLevel) // Use at least as many bins
initialCapacity = concurrencyLevel; // as estimated threads
long size = (long)(1.0 + (long)initialCapacity / loadFactor);
int cap = (size >= (long)MAXIMUM_CAPACITY) ?
MAXIMUM_CAPACITY : tableSizeFor((int)size);
this.sizeCtl = cap;
}

initTable方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
private final Node<K,V>[] initTable() {
Node<K,V>[] tab; int sc;
//cas+自旋,保证线程安全,对数组进行初始化操作
while ((tab = table) == null || tab.length == 0) {
//如果sizeCtl的值(-1)小于0,说明此时正在初始化或者说正在扩容, 让出cpu
if ((sc = sizeCtl) < 0)
Thread.yield(); // lost initialization race; just spin
//cas修改sizeCtl的值为-1,修改成功,进行数组初始化,失败,继续自旋
else if (U.compareAndSwapInt(this, SIZECTL, sc, -1)) {
try {
// 双重检查
if ((tab = table) == null || tab.length == 0) {
//n的值: sizeCtl为0,取默认长度16, 否则取sizeCtl的值
int n = (sc > 0) ? sc : DEFAULT_CAPACITY;
@SuppressWarnings("unchecked")
//基于初始长度,构建数组对象
Node<K,V>[] nt = (Node<K,V>[])new Node<?,?>[n];
//传给成员变量table: tansient volatile Node<K, V>[] table;
table = tab = nt;
//计算扩容阈值,并赋值给sc 【sc = 0.75n】
sc = n - (n >>> 2);
}
} finally {
//将扩容阈值,赋值给sizeCtl
// 此时的sizeCtl就记录了扩容阈值了
sizeCtl = sc;
}
break;
}
}
return tab;
}
  • 代码逻辑

由于有可能存在一个情况是多个线程同时走到这个方法中,为了保证能够正确初始化:

  1. 首先通过if进行判断,若当前已经有一个线程正在初始化即sizeCtl值变为-1,这个时候其他线程在If判断为true从而调用Thread.yield()让出CPU时间片
  2. 正在进行初始化的线程会调用U.compareAndSwapInt方法将sizeCtl改为-1即正在初始化的状态。

如果选择是无参的构造器的话,这里在new Node数组的时候会使用默认大小为DEFAULT_CAPACITY(16),然后乘以加载因子0.75为12,也就是说数组的可用大小为12。

添加(put)方法

源码

1
2
3
public V put(K key, V value) {
return putVal(key, value, false);
}

它的本质是调用putVal方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
final V putVal(K key, V value, boolean onlyIfAbsent) {
//如果有空值或者空键,直接抛异常
if (key == null || value == null) throw new NullPointerException();
//基于key计算hash值,并进行一定的扰动
//这个值一定为一个正数,方便后面添加元素判断该节点的类型
int hash = spread(key.hashCode());
//记录某个桶上元素的个数,如果超过8个,会转成红黑树
int binCount = 0;
for (Node<K,V>[] tab = table;;) {
Node<K,V> f; int n, i, fh;
//如果数组还未初始化,先对数组进行初始化
if (tab == null || (n = tab.length) == 0)
tab = initTable();
//如果hash计算得到的桶位置没有元素,利用cas将元素添加
// (tabAt方法用于获取角标对应的值)
else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) {
//cas+自旋(和外侧的for构成自旋循环),保证元素添加安全
if (casTabAt(tab, i, null,
new Node<K,V>(hash, key, value, null)))
break; // no lock when adding to empty bin
}
//如果hash计算得到的桶位置元素的hash值为MOVED(-1),证明正在扩容,那么协助扩容
//(这里涉及到了多线程的协助扩容相关知识点)
// 第一次初始化肯定是不走这里的
else if ((fh = f.hash) == MOVED)
tab = helpTransfer(tab, f);
//第一次初始化会走这个分支
else {
//hash计算的桶位置元素不为空,且当前没有处于扩容操作,进行元素添加
V oldVal = null;
//对当前桶进行加锁,保证线程安全,执行元素添加操作
synchronized (f) {
// 防止树化之后 元素位置
if (tabAt(tab, i) == f) {
// 当前为链表,在链表中插入新的键值对
if (fh >= 0) {
binCount = 1;
// 循环遍历链表
for (Node<K,V> e = f;; ++binCount) {
K ek;
// hash值一样
if (e.hash == hash &&
((ek = e.key) == key ||
(ek != null && key.equals(ek)))) {
oldVal = e.val;
if (!onlyIfAbsent)
//旧值覆盖掉
e.val = value;
break;
}
// 尾插到链表
Node<K,V> pred = e;
if ((e = e.next) == null) {
pred.next = new Node<K,V>(hash, key,
value, null);
break;
}
}
}
//当前为红黑树,将新的键值对插入到红黑树中
else if (f instanceof TreeBin) {
Node<K,V> p;
binCount = 2;
if ((p = ((TreeBin<K,V>)f).putTreeVal(hash, key,
value)) != null) {
oldVal = p.val;
if (!onlyIfAbsent)
p.val = value;
}
}
}
}
// 插入完键值对后再根据实际大小看是否需要转换成红黑树
if (binCount != 0) {
//链表长度大于/等于8,将链表转成红黑树
//ps:并不是大于8了,就一定会树化,在树化前再进行一次判断,如果是小于64的,则不会树化,而是扩容
if (binCount >= TREEIFY_THRESHOLD)
treeifyBin(tab, i);
//如果是重复键,直接将旧值返回
if (oldVal != null)
return oldVal;
break;
}
}
}
//添加的是新元素,维护集合长度,并判断是否要进行扩容操作(根据临界值(实际大小*加载因子)与实际大小进行判断)
addCount(1L, binCount);
return null;
}

代码细节 & 逻辑分析

下图为ConcurrentHashMap的数据结构形式,为一个哈希桶数组;

ConcurrentHashMap散列桶数组结构示意图

如果不出现哈希冲突的时候,每个元素均匀的分布在哈希桶数组中。当出现哈希冲突的时候,是标准的链地址的解决方式,将hash值相同的节点构成链表的形式,称为“拉链法”。

另外,在1.8版本中为了防止拉链过长,当链表的长度大于8(其实是大于64,在8 - 64之间只会扩容)的时候会将链表转换成红黑树。table数组中的每个元素实际上是单链表的头结点或者红黑树的根节点。当插入键值对时首先应该定位到要插入的桶,即插入table数组的索引i处。

引申出来一个问题:如何计算得出索引?

回答:通过key的HashCode值

如何计算呢?

  • spread()重哈希,以减小Hash冲突

对于一个hash表来说,hash值分散的不够均匀的话会大大增加哈希冲突的概率,从而影响到hash表的性能。

因此通过spread方法进行了一次重hash从而大大减小哈希冲突的可能性

1
2
3
4
5
static final int spread(int h) {
// HASH_BITS为0x7FFFFFFF,是除了首位为0,其余都是1的十六进制数;
// 首位为0表示为正数,这是最大的整形数int
return (h ^ (h >>> 16)) & HASH_BITS;
}

该方法主要是将key的hashCode的低16位于高16位进行异或运算,这样不仅能够使得hash值能够分散能够均匀减小hash冲突的概率,另外只用到了异或运算,在性能开销上也能兼顾,做到平衡的trade-off。

  • 初始化table

这里会判断table是否是经过初始化的,没有的话,就调用initTable进行初始化;

  • 判断是否正在扩容

如果当前节点不为null,且该节点为特殊节点(forwardingNode)的话,就说明当前concurrentHashMap正在进行扩容操作,关于扩容操作,之后会详细讲述。

那么怎样确定当前的这个Node是不是特殊的节点了?是通过判断该节点的hash值是不是等于-1(MOVED),代码为(fh = f.hash) == MOVED

1
static final int MOVED     = -1; // hash for forwarding nodes
  • 图解流程

put方法图解


取出(get)方法

源码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
public V get(Object key) {
Node<K,V>[] tab; Node<K,V> e, p; int n, eh; K ek;
// 1. 重hash
int h = spread(key.hashCode());
if ((tab = table) != null && (n = tab.length) > 0 &&
(e = tabAt(tab, (n - 1) & h)) != null) {
// 2. table[i]桶节点的key与查找的key相同,则直接返回
if ((eh = e.hash) == h) {
if ((ek = e.key) == key || (ek != null && key.equals(ek)))
return e.val;
}
// 3. 当前节点hash小于0说明为树节点,在红黑树中查找即可
else if (eh < 0)
return (p = e.find(h, key)) != null ? p.val : null;
while ((e = e.next) != null) {
//4. 从链表中查找,查找到则返回该节点的value,否则就返回null即可
if (e.hash == h &&
((ek = e.key) == key || (ek != null && key.equals(ek))))
return e.val;
}
}
return null;
}

代码逻辑

首先先看当前的hash桶数组节点即table[i]是否为查找的节点,若是则直接返回;若不是,则继续再看当前是不是树节点?通过看节点的hash值是否为小于0,如果小于0则为树节点。如果是树节点在红黑树中查找节点;如果不是树节点,那就只剩下为链表的形式的一种可能性了,就向后遍历查找节点,若查找到则返回节点的value即可,若没有找到就返回null。

  • 图解

get方法图解

扩容( transfer)方法

源码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
private final void transfer(Node<K,V>[] tab, Node<K,V>[] nextTab) {
int n = tab.length, stride;
//如果是多cpu,那么每个线程划分任务,最小任务量是16个桶位的迁移
if ((stride = (NCPU > 1) ? (n >>> 3) / NCPU : n) < MIN_TRANSFER_STRIDE)
stride = MIN_TRANSFER_STRIDE; // subdivide range
//如果是扩容线程,此时新数组为null
if (nextTab == null) { // initiating
try {
@SuppressWarnings("unchecked")
//两倍扩容创建新数组
Node<K,V>[] nt = (Node<K,V>[])new Node<?,?>[n << 1];
nextTab = nt;
} catch (Throwable ex) { // try to cope with OOME
sizeCtl = Integer.MAX_VALUE;
return;
}
// nextTable记录新的数组
nextTable = nextTab;
//记录线程开始迁移的桶位,从后往前迁移
//tansferIndex记录当前旧数组的size
transferIndex = n;
}
//记录新数组的末尾
int nextn = nextTab.length;
//已经迁移的桶位,会用这个节点占位(这个节点的hash值为-1--MOVED)
ForwardingNode<K,V> fwd = new ForwardingNode<K,V>(nextTab);
boolean advance = true;
boolean finishing = false; // to ensure sweep before committing nextTab
for (int i = 0, bound = 0;;) {
Node<K,V> f; int fh;
//进行迁移任务的分配工作
while (advance) {
int nextIndex, nextBound;
//i:记录当前正在迁移桶位的索引值
//bound/nextBound:记录下一次任务迁移的开始桶位
//--i >= bound 成立表示当前线程分配的迁移任务还没有完成
if (--i >= bound || finishing)
advance = false;
//没有元素需要迁移 -- 后续会去将扩容线程数减1,并判断扩容是否完成
else if ((nextIndex = transferIndex) <= 0) {
i = -1;
advance = false;
}
//计算下一次任务迁移的开始桶位,并将这个值赋值给nextBound
else if (U.compareAndSwapInt
(this, TRANSFERINDEX, nextIndex,
nextBound = (nextIndex > stride ?
nextIndex - stride : 0))) {
bound = nextBound;
i = nextIndex - 1;
advance = false;
}
}
//如果没有更多的需要迁移的桶位,就进入该if
if (i < 0 || i >= n || i + n >= nextn) {
int sc;
//扩容结束后,保存新数组,并重新计算扩容阈值,赋值给sizeCtl
if (finishing) {
nextTable = null;
table = nextTab;
sizeCtl = (n << 1) - (n >>> 1);
return;
}
//扩容任务线程数减1
if (U.compareAndSwapInt(this, SIZECTL, sc = sizeCtl, sc - 1)) {
//判断当前所有扩容任务线程是否都执行完成
// != 表示没扩容完, == 表示扩容完;
if ((sc - 2) != resizeStamp(n) << RESIZE_STAMP_SHIFT)
return;
//所有扩容线程都执行完,标识结束
finishing = advance = true;
i = n; // recheck before commit
}
}
//当前迁移的桶位没有元素,直接在该位置添加一个fwd节点
else if ((f = tabAt(tab, i)) == null)
advance = casTabAt(tab, i, null, fwd);
//当前节点已经被迁移
else if ((fh = f.hash) == MOVED)
advance = true; // already processed
else {
//当前节点需要迁移,加锁迁移,保证多线程安全
//此处迁移逻辑和jdk7的ConcurrentHashMap相同,不再赘述
synchronized (f) {
if (tabAt(tab, i) == f) {
Node<K,V> ln, hn;
if (fh >= 0) {
// fh >= 0:处理当前节点为链表的头结点的情况,构造两个链表,一个是原链表 另一个是原链表的反序排列
int runBit = fh & n;
Node<K,V> lastRun = f;
for (Node<K,V> p = f.next; p != null; p = p.next) {
int b = p.hash & n;
if (b != runBit) {
runBit = b;
lastRun = p;
}
}
if (runBit == 0) {
ln = lastRun;
hn = null;
}
else {
hn = lastRun;
ln = null;
}
for (Node<K,V> p = f; p != lastRun; p = p.next) {
int ph = p.hash; K pk = p.key; V pv = p.val;
if ((ph & n) == 0)
ln = new Node<K,V>(ph, pk, pv, ln);
else
hn = new Node<K,V>(ph, pk, pv, hn);
}
//在nextTable的i位置上插入一个链表
setTabAt(nextTab, i, ln);
//在nextTable的i+n的位置上插入另一个链表
setTabAt(nextTab, i + n, hn);
//在table的i位置上插入forwardNode节点 表示已经处理过该节点
setTabAt(tab, i, fwd);
//设置advance为true 返回到上面的while循环中 就可以执行i--操作
advance = true;
}
// 处理当前节点是TreeBin时的情况,操作和上面的类似
else if (f instanceof TreeBin) {
TreeBin<K,V> t = (TreeBin<K,V>)f;
TreeNode<K,V> lo = null, loTail = null;
TreeNode<K,V> hi = null, hiTail = null;
int lc = 0, hc = 0;
for (Node<K,V> e = t.first; e != null; e = e.next) {
int h = e.hash;
TreeNode<K,V> p = new TreeNode<K,V>
(h, e.key, e.val, null, null);
if ((h & n) == 0) {
if ((p.prev = loTail) == null)
lo = p;
else
loTail.next = p;
loTail = p;
++lc;
}
else {
if ((p.prev = hiTail) == null)
hi = p;
else
hiTail.next = p;
hiTail = p;
++hc;
}
}
ln = (lc <= UNTREEIFY_THRESHOLD) ? untreeify(lo) :
(hc != 0) ? new TreeBin<K,V>(lo) : t;
hn = (hc <= UNTREEIFY_THRESHOLD) ? untreeify(hi) :
(lc != 0) ? new TreeBin<K,V>(hi) : t;
setTabAt(nextTab, i, ln);
setTabAt(nextTab, i + n, hn);
setTabAt(tab, i, fwd);
advance = true;
}
}
}
}
}
}

代码流程/细节

代码逻辑请看注释,整个扩容操作分为两个部分

第一部分是构建一个nextTable,它的容量是原来的两倍,这个操作是单线程完成的。新建table数组的代码为:Node<K,V>[] nt = (Node<K,V>[])new Node<?,?>[n << 1],在原容量大小的基础上右移一位。

第二个部分就是将原来table中的元素复制到nextTable中,主要是遍历复制的过程。
根据运算得到当前遍历的数组的位置i,然后利用tabAt方法获得i位置的元素再进行判断:

  1. 如果这个位置为空,就在原table中的i位置放入forwardNode节点,这个也是触发并发扩容的关键点;
  2. 如果这个位置是Node节点(fh>=0),如果它是一个链表的头节点,就构造一个反序链表,把他们分别放在nextTable的i和i+n的位置上
  3. 如果这个位置是TreeBin节点(fh<0),也做一个反序处理,并且判断是否需要untreefi,把处理的结果分别放在nextTable的i和i+n的位置上
  4. 遍历过所有的节点以后就完成了复制工作,这时让nextTable作为新的table,并且更新sizeCtl为新容量的0.75倍 ,完成扩容。

ConcurrentHashMap扩容示意图

  • 图解流程

transfer方法图解

协助扩容(helpTransfer)方法

putVal处,有helpTransfer方法,

1
2
3
//发现此处为fwd节点,协助扩容,扩容结束后,再循环回来添加元素
else if ((fh = f.hash) == MOVED)
tab = helpTransfer(tab, f);
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
final Node<K,V>[] helpTransfer(Node<K,V>[] tab, Node<K,V> f) {
Node<K,V>[] nextTab; int sc;
if (tab != null && (f instanceof ForwardingNode) &&
(nextTab = ((ForwardingNode<K,V>)f).nextTable) != null) {
int rs = resizeStamp(tab.length);
while (nextTab == nextTable && table == tab &&
(sc = sizeCtl) < 0) {
if ((sc >>> RESIZE_STAMP_SHIFT) != rs || sc == rs + 1 ||
sc == rs + MAX_RESIZERS || transferIndex <= 0)
break;
if (U.compareAndSwapInt(this, SIZECTL, sc, sc + 1)) {
//扩容,传递一个不是null的nextTab
transfer(tab, nextTab);
break;
}
}
return nextTab;
}
return table;
}

集合长度累计方式

addCount方法

① CounterCell数组不为空,优先利用数组中的CounterCell记录数量

② 如果数组为空,尝试对baseCount进行累加,失败后,会执行fullAddCount逻辑

③ 如果是添加元素操作,会继续判断是否需要扩容

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
private final void addCount(long x, int check) {
CounterCell[] as; long b, s;
//当CounterCell数组不为空,则优先利用数组中的CounterCell记录数量
//或者当baseCount的累加操作失败,会利用数组中的CounterCell记录数量
if ((as = counterCells) != null ||
!U.compareAndSwapLong(this, BASECOUNT, b = baseCount, s = b + x)) {
CounterCell a; long v; int m;
//标识是否有多线程竞争
boolean uncontended = true;
//当as数组为空
//或者当as长度为0
//或者当前线程对应的as数组桶位的元素为空
//或者当前线程对应的as数组桶位不为空,但是累加失败
if (as == null || (m = as.length - 1) < 0 ||
(a = as[ThreadLocalRandom.getProbe() & m]) == null ||
!(uncontended =
U.compareAndSwapLong(a, CELLVALUE, v = a.value, v + x))) {
//以上任何一种情况成立,都会进入该方法,传入的uncontended是false
fullAddCount(x, uncontended);
return;
}
if (check <= 1)
return;
//计算元素个数
s = sumCount();
}
if (check >= 0) {
Node<K,V>[] tab, nt; int n, sc;
//当元素个数达到扩容阈值
//并且数组不为空
//并且数组长度小于限定的最大值
//满足以上所有条件,执行扩容
while (s >= (long)(sc = sizeCtl) && (tab = table) != null &&
(n = tab.length) < MAXIMUM_CAPACITY) {
//这个是一个很大的正数
int rs = resizeStamp(n);
//sc小于0,说明有线程正在扩容,那么会协助扩容
if (sc < 0) {
//扩容结束或者扩容线程数达到最大值或者扩容后的数组为null或者没有更多的桶位需要转移,结束操作
if ((sc >>> RESIZE_STAMP_SHIFT) != rs || sc == rs + 1 ||
sc == rs + MAX_RESIZERS || (nt = nextTable) == null ||
transferIndex <= 0)
break;
//扩容线程加1,成功后,进行协助扩容操作
if (U.compareAndSwapInt(this, SIZECTL, sc, sc + 1))
//协助扩容,newTable不为null
transfer(tab, nt);
}
//没有其他线程在进行扩容,达到扩容阈值后,给sizeCtl赋了一个很大的负数
//1+1=2 --》 代表此时有一个线程在扩容

//rs << RESIZE_STAMP_SHIFT)是一个很大的负数
else if (U.compareAndSwapInt(this, SIZECTL, sc,
(rs << RESIZE_STAMP_SHIFT) + 2))
//扩容,newTable为null
transfer(tab, null);
s = sumCount();
}
}
}

fullAddCount方法

① 当CounterCell数组不为空,优先对CounterCell数组中的CounterCell的value累加

② 当CounterCell数组为空,会去创建CounterCell数组,默认长度为2,并对数组中的CounterCell的value累加

③ 当数组为空,并且此时有别的线程正在创建数组,那么尝试对baseCount做累加,成功即返回,否则自旋

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
private final void fullAddCount(long x, boolean wasUncontended) {
int h;
//获取当前线程的hash值
if ((h = ThreadLocalRandom.getProbe()) == 0) {
ThreadLocalRandom.localInit(); // force initialization
h = ThreadLocalRandom.getProbe();
wasUncontended = true;
}
//标识是否有冲突,如果最后一个桶不是null,那么为true
boolean collide = false; // True if last slot nonempty
for (;;) {
CounterCell[] as; CounterCell a; int n; long v;
//数组不为空,优先对数组中CouterCell的value累加
if ((as = counterCells) != null && (n = as.length) > 0) {
//线程对应的桶位为null
if ((a = as[(n - 1) & h]) == null) {
if (cellsBusy == 0) { // Try to attach new Cell
//创建CounterCell对象
CounterCell r = new CounterCell(x); // Optimistic create
//利用CAS修改cellBusy状态为1,成功则将刚才创建的CounterCell对象放入数组中
if (cellsBusy == 0 &&
U.compareAndSwapInt(this, CELLSBUSY, 0, 1)) {
boolean created = false;
try { // Recheck under lock
CounterCell[] rs; int m, j;
//桶位为空, 将CounterCell对象放入数组
if ((rs = counterCells) != null &&
(m = rs.length) > 0 &&
rs[j = (m - 1) & h] == null) {
rs[j] = r;
//表示放入成功
created = true;
}
} finally {
cellsBusy = 0;
}
if (created) //成功退出循环
break;
//桶位已经被别的线程放置了已给CounterCell对象,继续循环
continue; // Slot is now non-empty
}
}
collide = false;
}
//桶位不为空,重新计算线程hash值,然后继续循环
else if (!wasUncontended) // CAS already known to fail
wasUncontended = true; // Continue after rehash
//重新计算了hash值后,对应的桶位依然不为空,对value累加 这里的x = 1
//成功则结束循环
//失败则继续下面判断
else if (U.compareAndSwapLong(a, CELLVALUE, v = a.value, v + x))
break;
//数组被别的线程改变了,或者数组长度超过了可用cpu大小,重新计算线程hash值,否则继续下一个判断
else if (counterCells != as || n >= NCPU)
collide = false; // At max size or stale
//当没有冲突,修改为有冲突,并重新计算线程hash,继续循环
else if (!collide)
collide = true;
//如果CounterCell的数组长度没有超过cpu核数,对数组进行两倍扩容
//并继续循环
else if (cellsBusy == 0 &&
U.compareAndSwapInt(this, CELLSBUSY, 0, 1)) {
try {
// 下面进行的是对counterCells数组进行初始化
if (counterCells == as) {// Expand table unless stale
CounterCell[] rs = new CounterCell[n << 1];
for (int i = 0; i < n; ++i)
rs[i] = as[i];
counterCells = rs;
}
} finally {
cellsBusy = 0;
}
collide = false;
continue; // Retry with expanded table
}
h = ThreadLocalRandom.advanceProbe(h);
}
//CounterCell数组为空,并且没有线程在创建数组,修改标记,并创建数组
else if (cellsBusy == 0 && counterCells == as &&
U.compareAndSwapInt(this, CELLSBUSY, 0, 1)) {
boolean init = false;
try { // Initialize table
if (counterCells == as) {
CounterCell[] rs = new CounterCell[2];
rs[h & 1] = new CounterCell(x);
counterCells = rs;
init = true;
}
} finally {
cellsBusy = 0;
}
if (init)
break;
}
//数组为空,并且有别的线程在创建数组,那么尝试对baseCount做累加,成功就退出循环,失败就继续循环
else if (U.compareAndSwapLong(this, BASECOUNT, v = baseCount, v + x))
break; // Fall back on using base
}
}
  • 图解流程

image-20210529160604963

集合长度获取方式

size方法

1
2
3
4
5
6
public int size() {
long n = sumCount();
return ((n < 0L) ? 0 :
(n > (long)Integer.MAX_VALUE) ? Integer.MAX_VALUE :
(int)n);
}

sumCount方法

1
2
3
4
5
6
7
8
9
10
11
12
13
final long sumCount() {
CounterCell[] as = counterCells; CounterCell a;
//获取baseCount的值
long sum = baseCount;
if (as != null) {
//遍历CounterCell数组,累加每一个CounterCell的value值
for (int i = 0; i < as.length; ++i) {
if ((a = as[i]) != null)
sum += a.value;
}
}
return sum;
}

注意:这个方法并不是线程安全的

ThreadLocal

ThreadLocal - 一个Map的key

概述

在多线程编程中通常解决线程安全的问题我们会利用synchronzed或者lock控制线程对临界区资源的同步顺序从而解决线程安全的问题,但是这种加锁的方式会让未获取到锁的线程进行阻塞等待,很显然这种方式的时间效率并不是很好。

线程安全问题的核心在于多个线程会对同一个临界区共享资源进行操作,那么,如果每个线程都使用自己的“共享资源”,各自使用各自的,又互相不影响到彼此即让多个线程间达到隔离的状态,这样就不会出现线程安全的问题。

ThreadLocal是JDK包提供的,它提供线程本地变量,如果创建一个ThreadLocal变量,那么访问这个变量的每个线程都会有这个变量的一个副本,在实际多线程操作的时候,操作的是自己本地内存中的变量,从而规避了线程安全问题,如下图所示

img

ThreadLocal这个类名可以顾名思义的进行理解,表示线程的“本地变量”,即每个线程都拥有该变量副本,达到人手一份的效果,各用各的这样就可以避免共享资源的竞争

  • 注意点

一个Thread包含一个ThreadLocalMap,但可以有多个ThreadLocal

因为ThreadLocal是Map的key,而我们存进去的数据是Map的value

如果感觉有些模糊,不知道什么意思,我们通过学习原理就可以明白了

实现原理

学习实现原理主要根据:set get remove 三个方法入手

set方法

set方法设置在当前线程中threadLocal变量的值

源码
1
2
3
4
5
6
7
8
9
10
11
12
public void set(T value) {
//1. 获取当前线程实例对象
Thread t = Thread.currentThread();
//2. 通过当前线程实例获取到ThreadLocalMap对象
ThreadLocalMap map = getMap(t);
if (map != null)
//3.如果Map不为null,则以当前threadLocl实例为key,值为value进行存入
map.set(this, value);
else
//4.map为null,则新建ThreadLocalMap并存入value
createMap(t, value);
}
代码流程/细节

方法的逻辑很清晰,具体请看上面的注释。通过源码我们知道value是存放在了ThreadLocalMap里了,当前先把它理解为一个普普通通的map即可,也就是说,数据value是真正的存放在了ThreadLocalMap这个容器中了,并且是以当前threadLocal实例为key

先简单的看下ThreadLocalMap是什么,有个简单的认识就好,下面会具体说的。

首先ThreadLocalMap是怎样来的?源码很清楚,是通过getMap(t)进行获取:

1
2
3
ThreadLocalMap getMap(Thread t) {
return t.threadLocals;
}

该方法直接返回的就是当前线程对象t的一个成员变量threadLocals:

1
2
3
/* ThreadLocal values pertaining to this thread. This map is maintained
* by the ThreadLocal class. */
ThreadLocal.ThreadLocalMap threadLocals = null;

也就是说ThreadLocalMap的引用是作为Thread的一个成员变量,被Thread进行维护的

回过头再来看看set方法,当map为Null的时候会通过createMap(t,value)方法:

1
2
3
void createMap(Thread t, T firstValue) {
t.threadLocals = new ThreadLocalMap(this, firstValue);
}

该方法就是new一个ThreadLocalMap实例对象,然后同样以当前threadLocal实例作为key,值为value存放到threadLocalMap中,然后将当前线程对象的threadLocals赋值为threadLocalMap

图解流程

image-20210529172329653

get方法

源码

get方法是获取当前线程中threadLocal变量的值

  • get方法源码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public T get() {
//1. 获取当前线程的实例对象
Thread t = Thread.currentThread();
//2. 获取当前线程的threadLocalMap
ThreadLocalMap map = getMap(t);
if (map != null) {
//3. 获取map中当前threadLocal实例为key的值的entry
ThreadLocalMap.Entry e = map.getEntry(this);
if (e != null) {
@SuppressWarnings("unchecked")
//4. 当前entitiy不为null的话,就返回相应的值value
T result = (T)e.value;
return result;
}
}
//5. 若map为null或者entry为null的话通过该方法初始化,并返回该方法返回的value
return setInitialValue();
}

通过代码,我们可以知道get其实是一个根据key查找value的方法,只是存储的Map,隐藏在当前Thread里面

  • setInitialValue方法源码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
private T setInitialValue() {
//protected T initialValue() {return null;}
T value = initialValue();
//获取当前线程
Thread t = Thread.currentThread();
//以当前线程作为key值,去查找对应的线程变量,找到对应的map
ThreadLocalMap map = getMap(t);
//如果map不为null,就直接添加本地变量,key为当前线程,值为添加的本地变量值
if (map != null)
map.set(this, value);
//如果map为null,说明首次添加,需要首先创建出对应的map
else
createMap(t, value);
return value;
}
代码流程/细节

通过当前线程thread实例获取到它所维护的threadLocalMap,然后以当前threadLocal实例为key获取该map中的键值对(Entry),若Entry不为null则返回Entry的value。如果获取threadLocalMap为null或者Entry为null的话,就以当前threadLocal为Key,value为null存入map后,并返回null

图解流程

get方法

remove方法

remove方法判断该当前线程对应的threadLocals变量是否为null,不为null就直接删除当前线程中指定的threadLocals变量

源码
1
2
3
4
5
6
7
public void remove() {
//1. 获取当前线程的threadLocalMap
ThreadLocalMap m = getMap(Thread.currentThread());
if (m != null)
//2. 从map中删除以当前threadLocal实例为key的键值对
m.remove(this);
}
代码流程/细节

删除数据是从map中删除数据,先获取与当前线程相关联的threadLocalMap然后从map中删除该threadLocal实例为key的键值对即可。

如下图所示:每个线程内部有一个名为threadLocals的成员变量,该变量的类型为ThreadLocal.ThreadLocalMap类型(类似于一个HashMap),其中的key为当前定义的ThreadLocal变量的this引用,value为我们使用set方法设置的值。每个线程的本地变量存放在自己的本地内存变量threadLocals中,如果当前线程一直不消亡,那么这些本地变量就会一直存在(所以可能会导致内存溢出),因此使用完毕需要将其remove掉。

img

图解流程

image-20210530164606712

ThreadLoacl底层细节

Entry数据结构

ThreadLocalMap是threadLocal一个静态内部类,和大多数容器一样内部维护了一个数组,同样的threadLocalMap内部维护了一个Entry类型的table数组。

1
2
3
4
5
6
/**
* The table, resized as necessary.
* table.length MUST always be a power of two
* table数组的长度必须为2的幂次方.
*/
private Entry[] table;
  • 内部源码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
/**
* 是继承自WeakReference的一个类,该类中实际存放的key是
* 指向ThreadLocal的弱引用和与之对应的value值(该value值
* 就是通过ThreadLocal的set方法传递过来的值)
* 由于是弱引用,当get方法返回null的时候意味着坑能引用
*/
static class Entry extends WeakReference<ThreadLocal<?>> {
/** value就是和ThreadLocal绑定的 */
Object value;

//k:ThreadLocal的引用,被传递给WeakReference的构造方法
Entry(ThreadLocal<?> k, Object v) {
super(k);
value = v;
}
}
//WeakReference构造方法(public class WeakReference<T> extends Reference<T> )
public WeakReference(T referent) {
super(referent); //referent:ThreadLocal的引用
}

//Reference构造方法
Reference(T referent) {
this(referent, null);//referent:ThreadLocal的引用
}

Reference(T referent, ReferenceQueue<? super T> queue) {
this.referent = referent;
this.queue = (queue == null) ? ReferenceQueue.NULL : queue;
}
  • 细节

 在上面的代码中,我们可以看出,当前ThreadLocal的引用k被传递给WeakReference的构造函数,所以ThreadLocalMap中的key为ThreadLocal的弱引用

弱引用的相关知识在这

每个线程实例中可以通过threadLocals获取到threadLocalMap,而threadLocalMap实际上就是一个以threadLocal实例为key,任意对象为value的Entry数组。

因此:当我们为threadLocal变量赋值,实际上就是以当前threadLocal实例为key,值为value的Entry往这个threadLocalMap中存放

image-20210530172556140

这就可能会导致一个问题:内存泄漏(这里是初步涉及一下,后面再重点学习)

考虑这个ThreadLocal变量没有其他强依赖,如果当前线程还存在(比如说线程池,线程执行完一个任务之后不会被销毁,而是会回到线程池中),由于线程的ThreadLocalMap里面的key是弱引用,所以当前线程的ThreadLocalMap里面的ThreadLocal变量的弱引用在gc的时候就被回收,但是对应的value还是存在,即存在一条这样的链路:

Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value

而这个value是无法被回收的,这就可能造成内存泄漏(因为这个时候ThreadLocalMap会存在key为null但是value不为null的entry项)

解决办法:使用线程池去维护线程的创建和复用,或及时使用remove方法

set方法细节

散列表

理想状态下,散列表就是一个包含关键字的固定大小的数组,通过使用散列函数,将关键字映射到数组的不同位置。下面是理想散列表的一个示意图:

理想散列表的一个示意图

在理想状态下,哈希函数可以将关键字均匀的分散到数组的不同位置,不会出现两个关键字散列值相同(假设关键字数量小于数组的大小)的情况。但是在实际使用中,经常会出现多个关键字散列值相同的情况(被映射到数组的同一个位置),我们将这种情况称为散列冲突。

为了解决散列冲突,主要采用下面两种方式:

  • 分离链表法(separate chaining)
  • 开放定址法(open addressing)
分离链表法 与 开放定址法
  • 分离链表法

分散链表法使用链表解决冲突,将散列值相同的元素都保存到一个链表中。当查询的时候,首先找到元素所在的链表,然后遍历链表查找对应的元素,典型实现为hashMap,concurrentHashMap的拉链法。下面是一个示意图:

分离链表法示意图

  • 开放定址法

开放定址法不会创建链表,当关键字散列到的数组单元已经被另外一个关键字占用的时候,就会尝试在数组中寻找其他的单元,直到找到一个空的单元。探测数组空单元的方式有很多,这里介绍一种最简单的 —— 线性探测法。

线性探测法就是从冲突的数组单元开始,依次往后搜索空单元,如果到数组尾部,再从头开始搜索(环形查找)。如下图所示:

开放定址法示意图

ThreadLocalMap 中使用开放地址法来处理散列冲突

HashMap 中使用的分离链表法

究其原因在于:在 ThreadLocalMap 中的散列值分散的十分均匀,很少会出现冲突。并且 ThreadLocalMap 经常需要清除无用的对象,使用纯数组更加方便。

源码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
private void set(ThreadLocal<?> key, Object value) {

// We don't use a fast path as with get() because it is at
// least as common to use set() to create new entries as
// it is to replace existing ones, in which case, a fast
// path would fail more often than not.

Entry[] tab = table;
int len = tab.length;
//根据threadLocal的hashCode确定Entry应该存放的位置
int i = key.threadLocalHashCode & (len-1);

//采用开放地址法,hash冲突的时候使用线性探测
for (Entry e = tab[i];
e != null;
e = tab[i = nextIndex(i, len)]) {
ThreadLocal<?> k = e.get();
//覆盖旧Entry
if (k == key) {
e.value = value;
return;
}
//当key为null时,说明threadLocal外部强引用已经被释放掉,那么就无法
//再通过这个key获取threadLocalMap中对应的entry,这里就存在内存泄漏的可能性
if (k == null) {
//用当前插入的值替换掉这个key为null的“脏”entry
replaceStaleEntry(key, value, i);
return;
}
}
//新建entry并插入table中i处
tab[i] = new Entry(key, value);
int sz = ++size;
//插入后再次清除一些key为null的“脏”entry,如果大于阈值就需要扩容
if (!cleanSomeSlots(i, sz) && sz >= threshold)
rehash();
}
一些问题

ThreadLoacl的HashCode如何确定?

1
2
3
4
5
6
7
8
9
private final int threadLocalHashCode = nextHashCode();
private static final int HASH_INCREMENT = 0x61c88647;
private static AtomicInteger nextHashCode =new AtomicInteger();
/**
* Returns the next hash code.
*/
private static int nextHashCode() {
return nextHashCode.getAndAdd(HASH_INCREMENT);
}

从源码中我们可以清楚的看到threadLocal实例的hashCode是通过nextHashCode()方法实现的,该方法实际上总是用一个AtomicInteger加上0x61c88647来实现的;那么这个0x61c88647是什么呢?他其实是:Fibonacci Hashing,能够保证hash表的每个散列桶能够均匀的分布

怎样确定新值插入到哈希表中的位置?

1
2
//根据threadLocal的hashCode确定Entry应该存放的位置
int i = key.threadLocalHashCode & (len-1);

本质方法:利用当前key(即threadLocal实例)的hashcode与哈希表大小相与;

因为哈希表大小总是为2的幂次方,所以相与等同于一个取模的过程,这样就可以通过Key分配到具体的哈希桶中去。

采取相与而非与运算,因为位运算效率更高

怎样解决hash冲突?

1
2
3
4
5
6
/**
* Increment i modulo len.
*/
private static int nextIndex(int i, int len) {
return ((i + 1 < len) ? i + 1 : 0);
}

通过不断向后线性探测,到达末尾时再回到0重新开始,呈一个环形。

怎样解决“脏”Entry?

在分析threadLocal,threadLocalMap以及Entry的关系的时候,我们已经知道使用threadLocal有可能存在内存泄漏(对象创建出来后,在之后的逻辑一直没有使用该对象,但是垃圾回收器无法回收这个部分的内存),在源码中针对这种key为null的Entry称之为“stale entry”,直译为不新鲜的entry,我把它理解为“脏entry”,

针对这种情况,在set方法的for循环中寻找和当前Key相同的可覆盖entry的过程中通过replaceStaleEntry方法解决脏entry的问题。如果当前table[i]为null的话,直接插入新entry后也会通过cleanSomeSlots来解决脏entry的问题

如何进行扩容?

  • 扩容阈值threshold
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
private int threshold; // Default to 0
/**
* The initial capacity -- MUST be a power of two.
*/
// 初始大小为16
private static final int INITIAL_CAPACITY = 16;

ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) {
// 创建初始大小为16的threadLoaclMap
table = new Entry[INITIAL_CAPACITY];
int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);
table[i] = new Entry(firstKey, firstValue);
size = 1;
setThreshold(INITIAL_CAPACITY);
}

/**
* Set the resize threshold to maintain at worst a 2/3 load factor.
*/
private void setThreshold(int len) {
// 将threshold值设置成当前哈希数组长度的2/3
threshold = len * 2 / 3;
}
  • 代码流程

根据源码可知,在第一次为threadLocal进行赋值的时候会创建初始大小为16的threadLocalMap,并且通过setThreshold方法设置threshold,其值为当前哈希数组长度乘以(2/3),可以理解为加载因子为2/3

加载因子是衡量哈希表密集程度的一个参数,如果加载因子越大的话,说明哈希表被装载的越多,出现hash冲突的可能性越大,反之,则被装载的越少,出现hash冲突的可能性越小。同时如果过小,很显然内存使用率不高,该值取值应该考虑到内存使用率和hash冲突概率的一个平衡,如hashMap,concurrentHashMap的加载因子都为0.75

这里threadLocalMap初始大小为16加载因子为2/3,所以哈希表可用大小为:16*2/3=10,即哈希表可用容量为10。

  • 扩容resize

当我们的hash表size值大于阈值threshold,将触发resize方法,进行扩容

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
/**
* Double the capacity of the table.
*/
private void resize() {
Entry[] oldTab = table;
int oldLen = oldTab.length;
//新数组为原数组的2倍
int newLen = oldLen * 2;
Entry[] newTab = new Entry[newLen];
int count = 0;

for (int j = 0; j < oldLen; ++j) {
Entry e = oldTab[j];
if (e != null) {
ThreadLocal<?> k = e.get();
//遍历过程中如果遇到脏entry的话直接另value为null,有助于value能够被回收
if (k == null) {
e.value = null; // Help the GC
} else {
//重新确定entry在新数组的位置,然后进行插入
int h = k.threadLocalHashCode & (newLen - 1);
while (newTab[h] != null)
h = nextIndex(h, newLen);
newTab[h] = e;
count++;
}
}
}
//设置新哈希表的threshHold和size属性
setThreshold(newLen);
size = count;
table = newTab;
}
  1. 新建一个大小为原来数组长度的两倍的数组
  2. 遍历旧数组中的entry并将其插入到新的hash数组中

注意点:在扩容的过程中针对脏entry的话会令value为null,以便能够被垃圾回收器能够回收,解决隐藏的内存泄漏的问题

getEntry方法

源码
1
2
3
4
5
6
7
8
9
10
11
12
private Entry getEntry(ThreadLocal<?> key) {
//1. 确定在散列数组中的位置
int i = key.threadLocalHashCode & (table.length - 1);
//2. 根据索引i获取entry
Entry e = table[i];
//3. 满足条件则返回该entry
if (e != null && e.get() == key)
return e;
else
//4. 未查找到满足条件的entry,额外在做的处理
return getEntryAfterMiss(key, i, e);
}
方法逻辑

若能当前定位的entry的key和查找的key相同的话就直接返回这个entry,否则的话就是在set的时候存在hash冲突的情况,需要通过getEntryAfterMiss做进一步处理

  • getEntryAfterMiss源码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
private Entry getEntryAfterMiss(ThreadLocal<?> key, int i, Entry e) {
Entry[] tab = table;
int len = tab.length;

while (e != null) {
ThreadLocal<?> k = e.get();
if (k == key)
//找到和查询的key相同的entry则返回
return e;
if (k == null)
//解决脏entry的问题
expungeStaleEntry(i);
else
//继续向后环形查找
i = nextIndex(i, len);
e = tab[i];
}
return null;
}

这个方法同样很好理解,通过nextIndex往后环形查找,如果找到和查询的key相同的entry的话就直接返回,如果在查找过程中遇到脏entry的话使用expungeStaleEntry方法进行处理

图解流程

image-20210531203747470

remove方法

源码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
/**
* Remove the entry for key.
*/
private void remove(ThreadLocal<?> key) {
Entry[] tab = table;
// 获取数组长度
int len = tab.length;
// 获取索引i,即key在数组中位置
int i = key.threadLocalHashCode & (len-1);
// 遍历table中每个entry
for (Entry e = tab[i];
e != null;
e = tab[i = nextIndex(i, len)]) {
// 找到要移除的key:
if (e.get() == key) {
//将entry的key置为null
e.clear();
//将该entry的value也置为null
expungeStaleEntry(i);
return;
}
}
}
代码逻辑

通过传入的key获取索引i,环形遍历表中的entry,如果找到与指定key相同的entry,先通过clear方法将key置为null后,使其转换为一个脏entry,然后调用expungeStaleEntry方法将其value置为null,以便垃圾回收时能够清理,同时将table[i]置为null。

图解流程

image-20210531205253033

内存泄漏问题

  • 引入

在[内存泄漏初认识](# Entry数据结构)处,我们已经初步知道了什么是内存泄漏;接下来就学习下如何去解决这个问题

问题解决

在上面的set方法中,我们遇到了两个方法:

1
2
replaceStaleEntry(key, value, i);
cleanSomeSlots(i, sz);

这两个方法用于处理【脏Entry】 —— key 为 null的Entry

  1. 出现hash冲突的时候,或是遇到脏数据的时候,使用replaceStaleEntry进行处理
  2. 在插入了新的Entry后,会调用cleanSomeSlots去检测并清除脏数据
cleanSomeSlots方法
  • cleanSomeSlots方法用于检测,清除【脏Entry】

  • 源码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
/* @param i a position known NOT to hold a stale entry. The
* scan starts at the element after i.
*
* @param n scan control: {@code log2(n)} cells are scanned,
* unless a stale entry is found, in which case
* {@code log2(table.length)-1} additional cells are scanned.
* When called from insertions, this parameter is the number
* of elements, but when from replaceStaleEntry, it is the
* table length. (Note: all this could be changed to be either
* more or less aggressive by weighting n instead of just
* using straight log n. But this version is simple, fast, and
* seems to work well.)
*
* @return true if any stale entries have been removed.
*/
private boolean cleanSomeSlots(int i, int n) {
boolean removed = false;
Entry[] tab = table;
int len = tab.length;
do {
// 向后线性探测
i = nextIndex(i, len);
// 获取i索引处的Entry
Entry e = tab[i];
//遇到了脏Entry
if (e != null && e.get() == null) {
// n=当前Hash表长
n = len;
// 标志为removed
removed = true;
// 清理脏Entry
i = expungeStaleEntry(i);
}
} while ( (n >>>= 1) != 0);
return removed;
}
expungeStaleEntry方法
  • 源码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
/**
* Expunge a stale entry by rehashing any possibly colliding entries
* lying between staleSlot and the next null slot. This also expunges
* any other stale entries encountered before the trailing null. See
* Knuth, Section 6.4
*
* @param staleSlot index of slot known to have null key
* @return the index of the next null slot after staleSlot
* (all between staleSlot and this slot will have been checked
* for expunging).
*/
private int expungeStaleEntry(int staleSlot) {
Entry[] tab = table;
int len = tab.length;

// 1.清除当前脏entry
// expunge entry at staleSlot
// 置桶中的value为null
tab[staleSlot].value = null;
// 置桶位为null
tab[staleSlot] = null;
// 表长减1
size--;

// Rehash until we encounter null
Entry e;
int i;
// 2.往后环形继续查找,直到遇到table[i]==null时结束
for (i = nextIndex(staleSlot, len);
(e = tab[i]) != null;
i = nextIndex(i, len)) {
ThreadLocal<?> k = e.get();
// 3. 如果在向后搜索过程中再次遇到脏entry,同样将其清理掉
if (k == null) {
e.value = null;
tab[i] = null;
size--;
} else {
//处理rehash的情况
int h = k.threadLocalHashCode & (len - 1);
if (h != i) {
tab[i] = null;

// Unlike Knuth 6.4 Algorithm R, we must scan until
// null because multiple entries could have been stale.
while (tab[h] != null)
h = nextIndex(h, len);
tab[h] = e;
}
}
}
return i;
}
  • 方法逻辑
  1. 清理当前脏entry,即将其value引用置为null,并且将table[staleSlot]也置为null。value置为null后该value域变为不可达,在下一次gc的时候就会被回收掉,同时table[staleSlot]为null后以便于存放新的entry;
  2. 从当前staleSlot位置向后环形(nextIndex)继续搜索,直到遇到哈希桶(tab[i])为null的时候退出;
  3. 若在搜索过程再次遇到脏entry,继续将其清除。

也就是说该方法,清理掉当前脏entry后,并没有闲下来继续向后搜索,若再次遇到脏entry继续将其清理,直到哈希桶(table[i])为null时退出

方法执行后结果: 从当前脏entry(staleSlot)位到返回的i位,这中间所有的entry不是脏entry

为什么是遇到null时退出?原因是存在脏entry的前提条件是 当前哈希桶(table[i])不为null,只是该entry的key域为null。如果遇到哈希桶为null,代表着其根本就不是一个键值对Entry,那更不可能是一个脏的Entry

总结
  • 运行流程

cleanSomeSlots示意图.png

  1. 从当前位置i处(位于i处的entry一定不是脏entry)为起点在初始小范围(log2(n),n为哈希表已插入entry的个数size)开始向后搜索脏entry,若在整个搜索过程没有脏entry,方法结束退出
  2. 如果在搜索过程中遇到脏entryt通过expungeStaleEntry方法清理掉当前脏entry,并且该方法会返回下一个哈希桶(table[i])为null的索引位置为i。这时重新令搜索起点为索引位置i,n为哈希表的长度len,再次扩大搜索范围为log2(n’)继续搜索。
  • 例子

cleanSomeSlots执行情景图.png

  1. 如图当前n等于hash表的size即n=10,i=1,在第一趟搜索过程中通过nextIndex,i指向了索引为2的位置,此时table[2]为null,说明第一趟未发现脏entry,则第一趟结束进行第二趟的搜索。

  2. 第二趟所搜先通过nextIndex方法,索引由2的位置变成了i=3,当前table[3]!=null但是该entry的key为null,说明找到了一个脏entry,先将n置为哈希表的长度len,然后继续调用expungeStaleEntry方法,该方法会将当前索引为3的脏entry给清除掉(令value为null,并且table[3]也为null),但是该方法可不想偷懒,它会继续往后环形搜索,往后会发现索引为4,5的位置的entry同样为脏entry,索引为6的位置的entry不是脏entry保持不变,直至i=7的时候此处table[7]位null,该方法就以i=7返回。至此,第二趟搜索结束;

  3. 由于在第二趟搜索中发现脏entry,n增大为数组的长度len,因此扩大搜索范围(增大循环次数)继续向后环形搜索;

  4. 直到在整个搜索范围里都未发现脏entry,cleanSomeSlot方法执行结束退出。

replaceStaleEntry
  • 源码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
/*
* @param key the key
* @param value the value to be associated with key
* @param staleSlot index of the first stale entry encountered while
* searching for key.
*/
private void replaceStaleEntry(ThreadLocal<?> key, Object value,
int staleSlot) {
Entry[] tab = table;
int len = tab.length;
Entry e;

// Back up to check for prior stale entry in current run.
// We clean out whole runs at a time to avoid continual
// incremental rehashing due to garbage collector freeing
// up refs in bunches (i.e., whenever the collector runs).

//向前找到第一个脏entry
int slotToExpunge = staleSlot;
for (int i = prevIndex(staleSlot, len);
(e = tab[i]) != null;
i = prevIndex(i, len))
if (e.get() == null)
1. slotToExpunge = i;

// Find either the key or trailing null slot of run, whichever
// occurs first
for (int i = nextIndex(staleSlot, len);
(e = tab[i]) != null;
i = nextIndex(i, len)) {
ThreadLocal<?> k = e.get();

// If we find key, then we need to swap it
// with the stale entry to maintain hash table order.
// The newly stale slot, or any other stale slot
// encountered above it, can then be sent to expungeStaleEntry
// to remove or rehash all of the other entries in run.
if (k == key) {

//如果在向后环形查找过程中发现key相同的entry就覆盖并且和脏entry进行交换
2. e.value = value;
3. tab[i] = tab[staleSlot];
4. tab[staleSlot] = e;

// Start expunge at preceding stale entry if it exists
//如果在查找过程中还未发现脏entry,那么就以当前位置作为cleanSomeSlots
//的起点
if (slotToExpunge == staleSlot)
5. slotToExpunge = i;
//搜索脏entry并进行清理
6. cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
return;
}

// If we didn't find stale entry on backward scan, the
// first stale entry seen while scanning for key is the
// first still present in the run.
//如果向前未搜索到脏entry,则在查找过程遇到脏entry的话,后面就以此时这个位置
//作为起点执行cleanSomeSlots
if (k == null && slotToExpunge == staleSlot)
7. slotToExpunge = i;
}

// If key not found, put new entry in stale slot
//如果在查找过程中没有找到可以覆盖的entry,则将新的entry插入在脏entry
8. tab[staleSlot].value = null;
9. tab[staleSlot] = new Entry(key, value);

// If there are any other stale entries in run, expunge them
10. if (slotToExpunge != staleSlot)
//执行cleanSomeSlots
11. cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
}

BlockingQueue - 阻塞队列

概述

最常用的”生产者-消费者“问题中,队列通常被视作线程间操作的数据容器,这样,可以对各个模块的业务功能进行解耦,生产者将“生产”出来的数据放置在数据容器中,而消费者仅仅只需要在“数据容器”中进行获取数据即可,这样生产者线程和消费者线程就能够进行解耦,只专注于自己的业务功能即可。

阻塞队列(BlockingQueue)被广泛使用在“生产者-消费者”问题中,其原因是BlockingQueue提供了可阻塞的插入和移除的方法。

当队列容器已满,生产者线程会被阻塞,直到队列未满;当队列容器为空时,消费者线程会被阻塞,直至队列非空时为止。

基本操作 - 接口

BlockingQueue基本操作总结如下(此图来源于JAVA API文档):

BlockingQueue基本操作.png

  • BlockingQueue继承于Queue接口,因此,对数据元素的基本操作有:

插入元素

  1. add(E e) :往队列插入数据,当队列满时,插入元素时会抛出IllegalStateException异常;
  2. offer(E e):当往队列插入数据时,插入成功返回true,否则则返回false。当队列满时不会抛出异常;

删除元素

  1. remove(Object o):从队列中删除数据,成功则返回true,否则为false
  2. poll:删除数据,当队列为空时,返回null;

查看元素

  1. element:获取队头元素,如果队列为空时则抛出NoSuchElementException异常;
  2. peek:获取队头元素(不会删除头结点),如果队列为空则抛出NoSuchElementException异常
  • BlockingQueue具有的特殊操作:

插入数据:

  1. put:当阻塞队列容量已经满时,往阻塞队列插入数据的线程会被阻塞,直至阻塞队列已经有空余的容量可供使用;
  2. offer(E e, long timeout, TimeUnit unit):若阻塞队列已经满时,同样会阻塞插入数据的线程,直至阻塞队列已经有空余的地方,与put方法不同的是,该方法会有一个超时时间,若超过当前给定的超时时间,插入数据的线程会退出;

删除数据

  1. take():当阻塞队列为空时,获取队头数据的线程会被阻塞;
  2. poll(long timeout, TimeUnit unit):当阻塞队列为空时,获取数据的线程会被阻塞,另外,如果被阻塞的线程超过了给定的时长,该线程会退出(该方法可以获取队列的头结点,且会删除此结点)

阻塞队列

在这里插入图片描述

  • 阻塞队列分别为:
    • ArrayBlockingQueue - 有界队列(数组)
    • *LinkedBlockingQueue - 有界队列(链表) *
    • PriorityBlockingQueue - 无界(优先)阻塞队列(数组)
    • SynchronousQueue - 同步队列
    • LinkedTransferQueue - 无界阻塞队列(链表)
    • LinkedBlockingDeque - 有界阻塞双端队列(链表)
    • DelayQueue - 延时无界阻塞队列(数组)

ArrayBlockingQueue

ArrayBlockingQueue

ArrayBlockingQueue是由数组实现的有界阻塞队列。该队列命令元素FIFO(先进先出)。因此,对头元素时队列中存在时间最长的数据元素,而对尾数据则是当前队列最新的数据元素。ArrayBlockingQueue可作为“有界数据缓冲区”,生产者插入数据到队列容器中,并由消费者提取。ArrayBlockingQueue一旦创建,容量不能改变。

当队列容量满时,尝试将元素放入队列将导致操作阻塞;尝试从一个空队列中取一个元素也会同样阻塞。

ArrayBlockingQueue默认情况下不能保证线程访问队列的公平性,所谓公平性是指严格按照线程等待的绝对时间顺序,即最先等待的线程能够最先访问到ArrayBlockingQueue。而非公平性则是指访问ArrayBlockingQueue的顺序不是遵守严格的时间顺序,有可能存在,一旦ArrayBlockingQueue可以被访问时,长时间阻塞的线程依然无法访问到ArrayBlockingQueue。

如果保证公平性,通常会降低吞吐量。如果需要获得公平性的ArrayBlockingQueue,可采用如下代码:

1
private static ArrayBlockingQueue<Integer> blockingQueue = new ArrayBlockingQueue<Integer>(10,true);
主要属性
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
private static final long serialVersionUID = -817911632652898426L;

/** The queued items */
//保存队列元素的数组
final Object[] items;

/** items index for next take, poll, peek or remove */
//取出元素的位置 - 队列头的位置
int takeIndex;

/** items index for next put, offer, or add */
//添加元素的位置 - 队列尾的位置
int putIndex;

/** Number of elements in the queue */
//队列中元素的数量
int count;

/*
* Concurrency control uses the classic two-condition algorithm
* found in any textbook.
*/

/** Main lock guarding all access */
//锁对象 用来保证多线程操作共享变量的安全问题
final ReentrantLock lock;

/** Condition for waiting takes */
/** 当队列为空时,就会调用notEmpty的wait方法,让当前线程等待 */
/** 当生产者生产了一个产品后,调用notEmpty的signal方法,唤醒消费者 */
private final Condition notEmpty;

/** Condition for waiting puts */
/** 当队列为满时,就会调用notFull的wait方法,让当前线程等待 */
/** 当消费者消费了一个产品后,调用notFull的signal方法,唤醒生产者 */
private final Condition notFull;

/**
* Shared state for currently active iterators, or null if there
* are known not to be any. Allows queue operations to update
* iterator state.
*/
transient Itrs itrs = null;
入队方法
序号 方法名 队列满时处理方式 方法返回值
1 add(E e) 抛出“Queue full”异常 boolean
2 offer(E e) 返回false boolean
3 put(E e) 线程阻塞,直到中断或被唤醒 void
4 offer(E e, long timeout, TimeUnit unit) 在规定时间内重试,超过规定时间返回false boolean
  • add方法、offer方法与enqueue方法
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
// 调用AbstractQueue父类中的方法。
public boolean add(E e) {
// 通过调用offer来时实现
if (offer(e))
return true;
else
throw new IllegalStateException("Queue full");
}

//向队列末尾新添加元素。返回true表示添加成功,false表示添加失败,不会抛出异常
public boolean offer(E e) {
//判断添加的数据是否为空
checkNotNull(e);
final ReentrantLock lock = this.lock;
// 使用lock来保证,多线程修改成员属性的安全
lock.lock();
try {
// 队列已满,添加元素失败,返回false。
if (count == items.length)
return false;
else {
// 调用enqueue方法将元素插入队列中
enqueue(e);
return true;
}
} finally {
lock.unlock();
}
}

add方法 → offer方法 → enqueue方法,因此本质是调用enqueue

1
2
3
4
5
6
7
8
9
10
private void enqueue(E x) {
// assert lock.getHoldCount() == 1;
// assert items[putIndex] == null;
final Object[] items = this.items;
items[putIndex] = x; //通过 putIndex 对数据赋值
if (++putIndex == items.length) // 当putIndex 等于数组长度时,将 putIndex 重置为 0
putIndex = 0;
count++;//记录队列元素的个数
notEmpty.signal();//唤醒处于等待状态下的线程,表示当前队列中的元素不为空,如果存在消费者线程阻塞,就可以开始取出元素
}

图解流程的话:

image-20210603160048623

  • put方法
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
public void put(E e) throws InterruptedException {
checkNotNull(e);
final ReentrantLock lock = this.lock;
// 加锁,如果线程中断了抛出异常
lock.lockInterruptibly();
try {
// 如果数组满了,使用notFull等待
// notFull等待的意思是说现在队列满了
// 只有取走一个元素后,队列才不满
// 然后唤醒notFull,然后继续现在的逻辑
// 这里之所以使用while而不是if
// 是因为有可能多个线程阻塞在lock上
// 即使唤醒了可能其它线程先一步修改了队列又变成满的了
// 这时候需要再次等待
while (count == items.length)
notFull.await();
// 入队
enqueue(e);
} finally {
// 解锁
lock.unlock();
}
}

从源码中可以看出来,区别于add方法的地方在于:如果队列满时,是使用notFull.await();进行等待,而add方法会抛出异常

出队方法
序号 方法名 队列空时处理方式 方法返回值
1 remove() 抛出异常 E
2 poll() 返回null E
3 take() 线程阻塞,指定中断或被唤醒 E
4 poll(long timeout, TimeUnit unit) 在规定时间内重试,超过规定时间返回null E
  • remove方法、poll方法与dequeue()方法
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
public E remove() {
// 调用poll()方法出队
E x = poll();
if (x != null)
// 如果有元素出队就返回这个元素
return x;
else
// 如果没有元素出队就抛出异常
throw new NoSuchElementException();
}

// 删除队列第一个元素(即队列头),并返回它。如果队列是空的,它不会抛出异常,而是会返回null。
public E poll() {
final ReentrantLock lock = this.lock;
// 使用lock来保证,多线程修改成员属性的安全
lock.lock();
try {
// 如果count == 0,列表为空,就返回null,否则调用dequeue方法,返回列表头元素
return (count == 0) ? null : dequeue();
} finally {
lock.unlock();
}
}

remove方法 → poll方法 → dequeue方法,因此本质是调用dequeue

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// 删除队列头的元素,返回它
private E dequeue() {
// assert lock.getHoldCount() == 1;
// assert items[takeIndex] != null;

final Object[] items = this.items;
// 得到当前队列头的元素
@SuppressWarnings("unchecked")
E x = (E) items[takeIndex];
// 将当前队列头位置设置为null
items[takeIndex] = null;
// 当takeIndex 等于数组长度时,将 takeIndex 重置为 0
if (++takeIndex == items.length)
takeIndex = 0;
// 队列数量减一
count--;
if (itrs != null)
itrs.elementDequeued();
// 因为删除了一个元素,那么队列肯定不满了,那么唤醒在notFull条件下等待的一个线程
notFull.signal();
return x;
}

关于itrs.elementDequeued():ArrayBlockingQueue 中,实现了迭代器的功能,也就是可以通过迭代器来遍历阻塞队列中的元素
所以 itrs.elementDequeued() 是用来更新迭代器中的元素数据的

同样,图解流程:

image-20210603162413042

  • take方法
1
2
3
4
5
6
7
8
9
10
11
12
13
public E take() throws InterruptedException {
final ReentrantLock lock = this.lock;
lock.lockInterruptibly();
try {
//如果队列为空,没有数据,将消费者线程移入等待队列中
while (count == 0)
notEmpty.await();
//获取数据
return dequeue();
} finally {
lock.unlock();
}
}

从源码中可以看出来,区别于remove方法的地方在于:如果队列空时,是使用notEmpty.await();进行等待,而remove方法会抛出异常

查看方法
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// 调用AbstractQueue父类中的方法。
public E element() {
E x = peek();
if (x != null)
return x;
else
throw new NoSuchElementException();
}

// 查看队列头元素
public E peek() {
final ReentrantLock lock = this.lock;
// 使用lock来保证,多线程修改成员属性的安全
lock.lock();
try {
// 返回当前队列头的元素
return itemAt(takeIndex); // null when queue is empty
} finally {
lock.unlock();
}
}

LinkedBlockingQueue

主要属性
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
// 容量
private final int capacity;

// 元素数量
private final AtomicInteger count = new AtomicInteger();

// 链表头
transient Node<E> head;

// 链表尾
private transient Node<E> last;

// take锁,执行take, poll等操作时候需要获取该锁
private final ReentrantLock takeLock = new ReentrantLock();

// notEmpty条件
// 当队列无元素时,take锁会阻塞在notEmpty条件上,等待其它线程唤醒
private final Condition notEmpty = takeLock.newCondition();

//put执行put, offer等操作时候需要获取该锁
private final ReentrantLock putLock = new ReentrantLock();

// notFull条件
// 当队列满了时,put锁会会阻塞在notFull上,等待其它线程唤醒
private final Condition notFull = putLock.newCondition();
内部类
1
2
3
4
5
6
7
static class Node<E> {
E item;

Node<E> next;

Node(E x) { item = x; }
}
入队方法
  • void put(E e); 如果队列满了,一直阻塞,直到队列不满了或者线程被中断–>阻塞

  • boolean offer(E e);如果队列没满,立即返回true; 如果队列满了,立即返回false–>不阻塞

  • boolean offer(E e, long timeout, TimeUnit unit); 在队尾插入一个元素,,如果队列已满,则进入等待,直到出现以下三种情况:–>阻塞

    • 被唤醒
    • 等待时间超时
    • 当前线程被中断
  • put(E e)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
public void put(E e) throws InterruptedException {
if (e == null) throw new NullPointerException();
int c = -1;
Node<E> node = new Node<E>(e);
final ReentrantLock putLock = this.putLock;
final AtomicInteger count = this.count;
// 获取锁中断
putLock.lockInterruptibly();
try {
//判断队列是否已满,如果已满阻塞等待
while (count.get() == capacity) {
notFull.await();
}
// 把node放入队列中
enqueue(node);
c = count.getAndIncrement();
// 再次判断队列是否有可用空间,如果有唤醒下一个线程进行添加操作
if (c + 1 < capacity)
notFull.signal();
} finally {
putLock.unlock();
}
// 如果队列中有一条数据,唤醒消费线程进行消费
if (c == 0)
signalNotEmpty();
}

方法逻辑:

  1. 队列已满,阻塞等待。
  2. 队列未满,创建一个node节点放入队列中,如果放完以后队列还有剩余空间,继续唤醒下一个添加线程进行添加。如果放之前队列中没有元素,放完以后要唤醒消费线程进行消费。
  • offer(E e)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
public boolean offer(E e) {
if (e == null) throw new NullPointerException();
final AtomicInteger count = this.count;
// 如果队列满了 返回false
if (count.get() == capacity)
return false;
int c = -1;
// 包装结点
Node<E> node = new Node<E>(e);
// 设置put锁
final ReentrantLock putLock = this.putLock;
putLock.lock();
try {
// 队列有可用空间,放入node节点,判断放入元素后是否还有可用空间,
// 如果有,唤醒下一个添加线程进行添加操作。
if (count.get() < capacity) {
enqueue(node);
c = count.getAndIncrement();
if (c + 1 < capacity)
notFull.signal();
}
} finally {
putLock.unlock();
}
if (c == 0)
signalNotEmpty();
return c >= 0;
}

大体逻辑与put方法相同,区别在于:当队列没有可用元素的时候,不同于put方法的阻塞等待,offer方法直接方法false

  • signalNotEmpty方法
1
2
3
4
5
6
7
8
9
private void signalNotEmpty() {
final ReentrantLock takeLock = this.takeLock;
takeLock.lock();
try {
notEmpty.signal();
} finally {
takeLock.unlock();
}
}

逻辑:获取了take锁,先上锁,然后唤醒消费者线程,最后释放锁;

  • enqueue方法
1
2
3
4
5
6
7
8
9
10
11
12
13
/**
* Links node at end of queue.
*
* @param node the node
*/
private void enqueue(Node<E> node) {
// assert putLock.isHeldByCurrentThread();
// assert last.next == null;
// 这里分为两步:
// 1.last.next = node
// 2.last = last.next
last = last.next = node;
}
出队方法
  • E take(); 如果队列空了,一直阻塞,直到队列不为空或者线程被中断–>阻塞
  • E poll(); 如果没有元素,直接返回null;如果有元素,出队
  • E poll(long timeout, TimeUnit unit); 如果队列不空,出队;如果队列已空且已经超时,返回null;如果队列已空且时间未超时,则进入等待,直到出现以下三种情况:
    • 被唤醒
    • 等待时间超时
    • 当前线程被中断
  • take方法
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
public E take() throws InterruptedException {
E x;
int c = -1;
final AtomicInteger count = this.count;
final ReentrantLock takeLock = this.takeLock;
takeLock.lockInterruptibly();
try {
// 队列为空,阻塞等待
while (count.get() == 0) {
notEmpty.await();
}
x = dequeue();
c = count.getAndDecrement();
// 队列中还有元素,唤醒下一个消费线程进行消费
if (c > 1)
notEmpty.signal();
} finally {
takeLock.unlock();
}
// 移除元素之前队列是满的,唤醒生产线程进行添加元素
if (c == capacity)
signalNotFull();
return x;
}

方法逻辑:

  1. 队列为空,阻塞等待。
  2. 队列不为空,从队首获取并移除一个元素,如果消费后还有元素在队列中,继续唤醒下一个消费线程进行元素移除。如果放之前队列是满元素的情况,移除完后要唤醒生产线程进行添加元素。
  • poll方法
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public E poll() {
final AtomicInteger count = this.count;
if (count.get() == 0)
return null;
E x = null;
int c = -1;
final ReentrantLock takeLock = this.takeLock;
takeLock.lock();
try {
if (count.get() > 0) {
x = dequeue();
c = count.getAndDecrement();
if (c > 1)
notEmpty.signal();
}
} finally {
takeLock.unlock();
}
if (c == capacity)
signalNotFull();
return x;
}

大体逻辑与take方法相同,只是在队列满的时候,take方法进行阻塞等待,poll方法会return null;

  • signalNotFull方法
1
2
3
4
5
6
7
8
9
10
11
12
/**
* Signals a waiting put. Called only from take/poll.
*/
private void signalNotFull() {
final ReentrantLock putLock = this.putLock;
putLock.lock();
try {
notFull.signal();
} finally {
putLock.unlock();
}
}

逻辑:获取了put锁,先上锁,然后唤醒生产者线程,最后释放锁;

  • dequeue方法
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
private E dequeue() {
// 获取到head节点
Node<E> h = head;
// 获取到head节点指向的下一个节点
Node<E> first = h.next;
// head节点指向自己等待下次gc回收
h.next = h; // help GC
// head节点指向新的节点
head = first;
// 获取到新的head节点的item值
E x = first.item;
// 新head节点的item值设置为null
first.item = null;
return x;
}

ArrayBlockingQueue与LinkedBlockingQueue对比

  • ArrayBlockingQueue:
    • 一个对象数组+一把锁+两个条件
    • 入队与出队都用同一把锁
    • 在只有入队高并发或出队高并发的情况下,因为操作数组,且不需要扩容,性能很高
    • 采用了数组,必须指定大小,即容量有限
  • LinkedBlockingQueue:
    • 一个单向链表+两把锁+两个条件
    • 两把锁,一把用于入队,一把用于出队,有效的避免了入队与出队时使用一把锁带来的竞争。
    • 在入队与出队都高并发的情况下,性能比ArrayBlockingQueue高很多
    • 采用了链表,最大容量为整数最大值,可看做容量无限

线程池

概述

  • 为什么要使用线程池?

    在实际使用中,线程是很占用系统资源的,如果对线程管理不善很容易导致系统问题。因此,在大多数并发框架中都会使用线程池来管理线程,使用线程池管理

假设一个服务器完成一项任务所需时间为:T1创建线程时间,T2在线程中执行任务的时间,T3销毁线程时间。如果:T1+T3远大于T2,则可以采用线程池,实现对线程的复用,以提高服务器性能。

线程主要有如下好处:

  1. 降低资源消耗。通过复用已存在的线程和降低线程关闭的次数来尽可能降低系统性能损耗;
  2. 提升系统响应速度。通过复用线程,省去创建线程的过程,因此整体上提升了系统的响应速度;
  3. 提高线程的可管理性。线程是稀缺资源,如果无限制的创建,不仅会消耗系统资源,还会降低系统的稳定性,因此,需要使用线程池来管理线程。
  • 线程池继承关系

img

  • 线程池的组成部分
  • 线程池管理器:创建并管理线程池。例如创建线程池、销毁线程池、添加新任务等等。
  • 工作线程:线程池中的工作线程。空闲时处于空闲状态,可以循环的执行任务。
  • 任务接口:每个任务必须实现任务接口,以供工作线程调度任务的执行。
  • 任务队列:存放待处理任务的队列。

工作原理

线程池执行流程图.jpg

从图可以看出,线程池执行所提交的任务过程主要有这样几个阶段:

  1. 先判断线程池中核心线程池所有的线程是否都在执行任务。如果不是,则新创建一个线程执行刚提交的任务,否则,核心线程池中所有的线程都在执行任务,则进入第2步;
  2. 判断当前阻塞队列是否已满,如果未满,则将提交的任务放置在阻塞队列中;否则,则进入第3步;
  3. 判断线程池中所有的线程是否都在执行任务,如果没有,则创建一个新的线程来执行任务,否则,则交给饱和策略进行处理

线程池 - 创建

线程池参数说明

  • 线程池构造方法
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
/**
* @param corePoolSize 池内核心线程数量, 超出数量的线程会进入阻塞队列
* @param maximumPoolSize 最大可创建线程数量
* @param keepAliveTime 线程存活时间
* @param unit 存活时间的单位
* @param workQueue 线程溢出后的阻塞队列
* @param threadFactory 创建线程的工厂类
* @param handler 饱和策略
*/
ThreadPoolExecutor(int corePoolSize,
int maximumPoolSize,
long keepAliveTime,
TimeUnit unit,
BlockingQueue<Runnable> workQueue,
ThreadFactory threadFactory,
RejectedExecutionHandler handler)

对于各个参数的说明:

字段名称 描述
corePoolSize 线程池核心线程数(平时保留的线程数),创建后不会关闭的线程数量,如果设置了allowCoreThreadTimeout后,空闲时间超时后还是会关闭。执行任务时,没有达到核心线程数的话,是会直接创建新的线程。
maximumPoolSize 规定线程池最多只能有多少个线程(worker)在执行。当核心线程数和任务队列也都满了,不能添加任务的时候,这个参数才会生效。如果当前有效工作线程数量小于最大线程数量,会再创建新的线程。
keepAliveTime 超出corePoolSize数量的线程的保留时间。
unit keepAliveTime的时间单位。
workQueue 任务队列,为阻塞队列BlockingQueue的实现。线程池会先满足corePoolSize的限制,在核心线程数满了后,将任务加入队列。但队列也满了后,线程数小于maximumPoolSize,线程池继续创建线程。
threadFactory 线程创建工厂,可以用来配置线程的命名、是否是守护线程、优先级等等。
handler 拒绝处理器,为RejectedExecutionHandler的实现类。当任务队列满负荷,已经达到最大线程数,把新加入的任务交给这个handler 进行处理。线程池默认使用AbortPolicy(直接抛弃)策略,直接抛出异常。
allowCoreThreadTimeout 核心线程的空闲时间也要进行超时限制,也就是keepAliveTime的限制。如果配置为true后,所有的线程空闲时间超时后,都会进行线程退出操作。
  • 关于四种拒绝处理器饱和策略:

AbortPolicy(中止策略):直接抛弃。

CallerRunsPolicy(调用者运行策略):用调用者的线程执行任务。

DiscardPolicy(丢弃策略):抛弃当前任务。

DiscardOldestPolicy(弃老策略):抛弃队列中最久的任务。

线程池参数说明

线程池 - 提交

线程池创建之后,后面就是要提交任务执行了,通常是使用使用线程池自带的submit或者excute方法,然后用lambda表达式传入函数体后,就可以执行任务了

submit的方法本质上也是调用的execute方法,因此只需要学习execute方法即可

  • 使用Thread创建启动线程
1
2
Thread t = new Thread();
t.start();
  • 使用Executor启动线程执行任务
1
2
Thread t = new Thread();
executor.execute(t);

对于不同的Executor实现,execute()方法可能是创建一个新线程并立即启动,也有可能是使用已有的工作线程来运行传入的任务,也可能是根据设置线程池的容量或者阻塞队列的容量来决定是否要将传入的线程放入阻塞队列中或者拒绝接收传入的线程。

execute源码

execute方法主要含义:通过调用这个方法可以向线程池提交一个任务,交由线程池去执行

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
public void execute(Runnable command) {
//需要执行的任务command为空,抛出空指针异常
if (command == null) // 1
throw new NullPointerException();

/*
*执行的流程实际上分为三步
*1、如果运行的线程小于corePoolSize,以用户给定的Runable对象新开一个线程去执行
* 并且执行addWorker方法会以原子性操作去检查runState和workerCount,以防止当返回false的
* 时候添加了不应该添加的线程
*2、 如果任务能够成功添加到队列当中,我们仍需要对添加的线程进行双重检查,有可能添加的线程在前
* 一次检查时已经死亡,又或者在进入该方法的时候线程池关闭了。所以我们需要复查状态,并有必
* 要的话需要在停止时回滚入列操作,或者在没有线程的时候新开一个线程
*3、如果任务无法入列,那我们需要尝试新增一个线程,如果新建线程失败了,我们就知道线程可能关闭了
* 或者饱和了,就需要拒绝这个任务
*
*/

//获取线程池的控制状态 (runState和workerCount)
int c = ctl.get(); // 2

// 通过workCountOf方法得到当前活动的线程数,
// 当前活动线程数小于corePoolSize,新建一个线程放入线程池中;
// addWorker(): 在线程池中创建一个新的线程并且执行
if (workerCountOf(c) < corePoolSize) {
//添加任务到worker集合 - 线程池当中
/*
* addWorker中的第二个参数表示限制添加线程的数量是根据corePoolSize来判断还是maximumPoolSize来判断;
* 如果为true,根据corePoolSize来判断;
* 如果为false,则根据maximumPoolSize来判断
*/
if (addWorker(command, true))
return; //成功返回
//失败的话再次获取线程池的控制状态
c = ctl.get();
}

/*
*判断线程池是否正处于RUNNING状态,并且往工作队列中添加该任务
*是的话添加Runnable对象到workQueue队列当中
*/
if (isRunning(c) && workQueue.offer(command)) { // 3

//再次获取线程池的状态
int recheck = ctl.get();

//再次检查状态
//线程池不处于RUNNING状态,将任务从任务队列中移除
if (! isRunning(recheck) && remove(command))
//拒绝任务
reject(command);
/*
* 获取线程池中的有效线程数,如果数量是0,则执行addWorker方法
* 这里传入的参数表示:
* 1. 第一个参数为null,表示在线程池中创建一个线程,但不去启动;
* 2. 第二个参数为false,将线程池的有限线程数量的上限设置为maximumPoolSize,添加线程时根据maximumPoolSize来判断;
* 如果判断workerCount大于0,则直接返回,在workQueue中新增的command会在将来的某个时刻被执行。
*/

//workerCount等于0
else if (workerCountOf(recheck) == 0) // 4
//添加worker
addWorker(null, false);
}
//加入阻塞队列失败,则尝试以线程池最大线程数新开线程去执行该任务
else if (!addWorker(command, false)) // 5
//执行失败则拒绝任务
reject(command);
}

execute执行流程

  • 执行流程
  1. 如果workerCount < corePoolSize,则创建并启动一个线程来执行新提交的任务;
  2. 如果workerCount >= corePoolSize,且线程池内的阻塞队列未满,则将任务添加到该阻塞队列中;
  3. 如果workerCount >= corePoolSize && workerCount < maximumPoolSize,且线程池内的阻塞队列已满,则创建并启动一个线程来执行新提交的任务;
  4. 如果workerCount >= maximumPoolSize,并且线程池内的阻塞队列已满, 则根据拒绝策略来处理该任务, 默认的处理方式是直接抛异常。

这里要注意一下addWorker(null, false);,也就是创建一个线程,但并没有传入任务,因为任务已经被添加到workQueue中了,所以worker在执行的时候,会直接从workQueue中获取任务。所以,在workerCountOf(recheck) == 0时执行addWorker(null, false);也是为了保证线程池在RUNNING状态下必须要有一个线程来执行任务。

  • 图解方法流程

img

addWorker

  • 作用:addWorker方法的主要工作是在线程池中创建一个新的线程并执行=
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
private boolean addWorker(Runnable firstTask, boolean core) {
//外部循环标记
retry:
//外层死循环
for (;;) {
//获取线程池控制状态
int c = ctl.get();
//获取runState运行状态
int rs = runStateOf(c);

// Check if queue empty only if necessary.
/*
* 这个if判断
* 如果rs >= SHUTDOWN,则表示此时不再接收新任务;
* 接着判断以下3个条件,只要有1个不满足,则返回false:
* 1. rs == SHUTDOWN,这时表示关闭状态,不再接受新提交的任务,但却可以继续处理阻塞队列中已保存的任务
* 2. firsTask为空
* 3. 阻塞队列不为空
*
* 首先考虑rs == SHUTDOWN的情况
* 这种情况下不会接受新提交的任务,所以在firstTask不为空的时候会返回false;
* 然后,如果firstTask为空,并且workQueue也为空,则返回false,
* 因为队列中已经没有任务了,不需要再添加线程了
*/
if (rs >= SHUTDOWN && //runState大于等于SHUTDOWN,初始位RUNNING
! (rs == SHUTDOWN && //runState等于SHUTDOWN
firstTask == null && //firstTask为null
! workQueue.isEmpty())) //workQueue任务队列不为空
return false;

//内层死循环
for (;;) {
//获取线程池的workerCount数量
int wc = workerCountOf(c);
//如果workerCount超出最大值或者大于corePoolSize/maximumPoolSize
//返回false
if (wc >= CAPACITY ||
wc >= (core ? corePoolSize : maximumPoolSize))
return false;
//通过CAS操作,使workerCount数量+1,成功则跳出循环,回到retry标记
if (compareAndIncrementWorkerCount(c))
break retry;

//CAS操作失败,再次获取线程池的控制状态
c = ctl.get(); // Re-read ctl
//如果当前runState不等于刚开始获取的runState,说明状态被改变了,则跳出内层循环,继续外层循环
if (runStateOf(c) != rs)
continue retry;
// else CAS failed due to workerCount change; retry inner loop
//CAS由于更改workerCount而失败,继续内层循环
}
}

//通过以上循环,能执行到这是workerCount成功+1了

//worker开始标记
boolean workerStarted = false;
//worker添加标记
boolean workerAdded = false;
//初始化worker为null
Worker w = null;
try {
//初始化一个当前Runnable对象的worker对象
w = new Worker(firstTask);
//获取该worker对应的线程
final Thread t = w.thread;
//如果线程不为null
if (t != null) {
//初始线程池的锁
final ReentrantLock mainLock = this.mainLock;
//获取锁
mainLock.lock();
try {
// Recheck while holding lock.
// Back out on ThreadFactory failure or if
// shut down before lock acquired.
//获取锁后再次检查,获取线程池runState
int rs = runStateOf(ctl.get());

//当runState小于SHUTDOWN或者runState等于SHUTDOWN并且firstTask为null
if (rs < SHUTDOWN ||
(rs == SHUTDOWN && firstTask == null)) {

//线程已存活
if (t.isAlive()) // precheck that t is startable
//线程未启动就存活,抛出IllegalThreadStateException异常
throw new IllegalThreadStateException();

//将worker对象添加到workers集合当中
workers.add(w);
//获取workers集合的大小
int s = workers.size();
//如果大小超过largestPoolSize
if (s > largestPoolSize)
//重新设置largestPoolSize
largestPoolSize = s;
//标记worker已经被添加
workerAdded = true;
}
} finally {
//释放锁
mainLock.unlock();
}
//如果worker添加成功
if (workerAdded) {
//启动线程
t.start();
//标记worker已经启动
workerStarted = true;
}
}
} finally {
//如果worker没有启动成功
if (! workerStarted)
//workerCount-1的操作
addWorkerFailed(w);
}
//返回worker是否启动的标记
return workerStarted;
}

addWorker方法的主要工作是在线程池中创建一个新的线程并执行,其中firstTask参数指定的是新线程需要执行的第一个任务,core参数决定于活动线程数的比较对象是corePoolSize还是maximumPoolSize。

根据传进来的参数首先对线程池和队列的状态进行判断,满足条件就新建一个Worker对象,并实例化该对象的线程,最后启动线程。

addWorker.jpg

runworker

  • 源码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
final void runWorker(Worker w) {
//获取当前线程
Thread wt = Thread.currentThread();
//获取worker里的任务
Runnable task = w.firstTask;
//将worker实例的任务赋值为null
w.firstTask = null;

/*
*unlock方法会调用AQS的release方法
*release方法会调用具体实现类也就是Worker的tryRelease方法
*也就是将AQS状态置为0,允许中断
*/
w.unlock(); // allow interrupts
//是否突然完成
boolean completedAbruptly = true;
try {
//worker实例的task不为空,或者通过getTask获取的不为空
while (task != null || (task = getTask()) != null) {
//获取锁
w.lock();
// If pool is stopping, ensure thread is interrupted;
// if not, ensure thread is not interrupted. This
// requires a recheck in second case to deal with
// shutdownNow race while clearing interrupt
/*
*获取线程池的控制状态,至少要大于STOP状态
*如果状态不对,检查当前线程是否中断并清除中断状态,并且再次检查线程池状态是否大于STOP
*如果上述满足,检查该对象是否处于中断状态,不清除中断标记
*/
if ((runStateAtLeast(ctl.get(), STOP) ||
(Thread.interrupted() &&
runStateAtLeast(ctl.get(), STOP))) &&
!wt.isInterrupted())
//中断改对象
wt.interrupt();
try {
//执行前的方法,由子类具体实现
beforeExecute(wt, task);
Throwable thrown = null;
try {
//执行任务
task.run();
} catch (RuntimeException x) {
thrown = x; throw x;
} catch (Error x) {
thrown = x; throw x;
} catch (Throwable x) {
thrown = x; throw new Error(x);
} finally {
//执行完后调用的方法,也是由子类具体实现
afterExecute(task, thrown);
}
} finally {//执行完后
//task设置为null
task = null;
//已完成任务数+1
w.completedTasks++;
//释放锁
w.unlock();
}
}
completedAbruptly = false;
} finally {
//处理并退出当前worker
processWorkerExit(w, completedAbruptly);
}
}
  • 流程
  1. 首先在方法一进来,就执行了w.unlock(),这是为了将AQS的状态改为0,因为只有getState() >= 0的时候,线程才可以被中断;
  2. 判断firstTask是否为空,为空则通过getTask()获取任务,不为空接着往下执行
  3. 判断是否符合中断状态,符合的话设置中断标记
  4. 执行beforeExecute(),task.run(),afterExecute()方法
  5. 任何一个出异常都会导致任务执行的终止;进入processWorkerExit来退出任务
  6. 正常执行的话会接着回到步骤2

runWorker.jpg

getTask

  • 源码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
private Runnable getTask() {
//标志是否获取任务超时
boolean timedOut = false; // Did the last poll() time out?

//死循环
for (;;) {
//获取线程池的控制状态
int c = ctl.get();
//获取线程池的runState
int rs = runStateOf(c);

// Check if queue empty only if necessary.
/*
*判断线程池的状态,出现以下两种情况
*1、runState大于等于SHUTDOWN状态
*2、runState大于等于STOP或者阻塞队列为空
*将会通过CAS操作,进行workerCount-1并返回null
*/
if (rs >= SHUTDOWN && (rs >= STOP || workQueue.isEmpty())) {
decrementWorkerCount();
return null;
}

//获取线程池的workerCount
int wc = workerCountOf(c);

// Are workers subject to culling?

/*
*allowCoreThreadTimeOut:是否允许core Thread超时,默认false
*workerCount是否大于核心核心线程池
*/
boolean timed = allowCoreThreadTimeOut || wc > corePoolSize;

/*
*1、wc大于maximumPoolSize或者已超时
*2、队列不为空时保证至少有一个任务
*/
if ((wc > maximumPoolSize || (timed && timedOut))
&& (wc > 1 || workQueue.isEmpty())) {
/*
*通过CAS操作,workerCount-1
*能进行-1操作,证明wc大于maximumPoolSize或者已经超时
*/
if (compareAndDecrementWorkerCount(c))
//-1操作成功,返回null
return null;
//-1操作失败,继续循环
continue;
}

try {
/*
*wc大于核心线程池
*执行poll方法
*小于核心线程池
*执行take方法
*/
Runnable r = timed ?
workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS) :
workQueue.take();
//判断任务不为空返回任务
if (r != null)
return r;
//获取一段时间没有获取到,获取超时
timedOut = true;
} catch (InterruptedException retry) {
timedOut = false;
}
}
}
  • 流程
  1. 获取线程池控制状态和runState,判断线程池是否已经关闭或者正在关闭,是的话则workerCount-1操作返回null
  2. 获取workerCount判断是否大于核心线程池
  3. 判断workerCount是否大于最大线程池数目或者已经超时,是的话workerCount-1,-1成功则返回null,不成功则回到步骤1重新继续
  4. 判断workerCount是否大于核心线程池,大于则用poll方法从队列获取任务,否则用take方法从队列获取任务
  5. 判断任务是否为空,不为空则返回获取的任务,否则回到步骤1重新继续

getTask.jpg

processWorkerExit

从名称来看 Process Worker Exit:任务过程 退出,当任务执行完或者出现异常中断执行,强制被退出的时候,会有相应的操作,这个方法就是这个【相应的操作】

  • 源码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
private void processWorkerExit(Worker w, boolean completedAbruptly) {
// 如果completedAbruptly值为true,则说明线程执行时出现了异常,需要将workerCount减1;
// 如果线程执行时没有出现异常,说明在getTask()方法中已经已经对workerCount进行了减1操作,这里就不必再减了。
if (completedAbruptly) // If abrupt, then workerCount wasn't adjusted
decrementWorkerCount();
final ReentrantLock mainLock = this.mainLock;
mainLock.lock();
try {
//统计完成的任务数
completedTaskCount += w.completedTasks;
// 从workers中移除,也就表示着从线程池中移除了一个工作线程
workers.remove(w);
} finally {
mainLock.unlock();
}
// 根据线程池状态进行判断是否结束线程池
tryTerminate();
int c = ctl.get();
/*
* 当线程池是RUNNING或SHUTDOWN状态时,如果worker是异常结束,那么会直接addWorker;
* 如果allowCoreThreadTimeOut=true,并且等待队列有任务,至少保留一个worker;
* 如果allowCoreThreadTimeOut=false,workerCount不少于corePoolSize。
*/
if (runStateLessThan(c, STOP)) {
if (!completedAbruptly) {
int min = allowCoreThreadTimeOut ? 0 : corePoolSize;
if (min == 0 && ! workQueue.isEmpty())
min = 1;
if (workerCountOf(c) >= min)
return; // replacement not needed
}
addWorker(null, false);
}
}

线程池 - 关闭

ThreadPoolExecutor提供了两个方法,用于线程池的关闭,分别是shutdown()shutdownNow()

  • shutdown方法
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public void shutdown() {
final ReentrantLock mainLock = this.mainLock;
mainLock.lock();
try {
// 检查权限
checkShutdownAccess();
// 设置线程池状态
advanceRunState(SHUTDOWN);
// 中断空闲线程
interruptIdleWorkers();
// 清理一些资源
onShutdown();
} finally {
mainLock.unlock();
}
// 尝试结束线程池 - 使线程池的状态设置为TERMINATED。
tryTerminate();
}
  • shutdownNow方法
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public List<Runnable> shutdownNow() {
List<Runnable> tasks;
final ReentrantLock mainLock = this.mainLock;
mainLock.lock();
try {
checkShutdownAccess();
advanceRunState(STOP);
// 中断所有工作线程,无论是否空闲
interruptWorkers();
// 取出队列中没有被执行的任务
tasks = drainQueue();
} finally {
mainLock.unlock();
}
// 尝试结束线程池 - 使线程池的状态设置为TERMINATED。
tryTerminate();
return tasks;
}

线程池 - 监控

通过线程池提供的参数进行监控。线程池里有一些属性在监控线程池的时候可以使用

  • getTaskCount:线程池已经执行的和未执行的任务总数;
  • getCompletedTaskCount:线程池已完成的任务数量,该值小于等于taskCount;
  • getLargestPoolSize:线程池曾经创建过的最大线程数量。通过这个数据可以知道线程池是否满过,也就是达到了maximumPoolSize;
  • getPoolSize:线程池当前的线程数量;
  • getActiveCount:当前线程池中正在执行任务的线程数量。

通过这些方法,可以对线程池进行监控,在ThreadPoolExecutor类中提供了几个空方法,如beforeExecute方法,afterExecute方法和terminated方法,可以扩展这些方法在执行前或执行后增加一些新的操作,例如统计线程池的执行任务的时间等,可以继承自ThreadPoolExecutor来进行扩展。

线程协作

技术参考