jvm对象创建创建过程以及重排序问题

￡神魔★判官ぃ 2023-09-30 09:35 13阅读 0赞

**目录**

一、jvm对象创建

1.对象创建过程

2.新创建对象的大小

3.对象头的简单介绍

4.对象定位方式

二、指令重排

1.硬件层次数据一致性

2.jvm保证有序性

三、volatile以及synchronized的实现

1.volatile

2.synchronized

--------------------

## 一、jvm对象创建 ##

#### 1.对象创建过程 ####

1)首先判断对应类是否加载，如果已经加载，则跳过这一步，如果没有加载则进入类加载过程，loading->linking->initializing;

2)为新建对象申请内存；

3)为普通成员变量赋默认值，例如private int a = 12，此时a的值为0；

4)为普通成员变量赋初始值(此时a的值才会为12)，并且调用构造方法；

#### 2.新创建对象的大小 ####

对于新创建的对象，对象大小主要分为下面两种情况：

1）普通对象（没有成员变量）：(1)对象头(markwords)8byte；(2)类指针4byte(一般都会开启类指针压缩，所以为4byte，命令为-XX:+UseCompressedClassPointers，如果关闭类指针压缩，则指针大小为8bte)；（3）实例数据，因为没有成员变量所以为0；(4)padding对齐（保证整个对象大小为8的倍数），一个空对象无论是否开启类指针压缩，大小都为16byte。

2）数组对象：(1)对象头(markwords)8byte；(2)类指针4byte(或者8byte)；（3）数组长度4byte；(4)padding对齐（保证整个对象大小为8的倍数）。一个新创建的数据对象，如果开启类指针压缩，大小为16字节，否则为24字节。

(*需要注意一个区别，classPointer和Oops(ordinary object pointers)，前者是每个新建对象都存在的指针，是公共属性，而后者指的是成员变量存在非基本类型的对象时，存在的指针，同样如果开启压缩是4个指针，如果不开启压缩是8个指针，通过-XX:+(-)UseCompressedOops来开启(关闭)*)

#### 3.对象头的简单介绍 ####

对象头存储的信息根据当前对象持有锁的状态不同，存储的信息也不相同。

1）锁标志位，无锁/偏向锁为01，轻量级锁00，重量级锁10，gc标识11

2）是否为偏向锁以及分带年龄只有无锁和偏向锁有，0无偏向锁，1有偏向锁

3）无锁还有独属于自己的对象的hashcode，但是这个hashcode并不是初始化的时候就存在，只有调用对象的hashcode方法以后，才会存在，并且重写过的hashcode方法是不会生效的；偏向锁存在线程id以及epoch；轻量级锁存在指向栈中锁记录的指针；重量级锁指向互斥量的指针。

（*当一个对象执行过identityHashCode以后是无法进入偏向锁状态的，因为记录偏向锁的位置被对象的hashcode占用*）

#### 4.对象定位方式 ####

1）句柄池：指针不直接指向对象的相关信息，而是由句柄池统一管理，指针先指向句柄池，然后由句柄池再指向具体对象，gc效率高，访问效率低；

2）直接指针：指针直接指向对象，范文效率高，gc效率低，hotspot目前采用该指针。

## 二、指令重排 ##

下面的代码为单例模式的双重检查创建方式的代码

public class Single {
        // 声明一个静态变量，使用volatile关键字修饰
        private static volatile Single INSTANCE;
        private Single(){
    
        }
        
        public static Single getInstance(){
            // 对实例进行判断，如果已经创建，则直接返回；如果没有创建则进入创建流程
            if (INSTANCE == null){
                // 进行加锁处理，防止并发
                synchronized (Single.class){
                    // 在进行一次非空判断，防止在第一次判断到加锁之间，有其他线程完成了对象的创建
                    if (INSTANCE == null){
                        INSTANCE = new Single();
                    }
                }
            }
            return INSTANCE;
        }
    }

上面中静态变量使用了volatile关键字进行了修饰，并且这是必须要使用的，原因就是该关键字防止指令重新排序。在上面也说了在创建对象的时候，成员变量赋初始值和赋默认值是两步操作，如果第一个线程进来以后，到了new Single()，此时jvm中只进行初始值的赋值操作，然后Instance就指向了这个对象，然后第二个线程并发获取该对象，获取到了该对象就拿去使用，那么就会出现取值并发问题。

因此就需要考虑如何避免指令重排。

#### 1.硬件层次数据一致性 ####

