死磕Synchronized底层实现,面试你还怕什么?

关于 synchronized 的底层实现,网上有很多文章了。但是很多文章要么作者根本没看代码,仅仅是根据网上其他文章总结、照搬而成,难免有些错误;要么很多点都是一笔带过,对于为什么这样实现没有一个说法,让像我这样的读者意犹未尽。

本系列文章将对HotSpot的 synchronized 锁实现进行全面分析,内容包括偏向锁、轻量级锁、重量级锁的加锁、解锁、锁升级流程的原理及源码分析,希望给在研究 synchronized 路上的同学一些帮助。

大概花费了两周的实现看代码(花费了这么久时间有些忏愧,主要是对C++、JVM底层机制、JVM调试以及汇编代码不太熟),将 synchronized 涉及到的代码基本都看了一遍,其中还包括在JVM中添加日志验证自己的猜想,总的来说目前对synchronized 这块有了一个比较全面清晰的认识,但水平有限,有些细节难免有些疏漏,还望请大家指正。

本篇文章将对 synchronized 机制做个大致的介绍,包括用以承载锁状态的对象头、锁的几种形式、各种形式锁的加锁和解锁流程、什么时候会发生锁升级。 需要注意的是本文旨在介绍背景和概念,在讲述一些流程的时候,只提到了主要case,对于实现细节、运行时的不同分支都在后面的文章中详细分析 

本人看的JVM版本是jdk8u,具体版本号以及代码可以在 这里 看到。

synchronized简介

Java中提供了两种实现同步的基础语义: synchronized 方法和 synchronized 块, 我们来看个demo:

当SyncTest.java被编译成class文件的时候, synchronized 关键字和 synchronized 方法的字节码略有不同,我们可以用javap -v  命令查看class文件对应的JVM字节码信息,部分信息如下:

从上面的中文注释处可以看到,对于 synchronized 关键字而言, javac 在编译时,会生成对应的 monitorenter monitorexit 指令分别对应 synchronized 同步块的进入和退出,有两个 monitorexit 指令的原因是:为了保证抛异常的情况下也能释放锁,所以 javac 为同步代码块添加了一个隐式的try-finally,在finally中会调用 monitorexit 命令释放锁。而对于 synchronized 方法而言, javac 为其生成了一个 ACC_SYNCHRONIZED 关键字,在JVM进行方法调用时,发现调用的方法被ACC_SYNCHRONIZED 修饰,则会先尝试获得锁。

在JVM底层,对于这两种 synchronized 语义的实现大致相同,在后文中会选择一种进行详细分析。

因为本文旨在分析 synchronized 的实现原理,因此对于其使用的一些问题就不赘述了,不了解的朋友可以看看 这篇文章 

锁的几种形式

传统的锁(也就是下文要说的重量级锁)依赖于系统的同步函数,在linux上使用 mutex 互斥锁,最底层实现依赖于 futex,关于 futex 可以看我之前的 文章 ,这些同步函数都涉及到用户态和内核态的切换、进程的上下文切换,成本较高。对于加了 synchronized 关键字但 运行时并没有多线程竞争,或两个线程接近于交替执行的情况 ,使用传统锁机制无疑效率是会比较低的。

在JDK 1.6之前, synchronized 只有传统的锁机制,因此给开发者留下了 synchronized 关键字相比于其他同步机制性能不好的印象。

在JDK 1.6引入了两种新型锁机制:偏向锁和轻量级锁,它们的引入是为了解决在没有多线程竞争或基本没有竞争的场景下因使用传统锁机制带来的性能开销问题。

在看这几种锁机制的实现前,我们先来了解下对象头,它是实现多种锁机制的基础。

对象头

因为在Java中任意对象都可以用作锁,因此必定要有一个映射关系,存储该对象以及其对应的锁信息(比如当前哪个线程持有锁,哪些线程在等待)。一种很直观的方法是,用一个全局map,来存储这个映射关系,但这样会有一些问题:需要对map做线程安全保障,不同的 synchronized 之间会相互影响,性能差;另外当同步对象较多时,该map可能会占用比较多的内存。

所以最好的办法是将这个映射关系存储在对象头中,因为对象头本身也有一些hashcode、GC相关的数据,所以如果能将锁信息与这些信息 共存 在对象头中就好了。

