maven pom.xml
<dependency>
<groupId>org.openjdk.jol</groupId>
<artifactId>jol-core</artifactId>
<version>0.10</version>
</dependency>
Java 类:
public class MyObjectData {
private int i=66;
private long l=6L;
private String string=new String("aaaa");
}
public class ObjectTest {
@Test
public void test1() {
Layouter l;
//64 bit vm object distribution, pointer compression not enabled
l = new HotSpotLayouter(new X86_64_DataModel());
System.out.println("***** " + l);
System.out.println(ClassLayout.parseInstance(new MyObjectData(),l).toPrintable());
System.out.println("==============================================");
}
}
运行结果:
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) 01 23 01 f8 (00000001 00100011 00000001 11111000) (-134143231)
12 4 (object header) 42 00 00 00 (01000010 00000000 00000000 00000000) (66)
16 8 long MyObjectData.l 6
24 4 int MyObjectData.i 66
28 4 (alignment/padding gap)
32 8 java.lang.String MyObjectData.string (object)
40 -8 (loss due to the next object alignment)
Instance size: 32 bytes
Space losses: 4 bytes internal + -8 bytes external = -4 bytes total`
不明白为什么64位VM在检查对象的内存使用情况时没有启动指针压缩,导致-8内存对齐。
最佳答案
I don't understand why the 64 bit VM did not start pointer compression when checking the memory usage of the object ...
JVM 不会动态启动指针压缩;例如“...在检查对象的内存使用情况时没有开始指针压缩...”
相反,它决定在(64 位)JVM 启动时是否使用压缩的 oop。它根据命令行选项来决定;即 UseCompressedOops
、ObjectAlignmentInBytes
和最大堆大小。最大堆大小由 -xmx
给定或由特定于平台的默认算法确定。
所以...您需要查看 JVM 的(实际和默认)JVM 选项,以找出压缩 oops(显然)无效的原因。使用 -XX:+PrintCommandLineFlags
来查找。
关于java - 64位VM不启动指针压缩,导致-8内存对齐,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/75963133/