对象内存布局和synchronized锁升级

1. 对象内存布局

1.1 内存布局

堆中的对象由对象头 + 实例数据 + 对齐填充数据构成。

对象头由类型指针和运行时元数据组成

• 类型指针：指向类元数据，即标明该对象所属类型
• 运行时元数据：哈希值 + GC分代年龄 + 锁状态标志 + 线程持有锁 + 偏向线程ID + 偏向时间戳

类型指针结构如图所示：

实例数据存储对象真正的有效信息，包括父类及自己本身拥有的字段。父类中的成员出现在子类之前，相同宽度的成员被分配在一起

对齐填充仅起到占位符的作用，不是必须的。

1.2 面试提问

以下对象内存信息由这个JOL小工具打印，咋Maven中导入包即可

<dependency>
    <groupId>org.openjdk.jol</groupId>
    <artifactId>jol-core</artifactId>
    <version>0.9</version>
</dependency>

1.2.1 new一个对象，占多少内存

对象分为有无成员变量，

• 如果没有，那就是16个字节【对象标记（8）和类元信息（8）】

举例如下：

Object o = new Object();
System.out.println(ClassLayout.parseInstance(o).toPrintable()); // 打印类元信息的工具

java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           01 00 00 00 (00000001 00000000 00000000 00000000) (1)
      4     4        (object header)                           00 00 00 00 (00000000 00000000 00000000 00000000) (0)
      8     4        (object header)                           e5 01 00 20 (11100101 00000001 00000000 00100000) (536871397)
     12     4        (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

扩展：打印出来的类型指针的查看顺序是：

一个字节内从左到右，整体从右到左，即化为人看到的顺序是：

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001

因为没有调用hash，所有这个对象的hash为空

并且根据最后的001可以确定，该对象处于无锁状态

可以看到前8个字节是类型指针，并且是无锁的状态，下面的4个字节是类元信息。不对呀，类元信息不是8个字节大小吗？因为这里存在着压缩指针，后面细说，下来就是填充数据4个字节。

• 如果有，根据对象的成员变量来决定对象的内存大小

class Student{
    int id;
    boolean flag;
}


com.shang.Object.Student object internals:
 OFFSET  SIZE      TYPE DESCRIPTION                               VALUE
      0     4           (object header)                           01 00 00 00 (00000001 00000000 00000000 00000000) (1)
      4     4           (object header)                           00 00 00 00 (00000000 00000000 00000000 00000000) (0)
      8     4           (object header)                           43 c1 00 20 (01000011 11000001 00000000 00100000) (536920387)
     12     4       int Student.id                                0
     16     1   boolean Student.flag                              false
     17     7           (loss due to the next object alignment)
Instance size: 24 bytes
Space losses: 0 bytes internal + 7 bytes external = 7 bytes total

可以看到 对象标记（8） + 类型指针（4） + 成员变量id （4）+ 成员变量flag（1） + 填充数据 （7） = 24

1.2.2 对象的hashCode存在对象的什么地方？

由上图可知，存在于对象头的对象标记出，无锁的情况是从第25 位 到 25 + 31位

1.2.3 锁对象对象如何得知？

查看对象头的前一个字节的后三位就可以知道状态了。

个人理解：为啥吧对象锁的状态放在第一个字节处，应该就是方便查找。

1.3 压缩指针

为什么对象指针，可以用8字节存也可以用4字节存？4字节存不会有什么问题吗？

1.3.1 不开启压缩指针

不开启指针压缩的情况下是，java对象是怎么存储的

采用8字节（64位）存储真实内存地址，比之前采用4字节（32位）压缩存储地址带来的问题：

• 增加了GC开销：64位对象引用需要占用更多的堆空间，留给其他数据的空间将会减少，从而加快了GC的发生，更频繁的进行GC。

• 降低CPU缓存命中率：64位对象引用增大了，CPU能缓存的oop将会更少，从而降低了CPU缓存的效率。

1.3.2 开启指针压缩

既然64位存储内存地址，会导致了这么多问题，那么我们可以不可以找一种方法，既使用之前的4字节（32位）存指针地址，又可以扩大内存的方法呢？

答案就是采用指针压缩技术！！

4个字节，32位，可以表示232 个地址，如果这个地址是真实内存地址的话，那么由于CPU寻址的最小单位是byte，也就是 232 byte = 4GB。

如果内存地址是指向 bit的话，32位的最大寻址范围其实是 512MB，但是由于内存里，将8bit为一组划分，所以内存地址就其实是指向的8bit为一组的byte地址，所以32位可以表示的容量就扩充了8倍，就变成了4GB。

4字节，8位最大表示4GB内存。那么Java是怎么做到 4个字节表示32GB呢？怎有扩大了8倍？？？

这就要使用到之前提到的Java的对齐填充机制了。Java的8字节对齐填充，就像是内存的8bit为一组，变为1byte一样。这里的压缩指针，不是真实的操作系统内存地址，而是Java进行8byte映射之后的地址，所以也相对于操作系统的指针有进行的8倍的扩容。

看下图：
JVM就将堆内存进行了块划分，以8字节为最小单位进行划分。

想一想？这里运用的原理是不是和操作系统32位表示4GB内存的原理一毛一样！！！我想着也是java做对齐填充的一重大原因吧！！

也就解释了为什么当内存大于32GB时，开启指针压缩的参数会失效！所以也网上建议大家在64位系统系下，JAVA的堆内存设置最好不要超过32G，一旦超过32G后，指针压缩就会失效，然后带来GC的触发频次变高，而且造成空间浪费。

注意：

32G是个近似值，这个临界值跟JVM和平台有关，当我们线上真正启动服务的时候直接设置 -Xmx=32GB 的时候很可能导致 CompressedOop 失效，那我们怎么确定当前环境下最大内存设置多大才且最大限度的使用内存才能启动 CompressedOop 呢？我们可以通过增加JVM参数 -XX:+PrintFlagsFinal，验证UseCompressedOops的值，从而得知，到底是不是真的开启了压缩指针，还是压缩指针失效！

2. Synchronized锁升级

总览

2.1 Synchronized的性能变化

1. Java5以前，有Synchronized,这个是操作系统级别的重量级操作,重量级锁,假如锁的竞争比较激烈的话,性能下降

2. 在Java早期版本中,synchronized属于重量级锁,效率低下,因为监视器锁(monitor)是依赖于底层的操作系统的Mutex Lock来实现的,挂起线程和恢复线程都需要转入内核态去完成,阻塞或唤醒一个Java线程需要操作系统切换CPU状态来完成,这种状态切换需要耗费处理器时间,如果同步代码块中内容过于简单,这种切换的时间可能比用户代码执行的时间还长”,时间成本相对较高,这也是为什么早期的synchronized效率低的原因

   Java 6之后,为了减少获得锁和释放锁所带来的性能消耗,引入了轻量级锁和偏向锁

3. 为什么每一个对象都可以成为一个锁？

   • Java对象是天生的Monitor,每一个Java对象都有成为Monitor的潜质,因为在Java的设计中 ,每一个Java对象自打娘胎里出来就带了一把看不见的锁,它叫做内部锁或者Monitor锁。
   • Monitor的本质是依赖于底层操作系统的Mutex Lock实现,操作系统实现线程之间的切换需要从用户态到内核态的转换,成本非常高

ObjectMonitor* monitor const {
    assert(has_monitor(), "check");
    return (ObjectMonitor*) (value() ^ monitor_value);
}

4. Mutex Lock

   Monitor是在jvm底层实现的,底层代码是c++。本质是依赖于底层操作系统的Mutex Lock实现,操作系统实现线程之间的切换需要从用户态到内核态的转换,状态转换需要耗费很多的处理器时间成本非常高。所以synchronized是Java语言中的一个重量级操作。

5. Java 6之后,为了减少获得锁和释放锁所带来的性能消耗,引入了轻量级锁和偏向锁,需要有个逐步升级的过程,别一开始就捅到重量级锁

6. synchronized锁:由对象头中的Mark Word根据锁标志位的不同而被复用及锁升级策略

2.2 无锁

代码展示：

Student student = new Student();
System.out.println("10进制hash码:"+student.hashCode());
System.out.println("16进制hash码:"+Integer.toHexString(student.hashCode()));
System.out.println("2进制hash码:"+Integer.toBinaryString(student.hashCode()));
System.out.println(ClassLayout.parseInstance(student).toPrintable());

程序不存在锁的竞争

2.3 偏向锁

2.3.1 作用

当一段同步代码一直被同一个线程多次访问,由于只有一个线程那么该线程在后续访问时便会自动获得锁(偏向锁)

同一个老顾客来访,直接老规矩行方便

偏向锁为了解决只有在一个线程执行同步时提高性能

2.3.2 偏向锁的理论

1. 在实际应用运行过程中发现,“锁总是同一个线程持有,很少发生竞争”,也就是说锁总是被第一个占用他的线程拥有,这个线程就是锁的偏向线程
2. 那么只需要在锁第一次被拥有的时候,记录下偏向线程ID。这样偏向线程就一直持有着锁(后续这个线程进入和退出这段加了同步锁的代码块时,不需要再次加锁和释放锁。而是直接比较对象头里面是否存储了指向当前线程的偏向锁)。
3. 如果相等表示偏向锁是偏向于当前线程的,就不需要再尝试获得锁了,直到竞争发生才释放锁。以后每次同步,检查锁的偏向线程ID与当前线程ID是否一致,如果一致直接进入同步。无需每次加锁解锁都去CAS更新对象头。如果自始至终使用锁的线程只有一个,很明显偏向锁几乎没有额外开销,性能极高。
4. 假如不一致意味着发生了竞争,锁已经不是总是偏向于同一个线程了,这时候可能需要升级变为轻量级锁,才能保证线程间公平竞争锁。偏向锁只有遇到其他线程尝试竞争偏向锁时,持有偏向锁的线程才会释放锁,线程是不会主动释放偏向锁的

2.3.3 技术实现

一个synchronized方法被一个线程抢到了锁时,那这个方法所在的对象就会在其所在的Mark Word中将偏向锁修改状态位,同时还会有占用前54位来存储线程指针作为标识。若该线程再次访问同一个synchronized方法时,该线程只需去对象头的Mark Word 中去判断一下是否有偏向锁指向本身的ID,无需再进入Monitor去竞争对象了。

2.3.4 步骤优化

步骤：

1. 偏向锁的操作不用直接捅到操作系统,不涉及用户到内核转换,不必要直接升级为最高级,我们以一个account对象的“对象头”为例

   

2. 假如有一个线程执行到synchronized代码块的时候,JVM使用CAS操作把线程指针ID记录到Mark Word当中,并修改标偏向标示,标示当前线程就获得该锁。锁对象变成偏向锁(通过CAS修改对象头里的锁标志位),字面意思是“偏向于第一个获得它的线程”的锁。执行完同步代码块后,线程并不会主动释放偏向锁。
   

3. 这时线程获得了锁,可以执行同步代码块。当该线程第二次到达同步代码块时会判断此时持有锁的线程是否还是自己(持有锁的线程ID也在对象头里),JVM通过account对象的Mark Word判断:当前线程ID还在,说明还持有着这个对象的锁,就可以继续进入临界区工作。由于之前没有释放锁,这里也就不需要重新加锁。 如果自始至终使用锁的线程只有一个,很明显偏向锁几乎没有额外开销,性能极高。

4. 结论: JVM不用和操作系统协商设置Mutex(争取内核),它只需要记录下线程ID就标示自己获得了当前锁,不用操作系统接入。

5. 上述就是偏向锁:在没有其他线程竞争的时候,一直偏向偏心当前线程,当前线程可以一直执行。

2.3.5 参数说明

* 实际上偏向锁在JDK1.6之后是默认开启的,但是启动时间有延迟,
* 所以需要添加参数-XX:BiasedLockingStartupDelay=0,让其在程序启动时立刻启动。
* 开启偏向锁:
* -XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0
* 关闭偏向锁:关闭之后程序默认会直接进入轻量级锁状态。
* -XX:-UseBiasedLocking

2.3.6 代码展示

1. 偏向锁在JDK1.6以上默认开启,开启后程序启动几秒后才会被激活,可以使用JVM参数来关闭延迟 -XX:BiasedLockingStartupDelay=0
2. 如果确定锁通常处于竞争状态则可通过JVM参数 -XX:-UseBiasedLocking 关闭偏向锁,那么默认会进入轻量级锁

public class MyObject{
    public static void main(String[] args){
        Object o = new Object();

        new Thread(() -> {
            synchronized (o){
                System.out.println(ClassLayout.parseInstance(o).toPrintable());
            }
        },"t1").start();
    }
}

2.3.7 偏向锁的撤销

偏向锁使用一种等到竞争出现才释放锁的机制,只有当其他线程竞争锁时,持有偏向锁的原来线程才会被撤销。撤销需要等待全局安全点(该时间点上没有字节码正在执行),同时检查持有偏向锁的线程是否还在执行)

