อาร์เรย์ Java byte ขนาด 1 MB หรือมากกว่านั้นใช้ RAM เป็นสองเท่า

เล่นโค้ดด้านล่างบน Windows 10 / OpenJDK 11.0.4_x64 ผลิตเป็นผลผลิตและused: 197 expected usage: 200ซึ่งหมายความว่าอาร์เรย์ 200 ไบต์ของหนึ่งล้านองค์ประกอบใช้เวลาประมาณ RAM 200MB ทุกอย่างดี

เมื่อฉันเปลี่ยนการจัดสรรอาร์เรย์ไบต์ในรหัสจาก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 ฉันเห็นในกรณีแรกทุกอย่างตามที่คาดไว้:

ในกรณีที่สองนอกเหนือจากอาร์เรย์ไบต์ฉันเห็นจำนวน int อาร์เรย์เดียวกันที่ใช้ RAM ในปริมาณเท่ากันกับอาร์เรย์ไบต์:

โดยวิธีอาร์เรย์เหล่านี้ไม่ได้แสดงว่าพวกเขามีการอ้างอิง แต่ฉันไม่สามารถเก็บรวบรวมขยะพวกเขา ... (อาร์เรย์ไบต์แสดงเพียงแค่ปรับที่พวกเขามีการอ้างอิง)

ความคิดใด ๆ ที่เกิดขึ้นที่นี่

สิ่งนี้อธิบายได้ว่าเป็นพฤติกรรมนอกกล่องเก็บขยะ G1ซึ่งโดยปกติแล้วจะเริ่มต้นที่ "ภูมิภาค" 1MB และกลายเป็นค่าเริ่มต้น JVM ใน Java 9 การเปิดใช้งานด้วย GCs อื่นเปิดใช้งานให้ตัวเลขที่แตกต่างกัน

วัตถุใด ๆ ที่มีขนาดพื้นที่เกินกว่าครึ่งถือว่าเป็น "humongous" ... สำหรับวัตถุที่มีขนาดใหญ่กว่าขนาดพื้นที่ฮีปหลายเท่าเล็กน้อยพื้นที่ที่ไม่ได้ใช้นี้อาจทำให้ฮีปนั้นแตกเป็นชิ้น ๆ

ฉันวิ่ง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