4

有人可以帮助我了解我看到的是故意的、正确的行为还是 Java11 中的某种泄漏？让我们看一个简单的 hello world 应用程序：

package com.example;

public class HelloWorld {
    public static void main(String[] args) throws InterruptedException {
        for( int i =0 ; i < 50; i++){
            Thread.sleep(1000);
            System.out.println("hello " + i);
        }
    }
}

唯一有趣的部分是 jar 依赖项。它可以是任何 jar，但为了使问题更加突出，让我们使用一个大的旧 gwt-user jar，它重 30MB：

plugins {
    id 'java'
}

group 'com.example'
version '1.0-SNAPSHOT'

repositories {
    mavenCentral()
}

dependencies {
    // https://mvnrepository.com/artifact/com.google.gwt/gwt-user
    compile group: 'com.google.gwt', name: 'gwt-user', version: '2.7.0'
}

运行应用程序，打开 jvisualvm，进行转储并查找保留的一组java.util.zip.ZipFile$Source：

jvisualvm堆转储

来自类路径的那个 jar（实际上从未使用过）占用了 1.5MB 的堆。它不会在 GC 期间消失，当你内存不足时它也不会消失，我什至在 OutOfMemory heapdumps 中看到了这些条目。

该条目显然由 map 保存java.util.zip.ZipFile$Source.files。从源头上我可以看出，理论上这应该由来自 InnocuousThreadGroup 的 Common-Cleaner 线程进行清理，但我没有看到它发生。

我在将小型轻量级 Java 应用程序从 JDK8 迁移到 JDK11 时遇到了这个问题。与 JDK8 相比，在 Xmx 设置较低的情况下，这些 jar 占用了我堆的很大一部分。

那么它是一个错误还是一个功能？

4

1 回答 1

4

这是故意的。

内存使用似乎增加的观察结果是由于 JDK 9 中的 zip/jar 文件从本机实现 [1] 迁移到纯基于 Java 的实现。主要是出于稳定性目的。

我会注意到本机实现分配了相似且大小相似的数据结构，但它们被隐藏在检查 Java 堆的工具之外。

但是，即使总内存占用量应该或多或少是中性的，也可能需要增加 Java 堆大小以包含增加的 Java 堆使用量。

[1] https://bugs.openjdk.java.net/browse/JDK-8145260

于 2020-03-27T11:25:31.083 回答