首页 > 其他分享 >JVM之指针压缩

JVM之指针压缩

时间：2023-06-28 18:22:08浏览次数：38  
标签：字节 对象 32 压缩 XX JVM 指针

做java开发的同学一般都比较熟悉JVM，那么关于指针压缩这块内容是不是也了解呢，不熟悉的小伙伴往下看吧。

首先说明，本文涉及的JDK版本是1.8，JVM虚拟机是64位的HotSpot实现为准。

java对象结构

了解指针压缩前，需要先搞懂java的实例对象在JVM虚拟机中内存结构是什么样的。
java对象由三部分构成：

  1. 对象头

对象头里也有三部分构成。

  • Markword

存储对象的hashCode、垃圾回收对象的年龄以及锁信息等。

  • 类型指针

对象指向的类信息地址即元数据指针，比如User对象指针指向User.class的JVM内存地址。注意：jdk1.8以后元数据是存在Metaspace里的，jdk1.8之前是在方法区里

  • 数组长度

只有对象是数组的情况下，才有这部分数据，若对象不是数组，则没有这部分，不分配空间。

  1. 对象体

对象里的非静态属性占用的空间（包括父类的所有属性，不区分修饰类型），不包括方法，注意：是非静态属性，属于对象的属性，静态属性是属于类的不在对象上分配空间。如果属性是基本数据类型，则直接存对象本身，如果是引用类型，则存的是对象的指针。

  1. 对齐填充

如果对象头+对象体大小不是8字节的倍数，则通过该部分进行补齐，比如对象头+对象体大小只有30字节，则需要补齐到32字节，这里的对齐填充就是2字节。默认情况下，JVM中对象是以8字节对齐的，若对象头加上对象体是8的倍数时，则不存在字节对齐，否则会填充补齐到8的倍数。
对象结构如下图所示（默认情况下）。
image.png

压缩指针的由来

计算机操作系统分32位和64位，这里的位在计算机里是用0和1来表示的，用32个（或64个）二进制0和1的组合来表示内存地址。以32位为例，在普通的内存中，对象的大小最小是以1字节来计算的，通过0和1的排列组合，能够表示寻址的内存空间最大就是2^32个，换算成内存空间就是2 ^ 32 / 1024 / 1024 / 1024 = 4G，也就是说32位的操作系统最大能寻址的内存空间只有4G，同理，64位的操作系统（查阅资料显示其实没有用到64位，最多只用到了48位，这个可自行查阅资料，反正肯定比32位大的多）2 ^ 48 / 1024 / 1024 / 1024 / 1024 = 256TB，这样内存就足够大了，但是目前还没有厂商能生产出这么大的内存。
4G对于现在的java应用系统来说，内存已经算小的了，那我们就会想到使用64位的系统，这样内存就可以更大了，但是当我们准备将32位系统切换到64位系统，起初我们可能会期望系统性能会立马得到提升，但现实情况可能并不是这样的，为什么呢？
（1）32位系统对象指针是4字节，64位系统对象指针是8字节（1位表示1bit，8个bit表示1字节），这样64位系统中的对象引用占用的内存空间是32位系统中的两倍大小，因此间接的导致了在64位系统中更多的内存消耗以及更频繁的GC发生，GC占用的CPU时间越多，那么我们的应用程序占用CPU的时间就越少，响应会变慢，吞吐量会降低。
（2）对象的引用变大了，那么CPU可缓存的对象相对就少了，降低了CPU缓存命中率，增加了对内存的访问，CPU对CPU缓存的访问速度可比对内存的访问速度快太多了，所以大量的对内存访问，会降低CPU的执行效率，增加了执行时间，从而影响性能。
既然32位系统内存不够，64位内存够但又影响性能，那有没有折中方案来解决这两个问题呢，于是聪明的JVM开发者想到了利用压缩指针，在64位的操作系统中利用32位的对象指针引用获得超过4G的内存寻址空间。

如何压缩指针

由于在JVM里，对象都是以8字节对齐的即对象的大小都是8的倍数，所以不管用32位还是64位的二进制表示，末尾3位始终都是0。既然JVM已经知道了这些对象的内存地址后三位始终是0，那么这些无意义的0就没必要在堆中继续存储。相反，我们可以利用存储0的这3位bit存储一些有意义的信息，这样我们就多出3位bit的寻址空间，也就是说如果我们继续使用32位来存储指针，只不过后三位原本用来存储0的bit现在被我们用来存放有意义的地址空间信息，当寻址的时候，JVM将这32位的对象引用左移3位即可（后三位补0）。我们原本32位的内存寻址空间一下变成了35位，可寻址的内存空间变为2 ^ 35 / 1024 / 1024 / 1024 = 32G，也就是说在64位系统JVM的内存可扩大到32G了，基本上可满足大部分应用的使用了。
所以在64位系统下，通过压缩指针我们可以继续使用32位来处理（引用指针由8字节可降低到4字节），存储的时候右移3位，寻址的时候左移3位，如下图所示。

