使用OpenJDK jol-core查看JVM对象内存时遇exit code 137问题求助

exit code 137搭配SIGKILL信号，通常意味着你的测试进程因内存占用超出系统/IDE限制，被操作系统强制终止。结合你手动实例化HotSpotLayouter并指定DataModel的代码来看，这个操作可能导致JOL内部初始化时出现资源异常占用，进而触发内存溢出或被系统查杀。

解决方案 #

1. 改用JOL自动适配当前JVM环境的方法

JOL提供了更简洁且安全的静态方法，无需手动实例化HotSpotLayouter，会自动适配当前运行的JVM参数（包括指针压缩状态）。修正后的代码如下：

public class MyObject {
}

public class ObjectTest {
    @Test
    public void test1() {
        // 输出当前JVM环境下的对象内存布局
        System.out.println(ClassLayout.parseInstance(new MyObject()).toPrintable());
    }
}

2. 测试不同指针压缩状态的正确方式

如果需要验证指针压缩开启/关闭的差异，不要手动指定DataModel，而是通过JVM启动参数切换状态，分别运行测试：

• 关闭指针压缩：添加JVM参数 -XX:-UseCompressedOops
• 开启指针压缩：添加JVM参数 -XX:+UseCompressedOops（默认开启，可省略）

3. 调整测试进程的内存限制

在IDE的测试配置中，增加JVM内存参数，比如设置 -Xmx512m，避免因内存不足被系统强制终止。

原因说明 #

手动实例化HotSpotLayouter并传入自定义DataModel，会绕过JOL对当前JVM环境的自动适配逻辑，可能导致内部结构初始化时占用异常多的内存，或者出现环境不兼容的问题，最终触发系统的SIGKILL信号终止进程。JOL的设计初衷就是自动适配当前JVM，因此优先使用静态解析方法更为稳妥。

内容的提问来源于stack exchange，提问作者ami who