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做了一些优化。
相信小伙伴们理解了本文的内容，会收获颇丰。
那我们下次再见。
往期文章推荐：
标签：加锁,synchronized,屏障,线程,内存,sychronized,揭秘,底层 来源： https://blog.51cto.com/u_14612575/2741083