image.png
这样一来，JVM虽然额外的执行了一些位运算但是极大的提高了寻址空间，并且将对象引用占用内存大小降低了一半，节省了大量空间，况且这些位运算对于CPU来说是非常容易且轻量的操作，可谓是一举两得。

如何进一步扩大寻址空间

前边提到我们在Java虚拟机堆中对象起始地址均需要对其至8的倍数，不过这个数值我们可以通过JVM参数-XX:ObjectAlignmentInBytes 来改变（默认值为8）。当然这个数值的必须是2的次幂，数值范围需要在8 - 256之间。
正是因为对象地址对齐至8的倍数，才会多出3位bit让我们存储额外的地址信息，进而将4G的寻址空间提升至32G。
同样的道理，如果我们将ObjectAlignmentInBytes的数值设置为16呢？
对象地址均对齐至16的倍数，那么就会多出4位bit让我们存储额外的地址信息。寻址空间变为2 ^ 36 / 1024 / 1024 / 1024 = 64G。
通过以上规律，我们就能知道，在64位系统中开启压缩指针的情况，寻址范围的计算公式：4G * ObjectAlignmentInBytes = 寻址范围。
但是并不建议大家贸然这样做，因为增大了ObjectAlignmentInBytes虽然能扩大寻址范围，但是这同时也可能增加了对象之间的字节填充，导致压缩指针没有达到原本节省空间的效果。

JVM压缩指针参数

可以通过以下命令查看java命令默认的启动参数：

java -XX:+PrintCommandLineFlags -version

image.png
通过下面这个命令，可以看到所有JVM参数的默认值。

java -XX:+PrintFlagsFinal -version

关于压缩指针的两个参数：
UseCompressedClassPointers：压缩类指针
UseCompressedOops：压缩普通对象指针
Oops是Ordinary object pointers的缩写，这两个参数默认是开启的，即-XX:+UseCompressedClassPointers，-XX:+UseCompressedOops，也可手动设置，如下所示

-XX:+UseCompressedClassPointers //开启压缩类指针
-XX:-UseCompressedClassPointers //关闭压缩类指针
-XX:+UseCompressedOops  //开启压缩普通对象指针
-XX:-UseCompressedOops  //关闭压缩普通对象指针

32位HotSpot VM是不支持UseCompressedOops参数的，只有64位HotSpot VM才支持。
Oracle JDK从6 update 23开始在64位系统上会默认开启压缩指针。

实例

使用 JOL 工具分析 Java 对象

maven依赖

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

常用类及方法

查看对象内部信息： ClassLayout.parseInstance(obj).toPrintable()
查看对象外部信息：GraphLayout.parseInstance(obj).toPrintable()
查看对象占用空间总大小：GraphLayout.parseInstance(obj).totalSize()
查看类内部信息：ClassLayout.parseClass(Object.class).toPrintable()

JOL使用

public class ObjectLayOut1 {
    public static void main(String[] args) {
        Goods goods = new Goods();
        goods.setAge((short) 10);
        goods.setNo(123456);
        goods.setId(111L);
        goods.setGoodsName("方便面");
        goods.setFlag(true);
        goods.setB((byte)1);
        goods.setPrice(1.5d);
        goods.setProduceTime(LocalDateTime.now());
        goods.setType('A');
        goods.setWeight(0.065f);
        System.out.println(ClassLayout.parseInstance(goods).toPrintable());
    }

}

@Setter
class Goods {
    private byte b;
    private char type;
    private short age;
    private int no;
    private float weight;
    private double price;
    private long id;
    private boolean flag;
    private String goodsName;
    private LocalDateTime produceTime;
}

输出：

