前言

hello, 大家好, 我是咸鱼君, 擅长各种Java摸鱼姿势.

image

恰逢2020年“金九”月,

今天, 我们就来说一说面试中出现频率极高的锁知识!

ps:说不定可以帮到部分有“想法”的同学

image

锁的优化

JDK6开始, synchronized的实现机制进行了较大调整,除了使用JDK5引进的CAS自旋之外, 还增加了以下的优化策略.

• 自适应的CAS自旋
• 锁消除
• 锁粗化
• 偏向锁
• 轻量级锁
• ...

这些优化使得synchronized性能获得了极大提高, 所以, 情况允许下, 推荐使用synchronized关键字.

今天, 我们好好了解下synchronized锁进行的那些优化, 这样我们使用时才能清晰的明白优劣, 作出合适的选择.

锁的基本状态

锁主要存在以下四种状态:

1. 无锁状态
2. 偏向锁状态
3. 轻量级锁状态
4. 重量级锁状态

锁可以从偏向锁 升级到 轻量级锁, 再 升级至 重量级锁.
不过锁的升级是单向的,
也就是说只能从低到高, 不会出现锁的降级.

在 JDK 1.6 中默认是开启偏向锁和轻量级锁的,
可以通过-XX:-UseBiasedLocking来禁用偏向锁.

自旋锁

线程的阻塞和唤醒需要CPU从用户态转为核心态,
频繁的阻塞和唤醒对CPU来说是一件负担很重的工作,势必会给系统的并发性能带来很大的压力.
另外, 其实在许多应用上面, 对象锁的锁状态只会持续很短一段时间,
为了这一段很短的时间频繁地阻塞和唤醒线程是非常不值得的.

所以引入自旋锁.

何谓自旋锁？

所谓自旋锁,
就是指当一个线程尝试获取某个锁时,
如果该锁已被其他线程占用,
就一直循环检测锁是否被释放,
而不是进入线程挂起或睡眠状态.

自旋锁适用于锁保护的临界区很小的情况,
临界区很小的话,锁占用的时间就很短.

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

所以说,自旋等待的时间(自旋的次数)必须要有一个限度,
如果自旋超过了定义的时间仍然没有获取到锁,则应该被挂起.

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

如果通过参数-XX:PreBlockSpin来调整自旋锁的自旋次数,会带来诸多不便.
假如将参数调整为10,
但是系统很多线程都是等你刚刚退出的时候就释放了锁(假如多自旋一两次就可以获取锁),是不是很尴尬.
于是JDK1.6引入自适应的自旋锁,让虚拟机会变得越来越聪明.

适应性自旋锁

JDK 1.6引入了更加聪明的自旋锁,即自适应自旋锁.
所谓自适应就意味着自旋的次数不再是固定的,它是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定.

那它如何进行适应性自旋呢？

线程如果自旋成功了,
那么下次自旋的次数会更加多,因为虚拟机认为既然上次成功了,
那么此次自旋也很有可能会再次成功,那么它就会允许自旋等待持续的次数更多.

反之,如果对于某个锁,很少有自旋能够成功,
那么在以后要或者这个锁的时候自旋的次数会减少甚至省略掉自旋过程,
以免浪费处理器资源.

有了自适应自旋锁, 随着程序运行和性能监控信息的不断完善,
虚拟机对程序锁的状况预测会越来越准确, 虚拟机会变得越来越聪明.

锁消除

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

锁消除的依据是逃逸分析的数据支持

逃逸分析

逃逸分析的是一个对象的动态作用域，2种情况
方法逃逸：对象通过参数传递传给了另一个方法
线程逃逸：对象有另外的线程访问
逃逸分析的目的是确认一个对象是否只可能当前线程能访问

如果不存在竞争,为什么还需要加锁呢？
所以, 锁消除可以节省毫无意义的请求锁的时间.

变量是否逃逸,对于虚拟机来说需要使用数据流分析来确定的,
对于开发人员来说, 一些情况是可以主观分析出来的,
比如,不存在数据竞争的代码块不需要加上同步!

但是, 有时候程序并不是我们所想的那样,
虽然没有显示使用锁, 但是在使用一些JDK的内置API时,如

• StringBuffer
• Vector
• HashTable
• 其它...

这个时候会存在隐形的加锁操作.

比如StringBuffer的append()方法, Vector的add()方法：

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内部的加锁操作消除.

锁粗化

锁粗化概念比较好理解,就是将多个连续的加锁、解锁操作连接在一起,扩展成一个范围更大的锁

为什么要锁粗化?

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