在JVM中,对象在内存中除了本身的数据外还会有个对象头,对于普通对象而言,其对象头中有两类信息: mark word 和类型指针。另外对于数组而言还会有一份记录数组长度的数据。

类型指针是指向该对象所属类对象的指针, mark word 用于存储对象的HashCode、GC分代年龄、锁状态等信息。在32位系统上 mark word 长度为32bit,64位系统上长度为64bit。为了能在有限的空间里存储下更多的数据,其存储格式是不固定的,在32位系统上各状态的格式如下:

《死磕Synchronized底层实现--概论》

可以看到锁信息也是存在于对象的 mark word 中的。当对象状态为偏向锁(biasable)时, mark word 存储的是偏向的线程ID;当状态为轻量级锁(lightweight locked)时, mark word 存储的是指向线程栈中 Lock Record 的指针;当状态为重量级锁(inflated)时,为指向堆中的monitor对象的指针。

重量级锁

重量级锁是我们常说的传统意义上的锁,其利用操作系统底层的同步机制去实现Java中的线程同步。

重量级锁的状态下,对象的 mark word 为指向一个堆中monitor对象的指针。

一个monitor对象包括这么几个关键字段:cxq(下图中的ContentionList),EntryList ,WaitSet,owner。

其中cxq ,EntryList ,WaitSet都是由ObjectWaiter的链表结构,owner指向持有锁的线程。

《死磕Synchronized底层实现--概论》

当一个线程尝试获得锁时,如果该锁已经被占用,则会将该线程封装成一个ObjectWaiter对象插入到cxq的队列尾部,然后暂停当前线程。当持有锁的线程释放锁前,会将cxq中的所有元素移动到EntryList中去,并唤醒EntryList的队首线程。

如果一个线程在同步块中调用了 Object#wait 方法,会将该线程对应的ObjectWaiter从EntryList移除并加入到WaitSet中,然后释放锁。当wait的线程被notify之后,会将对应的ObjectWaiter从WaitSet移动到EntryList中。

以上只是对重量级锁流程的一个简述,其中涉及到的很多细节,比如ObjectMonitor对象从哪来?释放锁时是将cxq中的元素移动到EntryList的尾部还是头部?notfiy时,是将ObjectWaiter移动到EntryList的尾部还是头部?

关于具体的细节,会在重量级锁的文章中分析。

轻量级锁

JVM的开发者发现在很多情况下,在Java程序运行时,同步块中的代码都是不存在竞争的,不同的线程交替的执行同步块中的代码。这种情况下,用重量级锁是没必要的。因此JVM引入了轻量级锁的概念。

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

《死磕Synchronized底层实现--概论》

加锁过程

1.在线程栈中创建一个 Lock Record ,将其 obj (即上图的Object reference)字段指向锁对象。

2.直接通过CAS指令将 Lock Record 的地址存储在对象头的 mark word 中,如果对象处于无锁状态则修改成功,代表该线程获得了轻量级锁。如果失败,进入到步骤3。

3.如果是当前线程已经持有该锁了,代表这是一次锁重入。设置 Lock Record 第一部分( Displaced Mark Word )为null,起到了一个重入计数器的作用。然后结束。

4.走到这一步说明发生了竞争,需要膨胀为重量级锁。

解锁过程

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

2.如果 Lock Record 的 Displaced Mark Word 为null,代表这是一次重入,将 obj 设置为null后continue。

3.如果 Lock Record 的 Displaced Mark Word 不为null,则利用CAS指令将对象头的 mark word 恢复成为 Displaced Mark Word 。如果成功,则continue,否则膨胀为重量级锁。

偏向锁

Java是支持多线程的语言,因此在很多二方包、基础库中为了保证代码在多线程的情况下也能正常运行,也就是我们常说的线程安全,都会加入如 synchronized 这样的同步语义。但是在应用在实际运行时,很可能只有一个线程会调用相关同步方法。比如下面这个demo:

在这个demo中为了保证对list操纵时线程安全,对addString方法加了 synchronized 的修饰,但实际使用时却只有一个线程调用到该方法,对于轻量级锁而言,每次调用addString时,加锁解锁都有一个CAS操作;对于重量级锁而言,加锁也会有一个或多个CAS操作(这里的’一个‘、’多个‘数量词只是针对该demo,并不适用于所有场景)。

