Java11がjava.util.zip.ZipFile $ Sourceをヒープ上に保持しているのはなぜですか？

debugcn 投稿 Dev

tporeba

誰かが私が見ているものがJava11の意図的で正しい動作なのか、それともある種のリークなのかを理解するのを手伝ってもらえますか？ばかげたシンプルなHelloWorldアプリを見てみましょう。

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の依存関係です。それはどんな瓶でもかまいませんが、問題をより壮観にするために、大きなものを使用しましょう-古い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ヒープダンプにも表示されます。

The entry is obviously kept by a map java.util.zip.ZipFile$Source.files. From the source I can tell that this theoretically should be cleaned by a Common-Cleaner thread from InnocuousThreadGroup, but I don't see it happening.

I encountered this problem when migrating a small, lightweight Java app from JDK8 to JDK11. With low Xmx settings those jars use up significant portion of my heap as compared to JDK8.

So is it a bug or a feature?

Claes Redestad

This is deliberate.

The observation that memory use seem to increase is caused by moving from a native to pure java-based implementation[1] for zip/jar files in JDK 9. Mainly for stability purposes.

I'll note that the native implementation allocates similar and similarly sized data structures, but they were hidden out of sight from tools inspecting the java heap.

ただし、合計メモリフットプリントは多かれ少なかれ中立である必要がありますが、Javaヒープの使用量の増加に対応するために、Javaヒープサイズを増やす必要がある場合があります。

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

この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。

侵害の場合は、連絡してください[email protected]

編集2021-06-12

コメントを追加

サインイン

分類Dev

Related 関連記事

記事

Java11がjava.util.zip.ZipFile $ Sourceをヒープ上に保持しているのはなぜですか？

Java11がjava.util.zip.ZipFile $ Sourceをヒープ上に保持しているのはなぜですか？

java.util.zip-ZipInputStreamとZipFile

java.util.zip.ZipFile.close（）がIOExceptionをスローするのはいつですか？

zipfileがzipと同じ出力.zipファイルサイズを提供しないのはなぜですか？

Java util zipが「破損した」zipファイルを作成する

java.util.zipと構造を保持するZipディレクトリ

ZipInputStreamなしでZipOutputStreamにZipEntryを追加する場合のjava.util.zip.ZipException

java.util.zip.ZipExceptionを解決するには？

エラー：java.util.zip.ZipException：エントリが重複しています

Java.util.zipが新しいファイルを追加すると、jar全体が上書きされますか？

java.util.zipを使用して有効なepubを構築する

java.util.zip.CRC32でのCRC-32の実装

java.util.zip.ZipException：重複エントリ：克服する方法

java.util.zip.ZipException: エントリの重複エラー

Tomcatが原因：java.util.zip.ZipException：zipファイルを開く際のエラー

Android Studio java.util.zip.ZipException：重複したエントリ

zipfileはzipをフォルダに抽出します

java.util.zip-ディレクトリ構造の再作成

java.util.zip.ZipException：packageAllDebugClassesForMultiDex中の重複エントリ

java.util.zip.ZipExceptionの取得：重複エントリ例外

java.util.zip.Deflaterから生のデフレートを取得することは可能ですか？

java.util.zip.Deflaterから生のデフレートを取得することは可能ですか？

java.util.zip.ZipException：ZIPファイルのエントリが多すぎます

Java.Util.Stackがループの最後の要素をポップしないのはなぜですか？

ラムダ（java.util.stream.Streams.zip）でJDK8を使用してストリームを圧縮する

zipfileを使用して絶対パスにzipファイルを作成する方法

java.util.loggingを使用しないのはなぜですか？

Python zipfile dosen't release zip file

アンドロイド：ZIPファイル（）java.util.zip.ZipException：zipファイルであるには余りにも短いファイル：0

Mavenプロジェクトをデプロイすると、java.util.zip.ZipException：LOCヘッダーが無効になります（署名が不正）