memory-leaks - 为什么 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 堆转储中看到了这些条目。

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

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

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

Answer 1

这是故意的。

内存使用似乎增加的观察
是由于从 native 实现转向纯基于 Java 的实现[1]
用于 JDK 9 中的 zip/jar 文件。主要是出于稳定性目的。

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

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

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