synchronized底层实现原理

      基于进入和退出管程（Monitor）对象实现，不管显式（Monitorenter Monitorexit）仍是隐式都是如此。同步方法并非由monitorenter和monitorexit指令来实现同步的，而是由方法调用指令读取运行时常量池中的ACC_SYNCHRONIZED标志来隐式实现的。

    在JVM中，对象在内存中的布局分为三块区域：对象头、实例数据和对齐填充。

实例变量：存放类的属性数据信息，包括父类的属性信息，若是是数组的实例部分还包括数组的长度，这部份内存按4字节对齐。

填充数据：因为虚拟机要求对象起始地址必须是8字节的整数倍。填充数据不是必须存在的，仅仅是为了字节对齐，这点了解便可

 

而对于顶部，则是Java头对象，它实现synchronized的锁对象的基础，这点咱们重点分析它，通常而言，synchronized使用的锁对象是存储在Java对象头里的，jvm中采用2个字来存储对象头(若是对象是数组则会分配3个字，多出来的1个字记录的是数组长度)，其主要结构是由Mark Word 和 Class Metadata Address 组成

虚拟机位数	头对象结构	说明
32/64bit	Mark Word	存储对象的hashCode、锁信息或分代年龄或GC标志等信息
32/64bit	Class Metadata Address	类型指针指向对象的类元数据，JVM经过这个指针肯定该对象是哪一个类的实例。

Mark Word组成：

锁状态	25bit	4bit	1bit是不是偏向锁	2bit 锁标志位
无锁状态	对象HashCode	对象分代年龄	0	01

因为对象头的信息是与对象自身定义的数据没有关系的额外存储成本，所以考虑到JVM的空间效率，Mark Word 被设计成为一个非固定的数据结构，以便存储更多有效的数据，它会根据对象自己的状态复用本身的存储空间

如32位JVM下，除了上述列出的Mark Word默认存储结构外，还有以下可能变化的结构

锁状态	25bit		4bit	1bit	2bit
	23bit	2bit		是不是偏向锁	锁标志位
轻量级锁	指向栈中锁记录的指针				00
重量级锁	指向互斥量（重量级锁）的指针				10
GC标记	空				11
偏向锁	线程ID	Epoch	对象分代年龄	1	01

其中轻量级锁和偏向锁是Java 6 对 synchronized 锁进行优化后新增长的，稍后咱们会简要分析。这里咱们主要分析一下重量级锁也就是一般说synchronized的对象锁，锁标识位为10，其中指针指向的是monitor对象（也称为管程或监视器锁）的起始地址。每一个对象都存在着一个 monitor 与之关联，对象与其 monitor 之间的关系有存在多种实现方式，如monitor能够与对象一块儿建立销毁或当线程试图获取对象锁时自动生成，但当一个 monitor 被某个线程持有后，它便处于锁定状态。在Java虚拟机(HotSpot)中，monitor是由ObjectMonitor实现的

锁的状态总共有四种，无锁状态、偏向锁、轻量级锁和重量级锁。随着锁的竞争，锁能够从偏向锁升级到轻量级锁，再升级的重量级锁，可是锁的升级是单向的，也就是说只能从低到高升级，不会出现锁的降级

 

偏向锁

偏向锁是Java 6以后加入的新锁，它是一种针对加锁操做的优化手段，通过研究发现，在大多数状况下，锁不只不存在多线程竞争，并且老是由同一线程屡次得到，所以为了减小同一线程获取锁(会涉及到一些CAS操做,耗时)的代价而引入偏向锁。偏向锁的核心思想是，若是一个线程得到了锁，那么锁就进入偏向模式，此时Mark Word 的结构也变为偏向锁结构，当这个线程再次请求锁时，无需再作任何同步操做，即获取锁的过程，这样就省去了大量有关锁申请的操做，从而也就提供程序的性能。因此，对于没有锁竞争的场合，偏向锁有很好的优化效果，毕竟极有可能连续屡次是同一个线程申请相同的锁。可是对于锁竞争比较激烈的场合，偏向锁就失效了，由于这样场合极有可能每次申请锁的线程都是不相同的，所以这种场合下不该该使用偏向锁，不然会得不偿失，须要注意的是，偏向锁失败后，并不会当即膨胀为重量级锁，而是先升级为轻量级锁。下面咱们接着了解轻量级锁。

 

 

轻量级锁

假若偏向锁失败，虚拟机并不会当即升级为重量级锁，它还会尝试使用一种称为轻量级锁的优化手段(1.6以后加入的)，此时Mark Word 的结构也变为轻量级锁的结构。轻量级锁可以提高程序性能的依据是“对绝大部分的锁，在整个同步周期内都不存在竞争”，注意这是经验数据。须要了解的是，轻量级锁所适应的场景是线程交替执行同步块的场合，若是存在同一时间访问同一锁的场合，就会致使轻量级锁膨胀为重量级锁。

 

 

自旋锁

轻量级锁失败后，虚拟机为了不线程真实地在操做系统层面挂起，还会进行一项称为自旋锁的优化手段。这是基于在大多数状况下，线程持有锁的时间都不会太长，若是直接挂起操做系统层面的线程可能会得不偿失，毕竟操做系统实现线程之间的切换时须要从用户态转换到核心态，这个状态之间的转换须要相对比较长的时间，时间成本相对较高，所以自旋锁会假设在不久未来，当前的线程能够得到锁，所以虚拟机会让当前想要获取锁的线程作几个空循环(这也是称为自旋的缘由)，通常不会过久，多是50个循环或100循环，在通过若干次循环后，若是获得锁，就顺利进入临界区。若是还不能得到锁，那就会将线程在操做系统层面挂起，这就是自旋锁的优化方式，这种方式确实也是能够提高效率的。最后没办法也就只能升级为重量级锁了。

锁消除

消除锁是虚拟机另一种锁的优化，这种优化更完全，Java虚拟机在JIT编译时(能够简单理解为当某段代码即将第一次被执行时进行编译，又称即时编译)，经过对运行上下文的扫描，去除不可能存在共享资源竞争的锁，经过这种方式消除没有必要的锁，能够节省毫无心义的请求锁时间，以下StringBuffer的append是一个同步方法，可是在add方法中的StringBuffer属于一个局部变量，而且不会被其余线程所使用，所以StringBuffer不可能存在共享资源竞争的情景，JVM会自动将其锁消除。

synchronized的可重入性

从互斥锁的设计上来讲，当一个线程试图操做一个由其余线程持有的对象锁的临界资源时，将会处于阻塞状态，但当一个线程再次请求本身持有对象锁的临界资源时，这种状况属于重入锁，请求将会成功，在java中synchronized是基于原子性的内部锁机制，是可重入的，所以在一个线程调用synchronized方法的同时在其方法体内部调用该对象另外一个synchronized方法，也就是说一个线程获得一个对象锁后再次请求该对象锁，是容许的，这就是synchronized的可重入性。