1. 第一个线程正在执行synchronized方法(处于同步块),它还没有执行完,其它线程来抢夺,该偏向锁会被取消掉并出现锁升级
   此时轻量级锁由原持有偏向锁的线程持有,继续执行其同步代码,而正在竞争的线程会进入自旋等待获得该轻量级锁
2. 第一个线程执行完成synchronized方法(退出同步块),则将对象头设置成无锁状态并撤销偏向锁 ,重新偏向
3. 可以理解为：其实如果线程A执行完毕,如果不再去竞争,那么就会重设线程B为偏向锁;如果线程A继续竞争,那么就会CAS自旋，也就升级到了轻量级锁

2.4 轻量级锁：多个线程竞争

主要作用(本质就是自旋锁)：有线程来参与锁的竞争,但是获取锁的冲突时间极短

从标志位来看

2.4.1 轻量级锁的获取

理论落地

(1) 轻量级锁是为了在线程近乎交替执行同步块时提高性能

(2) 主要目的: 在没有多线程竞争的前提下,通过CAS减少重量级锁使用操作系统互斥量产生的性能消耗,说白了先自旋再阻塞

(3) 升级时机:当关闭偏向锁功能或多线程竞争偏向锁会导致偏向锁升级为轻量级锁

(4) 假如线程A已经拿到锁,这时线程B又来抢该对象的锁,由于该对象的锁已经被线程A拿到,当前该锁已是偏向锁了。
而线程B在争抢时发现对象头Mark Word中的线程ID不是线程B自己的线程ID(而是线程A),那线程B就会进行CAS操作希望能获得锁。

