其他分享
首页 > 其他分享> > synchronized底层揭秘

synchronized底层揭秘

作者:互联网

 

前言

上篇文章我们从硬件级别探索,对可见性和有序性的认识上升了一个高度,却迟迟没有介绍原子性的解决方案。

今天我们就来聊一聊原子性的解决方案,

引入锁机制,除了可以保证原子性,同时也可以保证可见性和有序性。

相信小伙伴们对于synchronized互斥锁一定很熟悉,但是你懂它的实现原理吗,今天就让我们一起来揭开它的神秘面纱吧。

 

synchronized的原子性

首先我们来看一下synchronized是怎么保证原子性的。

其实往最简单了解释,还是比较容易理解的。synchronized加锁主要靠的是monitor,monitor在java里可以理解成一个监视器,在操作系统里它又被称为管程。

简单的模型如下图:

当我们的程序通过synchronized锁定一个对象的时候,这个对象会关联一个monitor,获取锁时会对monitor中的计数器进行+1操作,释放锁的时候进行-1操作,同时也是支持可重入的,同一个线程再次获取该对象的锁,计数器就再+1。

如果计数器为0就代表完全释放了锁,其他线程可以获取锁。

如果线程调用了wait方法,会释放锁资源,同时把线程放入waitset中,等待notifyall方法唤醒,唤醒后重新开始竞争锁资源。

这就是sychronized锁的最简单的解释,我们当然不会满足于此,接下来我们继续深入研究一下

先看一段代码:

MyLock lock = new MyLock();//一个自定义的锁对象
sychronized(lock){
//...
}

java的对象在内存中存储的布局可以分为三块区域:对象头(Header)、实例数据(Instance Data)和对齐填充(Padding)

对象头包含Mark Word(包含hashcode、锁数据、GC信息等)和Class MetaData Address(指向Class对象的指针)。

实例数据就是我们在对象里存放的那些数据。

java要求对象大小为8字节的整数倍,对齐填充就是用来填充字节的,没有其他意义。

Mark Word会指向一个monitor,这个monitor是C++实现的一个Object Monitor对象,首先线程在获取锁时,先进入到entry list中,然后通过CAS对count计数器进行+1操作,如果+1成功代表获取到锁,此时就会把该线程的信息放入owner中,owner就是用来存储当前获取到锁的线程的。整体结构如图所示:

 

 

 

 

sychronized的可见性

在说可见性之前,我们先引入两个概念:Store屏障和Load屏障

Store屏障就是强制CPU执行flush操作,Load屏障就是强制CPU执行refresh操作。

flush和refresh我们上篇文章已经说过,这里就不再解释了。

那sychronized是如何实现可见性的呢,其实就是利用了内存屏障。如下:

sychronized(this){
   // monitorenter
   // Load内存屏障
   //...  
}
//monitorexit
//Store内存屏障

 

sychronized的有序性

同样在说有序性之前引入两个新的内存屏障:Acquire屏障和Release屏障

Acquire屏障可以禁止读操作和其他读写操作之间发生指令重排,Release屏障可以禁止写操作和其他读写操作之间发生指令重排。

那sychronized是如何实现有序性的呢,其实就是利用了这两个内存屏障。如下:

sychronized(this){
   // monitorenter
   // Load内存屏障
   // Acquire内存屏障
   //...  
   //Release内存屏障
}
 //monitorexit
 //Store内存屏障

需要注意的是Acquire屏障和Release屏障保证的是sychronized内部的代码不会与外部的代码之间发生指令重排,内部的代码自己还是可能发生指令重排的。

 

sychronized的锁优化

jdk1.6后jvm对sychronized进行了锁优化,这部分我们做个概念了解就可以了。

1.锁消除

锁消除是JIT编译器对sychronized的优化,在编译的时候会通过逃逸分析技术,来分析锁对象。如果只有一个线程来加锁和解锁,没有锁竞争,那就没有必要加锁,会去掉monitorenter和monitorexit指令。

2.锁粗化

这个意思是,如果有多个连续的加锁释放锁操作,那么编译后会变成一把锁。

例如

sychronized(this){}

sychronized(this){}

sychronized(this){}

连着三个加锁操作,编译后会变成一个。

3.偏向锁

偏向锁主要是为了减少monitorenter和monitorexit指令的CAS操作,减少开销,如果认为当前锁大概率只有一个线程来竞争,那么就会给这个锁维护好一个偏好Bias,之后该线程加锁和释放锁都通过这个Bias来执行,不需要去执行CAS了。

但是如果发现有其他线程来竞争锁,就会收回之前分配好的偏好。

4.轻量级锁

如果偏向锁没能实现,也就是说有多个线程竞争锁,那么就会采用轻量级锁。

其实就是将对象里的轻量级锁指针指向一个已经获取了锁的线程,然后判断一下是不是自己加的锁,如果是就直接执行,如果不是说明有其他线程加了锁,就会升级为重量级锁,重量级锁流程我们上文中介绍原子性的时候已经说过了。

5.适应性自旋锁

在许多场景中,同步资源的锁定时间很短,为了这一小段时间去切换线程,线程挂起和恢复的花费可能会让系统得不偿失。为了让当前线程“稍等一下”,我们需让当前线程进行自旋。

如果在自旋完成后前面锁同步资源的线程已经释放了锁,那么当前线程就可以不必阻塞而是直接获取同步资源,从而避免了切换线程的开销。这就是自旋锁。

适应性自旋锁意味着自旋的时间(次数)不再固定,而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。

 

总结

到这里,有关synchronized的底层实现我们基本上已经聊完了。

使用锁来保证原子性,使用内存屏障来保证可见性和有序性。

同时jvm又对sychronized做了一些优化。

相信小伙伴们理解了本文的内容,会收获颇丰。

那我们下次再见。

 

往期文章推荐:

JVM专栏

消息中间件专栏

并发编程专栏

 

标签:加锁,synchronized,屏障,线程,内存,sychronized,揭秘,底层
来源: https://blog.51cto.com/u_14612575/2741083