这个问题在这里已有答案:
我有一个简单的演示来检查JVM内存分配和释放的细节。
Java版本
$ java -version
java version "1.8.0_201"
Java(TM) SE Runtime Environment (build 1.8.0_201-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode)
演示
/**
* VM Options: -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8
*/
public class DefaultCollector {
private static final int _1MB = 1024 * 1024;
public static void main(String... args) {
byte[] arr1 = new byte[2 * _1MB];
byte[] arr2 = new byte[2 * _1MB];
byte[] arr3 = new byte[2 * _1MB];
byte[] arr4 = new byte[4 * _1MB];
}
}
我手动使用CLI编译并运行程序
$ javac DefaultCollector.java
$ java -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8 DefaultCollector
GC日志
Heap
PSYoungGen total 9216K, used 6979K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
eden space 8192K, 85% used [0x00000000ff600000,0x00000000ffcd0f68,0x00000000ffe00000)
from space 1024K, 0% used [0x00000000fff00000,0x00000000fff00000,0x0000000100000000)
to space 1024K, 0% used [0x00000000ffe00000,0x00000000ffe00000,0x00000000fff00000)
ParOldGen total 10240K, used 4096K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
object space 10240K, 40% used [0x00000000fec00000,0x00000000ff000010,0x00000000ff600000)
Metaspace used 2468K, capacity 4486K, committed 4864K, reserved 1056768K
class space used 265K, capacity 386K, committed 512K, reserved 1048576K
-Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8
已经设置和eden: 8M, from: 1M, and to: 1M
清楚地呈现,为什么PSYoungGen total 9216K
而不是10240K
?Metaspace
记得Metaspace used 2468K
这么多记忆?究竟是什么?是否只有类型信息?至于第一个问题,@ Holger提供了非常直接的实验来展示fact。
报告的年轻一代的总大小总是包括伊甸园和仅来自太空,忽略总是空的
to
空间,这与大小背后报告的地址不一致,其中包括覆盖所有三个空间的完整跨度。
然后谈到第二个
为什么Metaspace占用了如此多的内存Metaspace使用了2468K?究竟是什么?是否只有类型信息?
我发现它在Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning Guide中的规格为
在以Metaspace开头的行中,使用的值是用于加载类的空间量...以类空间行开头的行包含压缩类指针的元数据的相应值。