在JDK1.6中为了 提高一个对象在一段很长的时间内都只被一个线程用做锁对象场景下的性能 ,引入了偏向锁,在第一次获得锁时,会有一个CAS操作,之后该线程再获取锁,只会执行几个简单的命令,而不是开销相对较大的CAS命令。我们来看看偏向锁是如何做的。

对象创建

当JVM启用了偏向锁模式(1.6以上默认开启),当新创建一个对象的时候,如果该对象所属的class没有关闭偏向锁模式(什么时候会关闭一个class的偏向模式下文会说,默认所有class的偏向模式都是是开启的),那新创建对象的 mark word 将是可偏向状态,此时 mark word中 的thread id(参见上文偏向状态下的 mark word 格式)为0,表示未偏向任何线程,也叫做匿名偏向(anonymously biased)。

加锁过程

case 1:当该对象第一次被线程获得锁的时候,发现是匿名偏向状态,则会用CAS指令,将 mark word 中的thread id由0改成当前线程Id。如果成功,则代表获得了偏向锁,继续执行同步块中的代码。否则,将偏向锁撤销,升级为轻量级锁。

case 2:当被偏向的线程再次进入同步块时,发现锁对象偏向的就是当前线程,在通过一些额外的检查后(细节见后面的文章),会往当前线程的栈中添加一条 Displaced Mark Word 为空的 Lock Record 中,然后继续执行同步块的代码,因为操纵的是线程私有的栈,因此不需要用到CAS指令;由此可见偏向锁模式下,当被偏向的线程再次尝试获得锁时,仅仅进行几个简单的操作就可以了,在这种情况下, synchronized 关键字带来的性能开销基本可以忽略。

case 3.当其他线程进入同步块时,发现已经有偏向的线程了,则会进入到 撤销偏向锁 的逻辑里,一般来说,会在 safepoint中去查看偏向的线程是否还存活,如果存活且还在同步块中则将锁升级为轻量级锁,原偏向的线程继续拥有锁,当前线程则走入到锁升级的逻辑里;如果偏向的线程已经不存活或者不在同步块中,则将对象头的 mark word 改为无锁状态(unlocked),之后再升级为轻量级锁。

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

解锁过程

当有其他线程尝试获得锁时,是根据遍历偏向线程的 lock record 来确定该线程是否还在执行同步块中的代码。因此偏向锁的解锁很简单,仅仅将栈中的最近一条 lock record 的 obj 字段设置为null。需要注意的是,偏向锁的解锁步骤中 并不会修改对象头中的thread id。

下图展示了锁状态的转换流程:

《死磕Synchronized底层实现--概论》

另外,偏向锁默认不是立即就启动的,在程序启动后,通常有几秒的延迟,可以通过命令  -XX:BiasedLockingStartupDelay=0来关闭延迟。

批量重偏向与撤销

从上文偏向锁的加锁解锁过程中可以看出,当只有一个线程反复进入同步块时,偏向锁带来的性能开销基本可以忽略,但是当有其他线程尝试获得锁时,就需要等到 safe point 时将偏向锁撤销为无锁状态或升级为轻量级/重量级锁。 safe point 这个词我们在GC中经常会提到,其代表了一个状态,在该状态下所有线程都是暂停的(大概这么个意思),详细可以看这篇 文章。总之,偏向锁的撤销是有一定成本的,如果说运行时的场景本身存在多线程竞争的,那偏向锁的存在不仅不能提高性能,而且会导致性能下降。因此,JVM中增加了一种批量重偏向/撤销的机制。

存在如下两种情况:(见官方 论文 第4小节):

1.一个线程创建了大量对象并执行了初始的同步操作,之后在另一个线程中将这些对象作为锁进行之后的操作。这种case下,会导致大量的偏向锁撤销操作。

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

批量重偏向(bulk rebias)机制是为了解决第一种场景。批量撤销(bulk revoke)则是为了解决第二种场景。

其做法是:以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。

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

End

