为什么 Java11 将 java.util.zip.ZipFile$Source 保留在堆上？

Question

有人可以帮助我了解我在 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:

的保留集

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

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

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

那么这是错误还是功能？

Answer 1

这是故意的。

内存使用似乎增加的观察是由于从本机迁移到纯 java-based 实现 [1] 对于 JDK 中的 zip/jar 个文件 9. 主要是为了稳定性目的。

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

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

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

为什么 Java11 将 java.util.zip.ZipFile$Source 保留在堆上？

Why is Java11 keeping java.util.zip.ZipFile$Source on heap?

memory-leaks

heap-dump

java-memory-leaks

java-11

openjdk-11