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在检查对象的内存使用时没有启动指针压缩，导致内存对齐。
1条答案
按热度按时间soat7uwm1#
我不明白为什么64位VM在检查对象的内存使用情况时没有启动指针压缩...
JVM不会动态启动指针压缩;例如："...在检查对象的内存使用情况时没有启动指针压缩*****..."*
相反，它决定在（64位）JVM启动时是否使用压缩的oops。即
UseCompressedOops、ObjectAlignmentInBytes和最大堆大小。最大堆大小由-xmx给定或由特定于平台的默认算法确定。所以...您需要查看JVM的（实际和默认）JVM选项，以弄清楚为什么压缩的oops（显然）无效。使用
-XX:+PrintCommandLineFlags可以找到答案。