com.star95.study.jvm.Goods object internals:
OFF  SZ                      TYPE DESCRIPTION               VALUE
  0   8                           (object header: mark)     0x0000000000000001 (non-biasable; age: 0)
  8   4                           (object header: class)    0xf800c143
 12   4                       int Goods.no                  123456
 16   8                    double Goods.price               1.5
 24   8                      long Goods.id                  111
 32   4                     float Goods.weight              0.065
 36   2                      char Goods.type                A
 38   2                     short Goods.age                 10
 40   1                      byte Goods.b                   1
 41   1                   boolean Goods.flag                true
 42   2                           (alignment/padding gap)   
 44   4          java.lang.String Goods.goodsName           (object)
 48   4   java.time.LocalDateTime Goods.produceTime         (object)
 52   4                           (object alignment gap)    
Instance size: 56 bytes
Space losses: 2 bytes internal + 4 bytes external = 6 bytes total

OFF：表示偏移量
SZ：占用字节大小
TYPE DESCRIPTION：类型描述
VALUE：取值，基本类型存的就是实际值，引用类型存的是指针

压缩指针参数组合

以以上代码配合以下jvm参数设置，看压缩的不同结果

一、-XX:+UseCompressedOops -XX:+UseCompressedClassPointers

类指针压缩和普通对象压缩都开启，这个也是jdk1.8默认的，不加这两个参数，压缩也是生效的。
image.png
输出：
image.png
这里类指针和引用类型的属性都压缩到以4字节保存了，对象占用56个字节，对象大小计算公式：

对象大小=对象头+实例数据+（填充数据）

二、-XX:+UseCompressedOops -XX:-UseCompressedClassPointers

开启普通对象压缩，关闭类指针压缩。
输出：
image.png
类指针占8个字节，普通对象指针是4个字节，对象占用56个字节，这里我们也可以看到保存到的顺序改变了，这就是重排序，JVM会根据类型及对齐字节大小合理优化。

三、-XX:-UseCompressedOops -XX:-UseCompressedClassPointers

类指针和普通对象指针压缩都关闭。
输出：
image.png
类指针和普通对象指针都占8字节，压缩均关闭的情况下，我们看到对象大小变成了64字节。

四、-XX:-UseCompressedOops -XX:+UseCompressedClassPointers

关闭普通对象压缩，开启类指针压缩。
输出：
image.png
我们看到，类指针占8字节，对象指针占8字节，底部还有一个警告，意思是说类指针压缩依赖普通对象压缩，这种相当于关闭了类指针压缩和普通对象压缩。

  • 开启 UseCompressedOops 时,UseCompressedClassPointers 会默认自动开启，可手工设置UseCompressedClassPointers的开启或关闭。
  • 关闭 UseCompressedOops 时,UseCompressedClassPointers 也会默认自动关闭，无法设置UseCompressedClassPointers，设置了也不会生效。

内存大小对压缩的影响

结合以上代码例子，我们通过设置jvm堆内存大小，看看是否影响类指针压缩和普通对象压缩。
设置jvm参数：

-Xmx31g -Xms31g -XX:+UseCompressedOops -XX:+UseCompressedClassPointers

image.png
image.png
类指针和对象指针都被压缩到4字节了。
接着我们把堆内存加到32g试试。

-Xmx32g -Xms32g -XX:+UseCompressedOops -XX:+UseCompressedClassPointers

image.png
堆内存加到32g，虽然类指针压缩和对象压缩都开启了，但是输出的还是各占8字节，说明压缩失效了，而且最后JVM还会发出警告，意思是64位的虚拟机，对开启压缩来说堆内存太大了。
为什么呢？
我们来算一下，既然指针压缩到了4byte，也就是32bit，同样按照之前算的，用排列组合的方式可以识别2^32个对象，也就是4G个对象，刚才同样也说了，在Java中，非简单对象都是必须以8byte对齐。
因此，其能够识别的最大内存就是4G*8byte=32GB，所以内存过大，压缩自动失效了。
这也是为什么很多Java服务在运行中，官方都建议单个运行实例的内存设置不要超过32GB的根本原因。典型的如Elasticsearch，很多资料都说设置JVM大小不要超过32G，但是很少有提到为什么。

总结

  • 通过指针压缩，利用对齐填充特性，通过映射方式达到了内存地址扩展的效果
  • 指针压缩能够节省内存空间，同时提高了程序的寻址效率
  • 堆内存设置最好不要超过32GB，这时指针压缩将会失效，造成空间的浪费
  • 指针压缩不仅可以作用于对象头的类型指针，还可以作用于引用类型的字段指针（包括引用类型的数组指针）
  • -XX:ObjectAlignmentInBytes，默认是 8，也就是 8 字节对齐

标签：字节,对象,32,压缩,XX,JVM,指针
From： https://www.cnblogs.com/star95/p/17512212.html

