阅读 357

深入浅出看synchronized的底层实现原理

原文链接: mp.weixin.qq.com

前言

加锁一直是线程安全绕不开的话题,针对线程的使用各位小伙伴基本上已经得心应手了,所以今天就来点稍稍深入的。

单拎出来synchronized,好好捋一捋它的前世今生。

正文

小A:synchronized关键字我已经基本上会用了,是不是要好好的深挖一下原理的内容了?

MDove:没错,接下来让我们从:

常见的synchronized加锁方式入手;引出Java对象在内存的布局,以及锁的存放位置;然后看一看锁在C++中的简单实现思路;最后咱们从字节码中,看一下JVM如果识别synchronized。

内容不是很难,不会涉及到特别多深奥的内容,大部分是平铺直叙的介绍,很适合阅读呦~

小A:快点开始吧,我等不及啦。

浅聊synchronized的使用

MDove:说起synchronized的底层实现原来,咱们先看看synchronized的俩种加锁方式:

1、某个对象实例内

此作用域内的synchronized锁 ,可以防止多个线程同时访问这个对象的synchronized方法

并且一个对象有多个synchronized方法,只要一个线程访问了其中的一个synchronized方法,其它线程不能同时访问这个对象中任何一个synchronized方法。

此外,不同对象实例的synchronized方法是不相干预的。也就是说,其它线程可以同时访问此类下的另一个对象实例中的synchronized方法;