此时线程B操作中有两种情况
如果锁获取成功,直接替换Mark Word中的线程ID为B自己的ID(A → B),重新偏向于其他线程(即将偏向锁交给其他线程,相当于当前线程"被"释放了锁),该锁会保持偏向锁状态,A线程Over,B线程上位

如果锁获取失败,则偏向锁升级为轻量级锁,此时轻量级锁由原持有偏向锁的线程持有,继续执行其同步代码,而正在竞争的线程B会进入自旋等待获得该轻量级锁。

2.4.2 代码展示

如果关闭偏向锁,就可以直接进入轻量级锁 -XX:-UseBiasedLocking

2.4.3 如何升级为轻量级锁

需要自旋到达一定次数和程度

• java6之前(了解):默认启用,默认情况下自旋的次数是10次,-XX:PreBlockSpin=10来修改或者自旋线程数超过cpu核数一半
• Java6之后:自适应(自适应意味着自旋的次数不是固定不变的),而是根据:同一个锁上一次自旋的时间和拥有锁线程的状态来决定。

2.3.4 轻量级锁和偏向锁的区别和不同

1. 争夺轻量级锁失败时,自旋尝试抢占锁
2. 轻量级锁每次退出同步块都需要释放锁,而偏向锁是在竞争发生时才释放锁

