我有一个简单的演示来检查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
?里面到底有什么?是否有仅类型信息?答案 0 :(得分:1)
对于第一个问题,@ Holger提供了非常直接的实验来证明fact。
为“年轻一代”报告的总大小始终仅包含eden,并且仅包含空间,忽略了始终为空的
to
空间,该空间与报告在大小后面的地址不一致,其中包括完整的跨度,涵盖了所有三个空间。
然后是第二个
为什么Metaspace占用大量内存Metaspace使用2468K?里面到底有什么?只有类型信息吗?
我在Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning Guide中找到了它的规范
在以Metaspace开头的行中,已用值是用于加载的类的空间量...以类空格行开头的行包含的元数据的相应值压缩的类指针。