在大多数的情况下,上述观点是正确的.

但是, 如果一系列的连续加锁解锁操作,可能会导致不必要的性能损耗,
所以引入锁粗化的概念.

还举个上文中的例子

public void vectorTest(){
    Vector<String> vector = new Vector<String>();
    for(int i = 0 ; i < 10 ; i++){
        vector.add(i + "");
    }
    System.out.println(vector);
}

vector每次add的时候都需要加锁操作,
JVM检测到对同一个对象(vector)连续加锁、解锁操作, 会合并一个更大范围的加锁、解锁操作, 即加锁解锁操作会移到for循环之外.

偏向锁

偏向锁是JDK6中引入的重要概念.
HotSpot虚拟机作者经过研究实践发现,
在大多数情况下, 锁不仅不存在多线程竞争, 而且总是由同一线程多次获得;
为了让线程获得锁的代价更低, 所以引进了偏向锁.

偏向锁是在单线程执行代码块时使用的机制.
如果在多线程并发的环境下(即线程A尚未执行完同步代码块,线程B发起了申请锁的申请),则一定会转化为轻量级锁或者重量级锁.

在JDK5中, 偏向锁默认是关闭的;
而到了JDK6中, 偏向锁已经默认开启.
如果并发数较大,并且同步代码块执行时间较长时,
则被多个线程同时访问的概率就很大,
此时就可以使用参数-XX:-UseBiasedLocking来禁止偏向锁(但这是个JVM参数,不能针对某个对象锁来单独设置).

引入偏向锁主要目的:

为了在没有多线程竞争的情况下,
尽量减少不必要的轻量级锁执行路径.
因为轻量级锁的加锁解锁操作是需要依赖多次CAS原子指令的;
而偏向锁只需要在置换ThreadID的时候依赖一次CAS原子指令(由于一旦出现多线程竞争的情况就必须撤销偏向锁,所以偏向锁的撤销操作的性能损耗也必须小于节省下来的CAS原子指令的性能消耗).

轻量级锁是为了在线程交替执行同步块时提高性能;
而偏向锁则是在只有一个线程执行同步块时进一步提高性能.

那么偏向锁是如何来减少不必要的CAS操作呢?

首先我们看下无竞争下锁存在什么问题：

现在几乎所有的锁都是可重入的,即已经获得锁的线程可以多次锁住/解锁监视对象;
按照HotSpot之前的设计,
每次加锁/解锁都会涉及到一些CAS操作(比如对等待队列的CAS操作),
CAS操作会延迟本地调用,

因此偏向锁的想法是:
一旦线程第一次获得了监视对象,
之后让监视对象“偏向”这个线程,
之后的多次调用则可以避免CAS操作;
说白了就是置个变量,
如果发现为true则无需再走各种加锁/解锁流程.

CAS为什么会引入本地延迟?

这要从SMP(对称多处理器)架构说起,下图大概表明了SMP的结构：

SMP(对称多处理器)架构

如图, 所有的CPU会共享一条系统总线(BUS),靠此总线连接主存.
每个核心都有自己的一级缓存,各核相对于BUS对称分布,
因此这种结构称为“对称多处理器”.

而CAS的全称为Compare-And-Swap,是一条CPU的原子指令;
其作用是让CPU比较后, 原子地更新某个位置的值;
其实现方式是基于硬件平台的汇编指令,
也就是说CAS是靠硬件实现的,JVM只是封装了汇编调用;
那些AtomicInteger类便是使用了这些封装后的接口.

举个例子

两个核心,Core1和Core2,
Core1和Core2可能会同时把主存中某个位置的值Load到自己的L1 Cache中,
当Core1在自己的L1 Cache中修改这个位置的值时,会通过总线,使Core2中L1 Cache对应的值“失效”;
而Core2一旦发现自己L1 Cache中的值失效(称为Cache命中缺失)则会通过总线从内存中加载该地址最新的值;
大家通过总线的来回通信称为“Cache一致性流量”,
因为总线被设计为固定的“通信能力”,
如果Cache一致性流量过大,总线将成为瓶颈.
而当Core1和Core2中的值再次一致时,称为“Cache一致性”;
从这个层面来说,锁设计的终极目标便是减少Cache一致性流量.

而CAS恰好会导致Cache一致性流量,
如果有很多线程都共享同一个对象,
当某个Core CAS成功时必然会引起总线风暴,
这就是所谓的本地延迟,
本质上偏向锁就是为了消除CAS,降低Cache一致性流量.

Cache一致性：

