为什么 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。从源头我可以看出，理论上这应该由来自 InnocouslyThreadGroup 的 Common-Cleaner 线程来清理，但我没有看到它发生。

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

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

Answer 1

这是故意的。

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

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

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

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