JAVA对象分析之偏向锁、轻量级锁、重量级锁升级过程

在HotSpot虚拟机里，对象在堆内存中的存储布局能够划分为三个部分：

对象头（Header）

实例数据（Instance Data）

对齐填充（Padding）。

对象头

HotSpot虚拟机(后面没有说明的话默认是这个虚拟机)对象头包括三部分:

一、Mark Word

二、指向类的指针

三、数组长度（只有数组对象才有）

对象头之Mark Word

Mark Word记录了对象和锁有关的信息，当这个对象被synchronized关键字当成同步锁时，围绕这个锁的一系列操做都和Mark Word有关。

Mark Word在32位JVM中的长度是32bit，在64位JVM中长度是64bit。

Mark Word在不一样的锁状态下存储的内容不一样，在32位JVM中是这么存的:

一共32位,两位用来记录锁的信息,1位用来记录是不是偏向锁,若是偏向锁是1的话,那么会分配23位来记录偏向的线程id,当计算过Hash后,意味着会分配25bit来记录HashCode,那么久没有空间用来记录偏向锁的线程ID了,因此计算过HashCode后就无法再进入偏向锁。若是进入轻量级锁或者重量级锁,意味着会用30bit指向指针,那么此时对象头中就只有两种信息,锁标志、指向锁的指针。

其中无锁和偏向锁的锁标志位都是01，只是在前面的1bit区分了这是无锁状态仍是偏向锁状态。

JDK1.6之后的版本在处理同步锁时存在锁升级的概念，JVM对于同步锁的处理是从偏向锁开始的，随着竞争愈来愈激烈，处理方式从偏向锁升级到轻量级锁，最终升级到重量级锁。

结合Mark Word分析锁升级的流程：

1，当没有被当成锁时，这就是一个普通的对象，Mark Word记录对象的HashCode，锁标志位是01，是否偏向锁那一位是0(0则false , 1 则true)。

2，当对象被当作同步锁并有一个线程A抢到了锁时，锁标志位仍是01，可是否偏向锁那一位改为1，前23bit记录抢到锁的线程id，表示进入偏向锁状态。

3，当线程A再次试图来得到锁时，JVM发现同步锁对象的标志位是01，是否偏向锁是1，也就是偏向状态，Mark Word中记录的线程id就是线程A本身的id，表示线程A已经得到了这个偏向锁，能够执行同步锁的代码。

4，当线程B试图得到这个锁时，JVM发现同步锁处于偏向状态，可是Mark Word中的线程id记录的不是B，那么线程B会先用CAS操做试图得到锁，这里的得到锁操做是有可能成功的，由于线程A通常不会自动释放偏向锁。若是抢锁成功，就把Mark Word里的线程id改成线程B的id，表明线程B得到了这个偏向锁，能够执行同步锁代码。若是抢锁失败，则继续执行步骤5。

5，偏向锁状态抢锁失败，表明当前锁有必定的竞争，偏向锁将升级为轻量级锁。JVM会在当前线程的线程栈中开辟一块单独的空间，里面保存指向对象锁Mark Word的副本，同时在对象锁Mark Word中保存指向这片空间的指针。上述两个保存操做都是CAS操做，若是保存成功，表明线程抢到了同步锁，就把Mark Word中的锁标志位改为00，能够执行同步锁代码。若是保存失败，表示抢锁失败，竞争太激烈，继续执行步骤6。

6，轻量级锁抢锁失败，JVM会使用自旋锁，自旋锁不是一个锁状态，只是表明不断的重试，尝试抢锁。从JDK1.7开始，自旋锁默认启用，自旋次数由JVM决定。若是抢锁成功则执行同步锁代码，若是失败则继续执行步骤7。

7，自旋锁重试以后若是抢锁依然失败，同步锁会升级至重量级锁，锁标志位改成10。在这个状态下，未抢到锁的线程都会被阻塞。

对象头之指向类的指针

该指针在32位JVM中的长度是32bit，在64位JVM中长度是64bit。

Java对象的类数据保存在方法区。 并非全部的虚拟机实现都必须在对象数据上保留类型指针，换句话说，查找对象的元数据信息并不必定要通过对象自己。

对象头之数组长度

若是对象是一个Java数组，那在对象头中还必须有一块用于记录数组长度的数据，由于虚拟机能够经过普通Java对象的元数据信息肯定Java对象的大小，可是若是数组的长度是不肯定的，将没法经过元数据中的信息推断出数组的大小。

只有数组对象保存了这部分数据, 该数据在32位和64位JVM中长度都是32bit。

实例数据

实例数据部分是对象真正存储的有效信息，即咱们在程序代码里面所定义的各类类型的字段内容，不管是从父类继承下来的，仍是在子类中定义的字段都必须记录起来。这部分的存储顺序会受到虚拟机分配策略参数（-XX：FieldsAllocationStyle参数）和字段在Java源码中定义顺序的影响。HotSpot虚拟机默认的分配顺序为longs/doubles、ints、shorts/chars、bytes/booleans、oops（OrdinaryObject Pointers，OOPs），从以上默认的分配策略中能够看到，相同宽度的字段老是被分配到一块儿存放，在知足这个前提条件的状况下，在父类中定义的变量会出如今子类以前。若是HotSpot虚拟机的+XX：CompactFields参数值为true（默认就为true），那子类之中较窄的变量也容许插入父类变量的空隙之中，以节省出一点点空间。

对齐填充

这并非必然存在的，也没有特别的含义，它仅仅起着占位符的做用。因为HotSpot虚拟机的自动内存管理系统要求对象起始地址必须是8字节的整数倍，换句话说就是任何对象的大小都必须是8字节的整数倍。对象头部分已经被精心设计成正好是8字节的倍数（1倍或者2倍），所以，若是对象实例数据部分没有对齐的话，就须要经过对齐填充来补全。

站在巨人的肩膀上

1.<<深刻理解Java虚拟机：JVM高级特性与最佳实践（第3版） (华章原创精品)>>,周志明