硬件层次采用缓存锁+总线锁的方式来保证数据的一致性。其中总线锁指的是每次去读取信息的时候，添加一个总锁，这样其他cpu就需等待上一个cpu读取完毕以后才可以继续读取，如果只有总线锁，那么效率就会很低，因此出现了缓存锁。缓存锁使用各种一致性协议实现，比较常用的是mesi一致性协议，它给每个缓存行做一个标记，这个标记分为四种：modified(修改)，shared(共享)，invalid(被其他cpu更改)，exclusive(独享)。这些状态是跟主内存中的数据进行比较。为什么采用缓存锁和总线锁一起来保证数据一致性呢，因为有些数据无法被缓存或者一个缓存行无法存储，这时候就需要用到总线锁。

缓存行是读取缓存的基本单位，一般情况每个缓存行的大小为64byte，例如定义一个int变量，大小为2个字节，在读取的时候不会只读取这个int变量，如果后面还有其它变量，那么会一起读取，一直到64byte，这就会出现一个问题，现在有两个变量：int x和int y，被读取到同一个缓存行中，此时一个cpu先读取到这个缓存行，并对x进行修改，此时这个标记为m，另一个也读取到这个缓存行，由于被上一个cpu修改，那么此时就无法读取y，此时就会出现效率问题。那么解决的办法就是对x和y进行补位处理，每个变量都补到64byte，独占一个缓存行，那么就可以解决上述问题。

为了提高运行效率，cpu在没有依赖关系的前提之下会打乱执行顺序，组合出一个比较高效的执行顺序来执行指令。cpu可以通过一些指令来控制指令重排，保证指令有序有序执行，即cpu内存屏障(不同cpu的实现不同)。包含以下三种屏障（intel cpu）：

1)sfence，在sfence之前的写操作必须在sfence之后的写操作写之前完成

2)lfence，在lfence之前的读操作必须在lfence之后的读操作读取之前玩成

3)mfence，在mfence之前的读写操作必须在mfence之后的读写操作读写之前完成

#### 2.jvm保证有序性 ####

jvm的有序性实现是依靠硬件层次的有序性实现，不只是包含上面提到的cpu内存屏障，还有可能是lock汇编指定(对于这一块我也不是很了解)等。

jvm有序性主要靠以下四种屏障实现：

1)loadload：load1:loadload:load2，表示在load2以及之后读操作要读取的数据在被访问之前，load1读取的数据必须先被访问

2)storestore：store1:storestore:store2，表示在store2以及之后要写的数据在被写之前，store1写的数据必须先完成写操作并对其它线程可见

3)loadstore：load1:storestore:store2，表示在store2以及之后要写的数据在被写之前，load1读取的数据必须先被访问

4)storeload：store1:loadload:load2，表示在load2以及之后读操作要读取的数据在被访问之前，store1写的数据必须先完成写操作并对其它线程可见。

## 三、volatile以及synchronized的实现 ##

在java中有两个关键字可以防止指令重排，他们就是volatile和synchronized。接下来说一下它们两个的具体实现。

#### 1.volatile ####

在字节码层面：添加了ACC\_VOLATILE标识，可以使用jClasslib插件查看，如下图：

![watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBAd2VpeGluXzM4NjEyNDAx_size_20_color_FFFFFF_t_70_g_se_x_16][]

在jvm层面：loadload屏障：volatile读操作：loadstore屏障；storestore屏障：volatile写操作： storeload屏障

#### 2.synchronized ####

在字节码层面：修饰方法时添加了ACC\_SYNCHRONIZED，如下图：

![watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBAd2VpeGluXzM4NjEyNDAx_size_20_color_FFFFFF_t_70_g_se_x_16 1][]

修饰代码块添加了一组指令monitorenter和monitorexit，如下图：

![watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBAd2VpeGluXzM4NjEyNDAx_size_20_color_FFFFFF_t_70_g_se_x_16 2][]

上图中出现了两次 monitorexit，那么原因是什么呢，原因就是一个monitorexit是代码块正常结束的时候执行的退出，一个monitorexit是代码块出现异常的时候执行的退出。

在jvm层面：C C++调用了操作系统提供的同步机制。

[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBAd2VpeGluXzM4NjEyNDAx_size_20_color_FFFFFF_t_70_g_se_x_16]: https://img-blog.csdnimg.cn/70c0257a59a14588bd8c02fa1637c7ff.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBAd2VpeGluXzM4NjEyNDAx,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBAd2VpeGluXzM4NjEyNDAx_size_20_color_FFFFFF_t_70_g_se_x_16 1]: https://img-blog.csdnimg.cn/d759188d90a04047ba19124667e37475.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBAd2VpeGluXzM4NjEyNDAx,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBAd2VpeGluXzM4NjEyNDAx_size_20_color_FFFFFF_t_70_g_se_x_16 2]: https://img-blog.csdnimg.cn/73f69e6497d144608bf4b56a03f081f0.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBAd2VpeGluXzM4NjEyNDAx,size_20,color_FFFFFF,t_70,g_se,x_16