上面提到Cache一致性,其实是有协议支持的,现在通用的协议是MESI(最早由Intel开始支持),具体参考：http://en.wikipedia.org/wiki/MESI_protocol.

Cache一致性流量的例外情况：

其实也不是所有的CAS都会导致总线风暴,这跟Cache一致性协议有关,具体参考：http://blogs.oracle.com/dave/entry/biased_locking_in_hotspot

NUMA(Non Uniform Memory Access Achitecture)架构：

与SMP对应还有非对称多处理器架构,现在主要应用在一些高端处理器上;
主要特点是:

• 没有总线;
• 没有公用主存;
• 每个Core有自己的内存;

针对这种结构此处不做讨论.

所以,当一个线程访问同步块并获取锁时,会在对象头和栈帧中的锁记录里存储锁偏向的线程ID,以后该线程进入和退出同步块时不需要花费CAS操作来争夺锁资源,只需要检查是否为偏向锁、锁标识为以及ThreadID即可,处理流程如下：

1. 检测Mark Word是否为可偏向状态,即是否为偏向锁1,锁标识位为01；
2. 若为可偏向状态,则测试线程ID是否为当前线程ID,如果是,则执行步骤(5),否则执行步骤(3)；
3. 如果测试线程ID不为当前线程ID,则通过CAS操作竞争锁,竞争成功,则将Mark Word的线程ID替换为当前线程ID,否则执行线程(4)；
4. 通过CAS竞争锁失败,证明当前存在多线程竞争情况,当到达全局安全点,获得偏向锁的线程被挂起,偏向锁升级为轻量级锁,然后被阻塞在安全点的线程继续往下执行同步代码块；
5. 执行同步代码块；

偏向锁的释放采用了 一种只有竞争才会释放锁的机制,线程是不会主动去释放偏向锁,需要等待其他线程来竞争.偏向锁的撤销需要 等待全局安全点(这个时间点是上没有正在执行的代码).其步骤如下：

1.暂停拥有偏向锁的线程；

2. 判断锁对象是否还处于被锁定状态,否,则恢复到无锁状态(01),以允许其余线程竞争.是,则挂起持有锁的当前线程,并将指向当前线程的锁记录地址的指针放入对象头Mark Word,升级为轻量级锁状态(00),然后恢复持有锁的当前线程,进入轻量级锁的竞争模式；

注意：此处将 当前线程挂起再恢复的过程中并没有发生锁的转移,仍然在当前线程手中,只是穿插了个 “将对象头中的线程ID变更为指向锁记录地址的指针” 这么个事.

偏向锁的获取和释放过程

轻量级锁

引入轻量级锁的主要目的是 在没有多线程竞争的前提下,减少传统的重量级锁使用操作系统互斥量产生的性能消耗.当关闭偏向锁功能或者多个线程竞争偏向锁导致偏向锁升级为轻量级锁,则会尝试获取轻量级锁,其步骤如下：

1. 在线程进入同步块时,如果同步对象锁状态为无锁状态(锁标志位为“01”状态,是否为偏向锁为“0”),虚拟机首先将在当前线程的栈帧中建立一个名为锁记录(Lock Record)的空间,用于存储锁对象目前的Mark Word的拷贝,官方称之为 Displaced Mark Word.此时线程堆栈与对象头的状态如下图所示：

   
   
   轻量级锁CAS操作之前线程堆栈与对象的状态

2. 拷贝对象头中的Mark Word复制到锁记录(Lock Record)中；

3. 拷贝成功后,虚拟机将使用CAS操作尝试将对象Mark Word中的Lock Word更新为指向当前线程Lock Record的指针,并将Lock record里的owner指针指向object mark word.如果更新成功,则执行步骤(4),否则执行步骤(5)；

4. 如果这个更新动作成功了,那么当前线程就拥有了该对象的锁,并且对象Mark Word的锁标志位设置为“00”,即表示此对象处于轻量级锁定状态,此时线程堆栈与对象头的状态如下图所示：

   
   
   轻量级锁CAS操作之后线程堆栈与对象的状态

5. 如果这个更新操作失败了,虚拟机首先会检查对象Mark Word中的Lock Word是否指向当前线程的栈帧,如果是,就说明当前线程已经拥有了这个对象的锁,那就可以直接进入同步块继续执行.否则说明多个线程竞争锁,进入自旋执行(3),若自旋结束时仍未获得锁,轻量级锁就要膨胀为重量级锁,锁标志的状态值变为“10”,Mark Word中存储的就是指向重量级锁(互斥量)的指针,当前线程以及后面等待锁的线程也要进入阻塞状态.