public synchronized void method(){  // TODO}public void method(){  synchronized(this) {   // TODO  }}复制代码

2、某个类

此作用域下,可以防止多个线程同时访问这个类中的synchronized方法。也就是说此种修饰,可以对此类的所有对象实例起作用。

public void method() {   synchronized(ClassName.class) {     // todo   }}public static synchronized method(){    // TODO}复制代码

MDove:注意一点,synchronized关键字是不能继承的,也就是说,基类的方法synchronized fun(){} 在继承类中并不自动是synchronized fun(){},而是变成了fun(){}。继承时,需要显式的指定它的某个方法为synchronized方法。有机会你可以自己写个demo试一下。

常见错误

MDove:你来看一看下面这个demo,有没有什么问题?

public class ErrorSyncInstance implements Runnable{    static int i=0;    public synchronized void add(){        i++;    }    @Override    public void run() {        for(int j=0;j<1000000;j++){            add();        }    }    public static void main(String[] args) throws InterruptedException {        Thread t1=new Thread(new ErrorSyncInstance());        Thread t2=new Thread(new ErrorSyncInstance());        t1.start();        t2.start();        t1.join();        t2.join();        System.out.println(i);    }}复制代码

小A:没觉得有问题呐?这不就是第一种加锁的方式,锁实例对象么?

MDove:既然你都知道是锁实例对象,那你没看出来问题么?虽然我们使用synchronized修饰了add()。但是却new了两个不同的实例对象,这也就意味着存在着两个不同的实例对象锁,因此t1和t2都会进入各自的对象锁,也就是说t1和t2线程使用的是不同的锁,因此线程安全是无法保证的。

小A:对对对,没错。那解决这种问题,是不是需要用第二种加锁的方式,锁住这个类?

MDove:没错,解决这种困境的的方式是将synchronized作用于静态的add方法,这样的话,对象锁就当前类,因为类对象只有一个,因此无论new多少个实例对象都是安全的:

小A:那是不是这样改写就可以了?

public static synchronized void add(){    i++;}复制代码

MDove:没错就是这样,很简单。接下来让我们看一些深入的内容,锁的实现。

synchronized锁的底层实现

1、对象的内存分布

MDove:我们都知道,对象被创建在堆中。并且对象在内存中的存储布局方式可以分为3块区域:对象头、实例数据、对齐填充。其中对象头,便是我们今天的主角。

关于实例数据、对齐填充的作用,各位小伙伴可以参考《深入理解Java虚拟机》。

MDove:对于对象头来说,主要是包括俩部分信息:

  • 1、自身运行时的数据,比如:锁状态标志、线程持有的锁…等等。(此部分内容被称之为Mark Word)

今天我们只聊:指向重量级锁的指针

  • 2、另一部分是类型指针:JVM通过这个指针来确定这个对象是哪个类的实例。

MDove:今天我们主要聊的是对象头,第一部分中重量级锁的内容。

MDove:先让我们从宏观的角度看一看synchronized锁的实现原理。

2、synchronized锁的宏观实现

MDove:synchronized的对象锁,其指针指向的是一个monitor对象(由C++实现)的起始地址。每个对象实例都会有一个 monitor。其中monitor可以与对象一起创建、销毁;亦或者当线程试图获取对象锁时自动生成。

monitor是由ObjectMonitor实现(ObjectMonitor.hpp文件,C++实现的),对于我们来说主要关注的是如下代码:

ObjectMonitor() {    // 省略部分变量    _count        = 0;     _owner        = NULL;    _WaitSet      = NULL;    _WaitSetLock  = 0 ;    _EntryList    = NULL ;}复制代码

MDove:我们可以看到这里定义了_WaitSet 和 _EntryList俩个队列,其中_WaitSet 用来保存每个等待锁的线程对象。

小A:那_EntryList呢?

MDove:别着急,让我们先看一下_owner,它指向持有ObjectMonitor对象的线程。当多个线程同时访问一段同步代码时,会先存放到 _EntryList 集合中,接下来当线程获取到对象的monitor时,就会把_owner变量设置为当前线程。同时count变量+1。如果线程调用wait() 方法,就会释放当前持有的monitor,那么_owner变量就会被置为null,同时_count减1,并且该线程进入 WaitSet集合中,等待下一次被唤醒。

MDove:当然,若当前线程顺利执行完方法,也将释放monitor,重走一遍刚才的内容,也就是_owner变量就会被置为null,同时_count减1,并且该线程进入 WaitSet集合中,等待下一次被唤醒。

因为这个锁对象存放在对象本身,也就是为什么Java中任意对象可以作为锁的原因。

3、synchronized代码块的底层实现

MDove:咱们先写一个简单的demo,然后看一下它们的字节码:

private int i = 0;public void fun() {    synchronized (this) {        i++;    }}复制代码

MDove:根据虚拟机规范要求,在执行monitorenter指令时,首先要尝试获取对象锁,也就是上文我们提到了monitor对象。如果这个对象没有被锁定,或者当前线程已经拥有了这个对象的锁,那么就把锁的计数器(_count)加1。当然与之对应执行monitorexit指令时,锁的计数器(_count)也会减1。

MDove:如果当前线程获取锁失败,那么就会被阻塞住,进入_WaitSet 中,等待锁被释放为止。

小A:等等,我看到字节码中,有俩个monitorexit指令,这是为什么呢?

MDove:是这样的,编译器需要确保方法中调用过的每条monitorenter指令都要执行对应的monitorexit 指令。为了保证在方法异常时,monitorenter和monitorexit指令也能正常配对执行,编译器会自动产生一个异常处理器,它的目的就是用来执行 异常的monitorexit指令。而字节码中多出的monitorexit指令,就是异常结束时,被执行用来释放monitor的。

小A:我们刚才看的是同步代码块的原理,那么直接修饰在方法上呢?也是通过这个俩个指令吗?

MDove:你别说,还真不是:

public synchronized void fun() {    i++;}复制代码

MDove:可以看到:字节码中并没有monitorenter指令和monitorexit指令,取得代之的是ACC_SYNCHRONIZED标识,JVM通过ACC_SYNCHRONIZED标识,就可以知道这是一个需要同步的方法,进而执行上述同步的过程,也就是_count加1,这些过程。

小A:哦,原来是这样。一个是用了指令,一个是用的标识呀~对了,我听说synchronized的性能特别低是这样么?

MDove:这句话不全对,JDK1.5后对synchronized进行了大刀阔斧的优化,这其中涉及到偏向锁、轻量级锁、自旋锁、锁消除等手段。时候也不早了,这些内容今天就不展开了。有机会我们下次再学习吧~

剧终

感觉文章不错,欢迎分享给自己身边的小伙伴~

文章分类
后端
文章标签