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){}

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

3.偏向锁

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

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

4.轻量级锁

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

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

5.适应性自旋锁

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

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

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

总结

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

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

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

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

那我们下次再见。

往期文章推荐：

JVM专栏

消息中间件专栏

并发编程专栏