轻量级锁的释放也是通过CAS操作来进行的,主要步骤如下：

1.通过CAS操作尝试把线程中复制的Displaced Mark Word对象替换当前的Mark Word；
2.如果替换成功,整个同步过程就完成了,恢复到无锁状态(01)；

3. 如果替换失败,说明有其他线程尝试过获取该锁(此时锁已膨胀),那就要在释放锁的同时,唤醒被挂起的线程；

对于轻量级锁,其性能提升的依据是 “对于绝大部分的锁,在整个生命周期内都是不会存在竞争的”,如果打破这个依据则除了互斥的开销外,还有额外的CAS操作,因此在有多线程竞争的情况下,轻量级锁比重量级锁更慢.

轻量级锁的获取和释放过程

1. 为什么升级为轻量锁时要把对象头里的Mark Word复制到线程栈的锁记录中呢？

因为在申请对象锁时 需要以该值作为CAS的比较条件,同时在升级到重量级锁的时候,能通过这个比较判定是否在持有锁的过程中此锁被其他线程申请过,如果被其他线程申请了,则在释放锁的时候要唤醒被挂起的线程.

2. 为什么会尝试CAS不成功以及什么情况下会不成功？

CAS本身是不带锁机制的,其是通过比较而来.假设如下场景：线程A和线程B都在对象头里的锁标识为无锁状态进入,那么如线程A先更新对象头为其锁记录指针成功之后,线程B再用CAS去更新,就会发现此时的对象头已经不是其操作前的对象HashCode了,所以CAS会失败.也就是说,只有两个线程并发申请锁的时候会发生CAS失败.

然后线程B进行CAS自旋,等待对象头的锁标识重新变回无锁状态或对象头内容等于对象HashCode(因为这是线程B做CAS操作前的值),这也就意味着线程A执行结束(参见后面轻量级锁的撤销,只有线程A执行完毕撤销锁了才会重置对象头),此时线程B的CAS操作终于成功了,于是线程B获得了锁以及执行同步代码的权限.如果线程A的执行时间较长,线程B经过若干次CAS时钟没有成功,则锁膨胀为重量级锁,即线程B被挂起阻塞、等待重新调度.

此处,如何理解“轻量级”？“轻量级”是相对于使用操作系统互斥量来实现的传统锁而言的.但是,首先需要强调一点的是,轻量级锁并不是用来代替重量级锁的,它的本意是在没有多线程竞争的前提下,减少传统的重量级锁使用产生的性能消耗.

轻量级锁所适应的场景是线程交替执行同步块的情况,如果存在同一时间访问同一锁的情况,必然就会导致轻量级锁膨胀为重量级锁.

重量级锁

Synchronized是通过对象内部的一个叫做 监视器锁(Monitor)来实现的.但是监视器锁本质又是依赖于底层的操作系统的Mutex Lock来实现的.而操作系统实现线程之间的切换这就需要从用户态转换到核心态,这个成本非常高,状态之间的转换需要相对比较长的时间,这就是为什么Synchronized效率低的原因.因此,这种依赖于操作系统Mutex Lock所实现的锁我们称之为 “重量级锁”.

重量级锁、轻量级锁和偏向锁之间转换

重量级锁、轻量级锁和偏向锁之间转换

Synchronized偏向锁、轻量级锁及重量级锁转换流程

锁的优劣

各种锁并不是相互代替的,而是在不同场景下的不同选择,绝对不是说重量级锁就是不合适的.每种锁是只能升级,不能降级,即由偏向锁->轻量级锁->重量级锁,而这个过程就是开销逐渐加大的过程.

1. 如果是单线程使用,那偏向锁毫无疑问代价最小,并且它就能解决问题,连CAS都不用做,仅仅在内存中比较下对象头就可以了；
2. 如果出现了其他线程竞争,则偏向锁就会升级为轻量级锁；
3. 如果其他线程通过一定次数的CAS尝试没有成功,则进入重量级锁；

在第3种情况下进入同步代码块就 要做偏向锁建立、偏向锁撤销、轻量级锁建立、升级到重量级锁,最终还是得靠重量级锁来解决问题,那这样的代价就比直接用重量级锁要大不少了.所以使用哪种技术,一定要看其所处的环境及场景,在绝大多数的情况下,偏向锁是有效的,这是基于HotSpot作者发现的“大多数锁只会由同一线程并发申请”的经验规律.

锁的优劣

参考文章: 源码架构

都看到这了, 不点个“赞”就想跑?

image

欢迎关注我

技术公众号 “CTO技术”

订阅号.png