Java中的 synchronized 有偏向锁、轻量级锁、重量级锁三种形式,分别对应了锁只被一个线程持有、不同线程交替持有锁、多线程竞争锁三种情况。当条件不满足时,锁会按偏向锁->轻量级锁->重量级锁 的顺序升级。JVM种的锁也是能降级的,只不过条件很苛刻,不在我们讨论范围之内。该篇文章主要是对Java的 synchronized 做个基本介绍,后文会有更详细的分析。

Image placeholder
loki12345
未设置
  52人点赞

没有讨论,发表一下自己的看法吧

推荐文章
CentOS7 下使用 rsync+sersync 配置文件自动同步

为什么需要文件自动同步功能? 我们平时上传代码,可以通过ftp、sftp等将文件上传至服务器,耗时耗力,而且很容易出错。如果服务器数量少还好,一但服务器数量增加,压力可想而知。 这个时候我们可以使用各

Rust 标准库中的 async/await (async-std)

Rust对齐标准库中的async/await(async-std)简介现在的rust生态中,async/await在rust1.39中已经stable,其他库还有futures已经到0.3.x,还有就

实现人工智能落地 你还差一个“数据分析流水线”的距离

在智慧生产场景,生产制造商可以在生产线上利用深度学习,尤其是图像识别,将产品的质量检测自动化。比如自动检测产品表面有没有划伤、有没有零部件的缺失、有没有标签的错位。研究表明,相比人工检测,智慧检测可以

利用 consul+nginx-upsync 实现动态负载

如果Nginx遇到大流量和高负载,修改配置文件重启可能并不总是那么方便,因为恢复Nginx并重载配置会进一步增加系统负载,并很可能暂时降低性能。而一个个修改配置文件也是很容易出错和费时间的操作。 这时

利用 consul+nginx-upsync 实现动态负载

这是前一段时间学习的课程上面的,自己实际操作了一下,详细操作及说明如下。如果Nginx遇到大流量和高负载,修改配置文件重启可能并不总是那么方便,因为恢复Nginx并重载配置会进一步增加系统负载,并很可

PHP 内核:讲下 PHP 7 底层虚拟机工作原理 —— Zend Virtual Machine 7.2 版本

本文旨在提供Zend虚拟机的概述,如php7所示。这不是一个全面的描述,但我试图涵盖大部分重要部分,以及一些更精细的细节。 此描述针对的是PHP7.2版(目前正在开发中),但几乎所有内容都适用于PHP

看完这篇,你还不能理解 ‘数据库架构’?趁早回家吧

来源:http://rrd.me/ep46N一、数据库架构原则高可用高性能一致性扩展性二、常见的架构方案方案一:主备架构,只有主库提供读写服务,备库冗余作故障转移用jdbc:mysql://vip:3

【搞定 Java 并发面试】面试最常问的 Java 并发基础常见面试题总结!

Java并发基础常见面试题总结 1.什么是线程和进程? 1.1.何为进程? 进程是程序的一次执行过程,是系统运行程序的基本单位,因此进程是动态的。系统运行一个程序即是一个进程从创建,运行到消亡的过程。

Linux 文件同步工具之 rsync

学习背景 1.最近公司的项目在使用jenkins做自动化构建,因为jenkins在构建时是比较耗性能的,便单独使用了一台服务器做构建服务器。但是个人觉得这样成本过高,单独拿一台服务器来构建并且该服务器

深入了解JavaScript async/await !

Asyncfunctions让我们以async这个关键字开始。它可以被放置在任何函数前面,像下面这样:asyncfunctionf(){ return1; }在函数前面的「async」这个单词表达了一

ES6问答-async函数