2.5 重锁 存在用户态、内核态切换

• 有大量的线程参与锁的竞争,冲突性很高
• 锁标志位

2.6 各种锁优缺点、synchronized锁升级和实现原理

2.6.1 各个锁的优缺点的对比

synchronized锁升级过程总结:一句话,就是先自旋,不行再阻塞。

实际上是把之前的悲观锁(重量级锁)变成在一定条件下使用偏向锁以及使用轻量级(自旋锁CAS)的形式

2.6.2 总结

1. 偏向锁:适用于单线程适用的情况,在不存在锁竞争的时候进入同步方法/代码块则使用偏向锁。
2. 轻量级锁:适用于竞争较不激烈的情况(这和乐观锁的使用范围类似), 存在竞争时升级为轻量级锁,轻量级锁采用的是自旋锁,如果同步方法/代码块执行时间很短的话,采用轻量级锁虽然会占用cpu资源但是相对比使用重量级锁还是更高效。
3. 重量级锁:适用于竞争激烈的情况,如果同步方法/代码块执行时间很长,那么使用轻量级锁自旋带来的性能消耗就比使用重量级锁更严重,这时候就需要升级为重量级锁

2.7 锁消除

锁消除: 从JIT角度看相当于无视它,synchronized (o)不存在了,这个锁对象并没有被共用扩散到其它线程使用,极端的说就是根本没有加这个锁对象的底层机器码,消除了锁的使用