相关文章

  • CUDA学习详细教程之指针篇
    近期，我在写深度学习相关的C++部署时候，往往想更好的提速，将更多类似矩阵相关的运算交给CUDA处理，以此提高推理速度。然，cuda编程入门较为复杂，想简单对图像预处理，通过指针指向减少host到device时间，或模型预测后device上处理完后，数据在device到host输出结果等，这些将会涉及很多知识。......
  • 【JVM 方法区 04】
    从线程共享与否的角度划分“运行时数据区结构图”  线程共享区包括：堆、方法区（元空间）他两都会报OOM，现成私有化包括：虚拟机栈、本地方法栈、程序计数器（其中虚拟机栈和本地方法栈会抛StackOverflowError异常，程序计数器不会抛异常），还有一部分叫ThreadLocal一、栈、堆、方法区的交......
  • python zipfile 打包压缩 层级过多的解决措施
    zipfile使用详细https://www.cnblogs.com/yyds/p/6427349.html解决方案https://blog.csdn.net/csrh131/article/details/107895772操作案例和总结https://blog.51cto.com/u_16055028/6475844https://mp.weixin.qq.com/s/2RDCnQLORmn8kMHJsOhenA......
  • 【Python&RS】基于GDAL的遥感影像压缩
    ​        最近在处理一些高空间分辨率的卫星数据，数据量非常大。一个图幅都几十个G，ENVI表示压力太大了根本跑不动。所以研究了一下影像压缩的方式，在ArcGIS导出的压缩方式有很多限制，而且压缩并不是很明显。        所以我尝试使用GDAL库对影像进行压缩，速度还可......
  • 关于指针
    学习参考文章链接http://t.csdn.cn/HhSR5前面几篇多次看到把地址作为scanf()的输入参数的用法。例如，函数调用scanf("%d",&n)，把输入的值存储到变量n所在的内存单元里。其中&n表示变量n的内存地址或存储位置。这里&称为地址运算符，&是一元运算符，与其他一元运算符有同样的优先级。......
  • redis压缩列表ziplist
     压缩列表（ziplist）是Redis的一种内存紧凑型的数据结构，它是一个字节数组，可以包含任意多个元素，每个元素可以是一个字节数组或一个整数。压缩列表的结构由多个字段组成，包括zlbytes（压缩列表的字节长度），zltail（压缩列表尾元素的偏移量），zllen（压缩列表的元素数目），entryX（压缩列表存储的......
  • jvm-第四节垃圾回收器的细节实现
    垃圾回收器串讲及HostSpot的细节实现本篇知识点概况并发标记与三色标记gc并发下漏标问题与不同垃圾回收期下的处理方案（G1,Cms对比）跨代引用安全点与安全区域gc参数（了解）其他的垃圾回收期（了解）并发标记与三色标记三色标记诞生的历史：在三色标记之前有一个标记清除算法，根据可达性，可达设......
  • jvm-第四节垃圾回收器的细节实现
    #垃圾回收器串讲及HostSpot的细节实现本篇知识点概况并发标记与三色标记gc并发下漏标问题与不同垃圾回收期下的处理方案（G1,Cms对比）跨代引用安全点与安全区域gc参数（了解）其他的垃圾回收期（了解）并发标记与三色标记三色标记诞生的历史：在三色标记之前有一个标记清除算法......
  • JVM中的-Xms 、-Xmx 参数该如何设置
    在Java虚拟机（JVM）中，-Xms和-Xmx都是用来设置JVM堆内存大小的参数。其中，-Xms用于设置JVM启动时分配的初始堆内存大小，而-Xmx用于设置JVM堆内存的最大可用空间。默认情况下，-Xms参数的值为物理内存的1/64，-Xmx参数的值为物理内存的1/4。在设置这两个参数时，需要根据具体应......
  • go：数组和切片、可变长参数、maps、字符串、指针、结构体、方法、接口
    目录数组和切片数组切片可变长参数maps字符串指针结构体方法接口数组和切片数组#1定义，初始化，使用#2数组是值类型数字，字符串，布尔，数组，都是值类型，真正直接存数据切片，map，指针引用类型，是个地址，指向了具体的值#3数组长度#4循环打印数组#5多纬数组#......

赞助商

阅读排行

网站主页关于我们联系我们网站地图

本网站内容转载自其他媒体，侵权联系[admin##ips99.com]。

Copyright © 2020-2023 IPS99 版权所有 IPS99