async函数 async是什么?它和Genernator函数外观上的区别是什么? constasyncReadFile=asyncfunction(){ constf1=awaitreadFile

单点登录系统原理与实现,图文并茂,附源码

本原文:整理自互联网一、单系统登录机制1、http无状态协议web应用采用browser/server架构,http作为通信协议。http是无状态协议,浏览器的每一次请求,服务器会独立处理,不与之前或

RTSP网络摄像头/海康大华硬盘录像机网页无插件直播方案EasyNVR如何实现RTMP/FLV/HLS/RTSP直播流分发

背景需求对于摄像机直播,客户反馈的最多就是实现web直播、摆脱插件,可以自定义集成等问题。我们熟悉的EasyNVR已经完美的解决了这些问题。然而对于web播放也存在一些问题,通常我们web播放RTMP

美漂数据科学家年薪多少?爬了6年H1B签证数据发现,招的人多了,但钱少了

大数据文摘出品来源:medium编译:张睿毅、曹培信自2012年起,一直被称为“最性感的工作”的数据科学家职位,吸引了大批远渡重洋到达硅谷,做着“数据梦”的留学生们。但他们也付出了不菲的前期投入,除了

css底层什么技术实现的

css底层什么技术实现的css底层是由浏览器进行解析渲染实现的。具体是通过css解析器解析css语法,生成css规则树,再结合dom树进行渲染绘制到屏幕上的。(相关课程推荐:css视频教程)CSS的渲

Onvif/RTSP海康大华网络安防摄像机网页无插件直播方案EasyNVR中直播页面和视频列表页面的区别介绍

背景分析随着平安城市、智慧城市、雪亮工程、智能交通等各项建设的持续开展,安防逐渐得到普及,面对如此广阔的市场,对安防企业来说不仅仅是机遇更多的是挑战。现今大多数摄像头一直没能摆脱人工监控的传统监控方式

Onvif/RTSP海康大华网络安防摄像机网页无插件直播方案EasyNVR如何使用Excel将通道配置简单化?

进入移动互联网时代以来,企业微信公众号已成为除官网以外非常重要的宣传渠道,当3.2亿直播用户与9亿微信用户的势能累加,在微信上开启直播已成为越来越多企业的必然选择。EasyNVR核心在于摄像机的音视频

Onvif/RTSP海康大华网络安防摄像机网页无插件直播方案EasyNVR登陆用户名密码失效问题解决方案

背景分析随着互联网基础设施建设的发展,4G/5G/NB-IoT各种网络技术的大规模商用,视频随时随地可看、可控的诉求越来越多,互联网思维、架构和技术引入进传统监控行业里,成为新形势下全终端监控的基础需

RTSP、RTMP网络摄像头互联网无插件直播视频流媒体服务器EasyNVR在windows上无法启动问题排查

背景需求随着雪亮工程、明厨亮灶、手机看店、智慧幼儿园监控等行业开始将传统的安防摄像头进行互联网、微信直播,我们知道摄像头直播的春天了。将安防摄像头或NVR上的视频流转成互联网直播常用的RTSP、RTM

安防摄像头网页无插件直播流媒体服务器EasyNVR在IE浏览器下的 pointer-events- none前端兼容性调试

背景说明由于互联网的飞速发展,传统安防摄像头的视频监控直播与互联网直播相结合是大势所趋。传统安防的直播大多在一个局域网内,在播放的客户端上也是有所限制,一般都需要OCXWeb插件进行直播。对于安防监控

RTSP-ONVIF协议安防视频监控流媒体服务解决方案EasyNVR在Windows重启时提示“进程意外终止”问题解析

什么是ONVIFOpenNetworkVideoInterfaceForum,开放型网络视频接口论坛,以公开、开放的原则共同制定开放性行业标准。是一个提供开放网络视频接口的论坛组织。ONVIF规范描述

安防摄像头RTSP/Onvif协议网页无插件直播视频流媒体服务器EasyNVR之按需直播如何有效利用最大上行带宽

介绍一般情况下,直播默认的播放方式是非按需直播,但很多情况下,不少用户会选择按需直播。按需直播能够减少带宽流量和服务器性能占用,最优的提高服务器的使用效率。下面我们来系统介绍下EasyNVR中按需直播

jQuery与Zepto是什么?

jQuery是什么?jQuery是一个简洁而快速的JavaScript库,可用于简化事件处理,HTML文档遍历,Ajax交互和动画,以便快速开发网站。jQuery简化了HTML的客户端脚本,从而简化了

jquery和zepto的区别是什么?

jQuery是一个简洁而快速的JavaScript库,可用于简化事件处理,HTML文档遍历,Ajax交互和动画,以便快速开发网站。jQuery简化了HTML的客户端脚本,从而简化了Web2.0应用程序

jquery中size()与length的区别是什么?

jQuerylength和size()区别length是属性,size()是方法。如果你只是想获取元素的个数,两者效果一样既("img").length和("img").size()获取的值是一样的。