1 MB或更大的Java字节数组占用RAM的两倍


14

在Windows 10 / OpenJDK 11.0.4_x64上运行下面的代码会作为输出used: 197和输出expected usage: 200。这意味着200个字节数组(一百万个元素)占用了大约。200MB RAM。一切都很好。

当我将代码中的字节数组分配从new byte[1000000]更改为new byte[1048576](即更改为1024 * 1024个元素)时,它会作为输出used: 417和产生expected usage: 200。有没有搞错?

import java.io.IOException;
import java.util.ArrayList;

public class Mem {
    private static Runtime rt = Runtime.getRuntime();
    private static long free() { return rt.maxMemory() - rt.totalMemory() + rt.freeMemory(); }
    public static void main(String[] args) throws InterruptedException, IOException {
        int blocks = 200;
        long initiallyFree = free();
        System.out.println("initially free: " + initiallyFree / 1000000);
        ArrayList<byte[]> data = new ArrayList<>();
        for (int n = 0; n < blocks; n++) { data.add(new byte[1000000]); }
        System.gc();
        Thread.sleep(2000);
        long remainingFree = free();
        System.out.println("remaining free: " + remainingFree / 1000000);
        System.out.println("used: " + (initiallyFree - remainingFree) / 1000000);
        System.out.println("expected usage: " + blocks);
        System.in.read();
    }
}

通过visualvm进行更深入的研究,在第一种情况下,我看到了预期的一切:

字节数组占用200mb

在第二种情况下,除了字节数组之外,我看到与字节数组占用相同数量的int数组的RAM数量相同:

整数数组占用额外的200mb

顺便说一下,这些int数组不显示它们被引用了,但是我不能垃圾回收它们...(字节数组在被引用的地方显示得很好。)

任何想法在这里发生了什么?


尝试将数据从ArrayList <byte []>更改为byte [blocks []],并在for循环中:data [i] = new byte [1000000]以消除对ArrayList内部的依赖
jalynn2

它可能与JVM在内部使用int[]来模拟较大的JVM 以byte[]获得更好的空间局部性有关吗?
Jacob G.19年

@雅各布 它肯定看起来是内部的,但指南中似乎没有任何指示。
卡亚曼

仅有两个观察结果:1.如果从1024 * 1024中减去16,这似乎可以正常工作。2. jdk8的行为似乎不同于此处可以观察到的行为。
第二天

@second是的,神奇的限制显然是数组是否占用1MB RAM。我假设如果只减去1,则为了提高运行时效率和/或将阵列的管理开销计数到1MB,将填充内存...有趣的是JDK8的行为有所不同!
乔治(Georg)

Answers:


9

这描述的是G1垃圾收集器的开箱即用的行为,通常默认情况下为1MB“区域”,并在Java 9中成为JVM默认状态。在启用其他GC的情况下运行会产生不同的数字。

任何大于区域大小一半的对象都被认为是“巨大的” ...对于略大于堆区域大小倍数的对象,此未使用的空间可能导致堆变得碎片化。

我跑了java -Xmx300M -XX:+PrintGCDetails出来,发现堆满了巨大的区域:

[0.202s][info   ][gc,heap        ] GC(51) Old regions: 1->1
[0.202s][info   ][gc,heap        ] GC(51) Archive regions: 2->2
[0.202s][info   ][gc,heap        ] GC(51) Humongous regions: 296->296
[0.202s][info   ][gc             ] GC(51) Pause Full (G1 Humongous Allocation) 297M->297M(300M) 1.935ms
[0.202s][info   ][gc,cpu         ] GC(51) User=0.01s Sys=0.00s Real=0.00s
...
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space

我们希望我们的1MiB byte[]“小于G1区域大小的一半”,因此添加可以-XX:G1HeapRegionSize=4M提供功能性的应用程序:

[0.161s][info   ][gc,heap        ] GC(19) Humongous regions: 0->0
[0.161s][info   ][gc,metaspace   ] GC(19) Metaspace: 320K->320K(1056768K)
[0.161s][info   ][gc             ] GC(19) Pause Full (System.gc()) 274M->204M(300M) 9.702ms
remaining free: 100
used: 209
expected usage: 200

G1的深入概述:https : //www.oracle.com/technical-resources/articles/java/g1gc.html

粉碎G1的详细信息:https : //docs.oracle.com/en/java/javase/13/gctuning/garbage-first-garbage-collector-tuning.html#GUID-2428DA90-B93D-48E6-B336-A849ADF1C552


对于串行GC和占用8MB的长数组,我也有同样的问题(对于大小1024-1024-2很好),更改G1HeapRegionSize对我而言没有任何作用
GotoFinal

我不清楚。您能用long []
drekbour

@GotoFinal,我没有发现上面没有解释的任何问题。我测试了long[1024*1024]使用G1的预期使用量为1600M 的代码,其变化范围为-XX:G1HeapRegionSize[使用的1M:1887,使用的2M:2097,使用的4M:3358,使用的8M:3358,使用的16M:3363,使用的32M:1682]。与-XX:+UseConcMarkSweepGC二手车:1687。与-XX:+UseZGC二手车:2105。与-XX:+UseSerialGC二手车:1698
drekbour

gist.github.com/c0a4d0c7cfb335ea9401848a6470e816只是这样的代码,没有更改任何GC选项,它将打印,used: 417 expected usage: 400但是如果我删除-2它,它将更改为used: 47050MB左右,而50 * 2个long肯定比50MB少得多
GotoFinal

1
一样。差异约为50MB,您有50个“巨大”的块。这是GC的详细信息:1024 * [0.297s][info ][gc,heap ] GC(18) Humongous regions: 450->4501024- > 1024 * 1024-2-> [0.292s][info ][gc,heap ] GC(20) Humongous regions: 400->400这证明了最后两个long迫使G1分配了另一个1MB区域,仅用于存储16个字节
。– drekbour
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.