**
 * 锁消除
 * 从JIT角度看相当于无视它,synchronized (o)不存在了,这个锁对象并没有被共用扩散到其它线程使用,
 * 极端的说就是根本没有加这个锁对象的底层机器码,消除了锁的使用
 */
public class LockClearUPDemo{
    static Object objectLock = new Object();//正常的

    public void m1(){
        //锁消除,JIT会无视它,synchronized(对象锁)不存在了。不正常的
        Object o = new Object();

        synchronized (o){
            System.out.println("-----hello LockClearUPDemo"+"\t"+o.hashCode()+"\t"+objectLock.hashCode());
        }
    }

    public static void main(String[] args){
        LockClearUPDemo demo = new LockClearUPDemo();

        for (int i = 1; i <=10; i++) {
            new Thread(() -> {
                demo.m1();
            },String.valueOf(i)).start();
        }
    }
}

2.8 锁粗化

锁粗化 : 假如方法中首尾相接,前后相邻的都是同一个锁对象,那JIT编译器就会把这几个synchronized块合并成一个大块,加粗加大范围,一次申请锁使用即可,避免次次的申请和释放锁,提升了性能

/**
 * 锁粗化
 * 假如方法中首尾相接,前后相邻的都是同一个锁对象,那JIT编译器就会把这几个synchronized块合并成一个大块,
 * 加粗加大范围,一次申请锁使用即可,避免次次的申请和释放锁,提升了性能
 */
public class LockBigDemo
{
    static Object objectLock = new Object();


    public static void main(String[] args)
    {
        new Thread(() -> {
            synchronized (objectLock) {
                System.out.println("11111");
            }
            synchronized (objectLock) {
                System.out.println("22222");
            }
            synchronized (objectLock) {
                System.out.println("33333");
            }
        },"a").start();

        new Thread(() -> {
            synchronized (objectLock) {
                System.out.println("44444");
            }
            synchronized (objectLock) {
                System.out.println("55555");
            }
            synchronized (objectLock) {
                System.out.println("66666");
            }
        },"b").start();

    }
}

参考博文：
Juc20_Synchronized锁升级、无锁、偏向锁、轻量级锁、重量级锁、锁消除、锁粗化
聊一聊JAVA指针压缩的实现原理（图文并茂，让你秒懂）