用如下JVM参数运行代码:
# 初始新生代大小 5M
-XX:NewSize=5242880
# 最大新生代大小 5M
-XX:MaxNewSize=5242880
# 初始堆大小 10M
-XX:InitialHeapSize=10485760
# 最大堆大小 10M
-XX:MaxHeapSize=10485760
-XX:SurvivorRatio=8
# 大对象阈值是10MB
-XX:PretenureSizeThreshold=10485760
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
GC日志打印选型:
-XX:+PrintGCDetils:打印详细gc日志
-XX:+PrintGCTimeStamps:这个参数可以打印出来每次GC发生的时间
-Xloggc:gc.log:这个参数可以设置将gc日志写入一个磁盘文件
加上该参数后,JVM参数如下:
-XX:NewSize=5242880
-XX:MaxNewSize=5242880
-XX:InitialHeapSize=10485760
-XX:MaxHeapSize=10485760
-XX:SurvivorRatio=8
-XX:PretenureSizeThreshold=10485760
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-Xloggc:gc.log
byte[] array1 = new byte[1024 * 1024];
该行会在JVM Eden内放入一个1M数组,同时在main线程的虚拟机栈压入一个main方法栈帧,其栈帧内部有一“arr1”变量,该变量指向Eden的那1M数组:
arr1 = new byte[1024 * 1024];
此时会在Eden创建第二个数组,局部变量指向其。然后第一个数组无人引用,成了垃圾:
byte[] array1 = new byte[1024 * 1024];
在Eden创建第三个数组,同时让arr1指向第三个数组,此时前两个数组都无人引用,都成了垃圾:
arr1 = null;
arr1啥都不指了,导致之前创建的3数组全部变成垃圾:
byte[] arr2 = new byte[2 * 1024 * 1024];
分配一个2MB大小的数组,尝试放入Eden,这时Eden放的下吗?
显然不行,Eden共4M,已放入3个1M数组,只剩1M,所以这时就会触发Y-GC。
然后运行即可,运行完后,会出现gc.log文件,即本次程序运行的gc日志:
打开gc.log文件,我们会看到如下所示的gc日志:
这次运行程序的JVM参数,包含:
给JVM加个打印gc日志的参数,就可以在此看到JVM默认参数配置
0.410: [GC (Allocation Failure) 0.410: [ParNew: 3863K->465K(4608K), 0.0025689 secs] 3863K->1491K(9728K), 0.0029347 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
0.269: [ParNew: 4030K->512K(4608K), 0.0015734 secs] 4030K->574K(9728K), 0.0017518 secs]
[Times: user=0.00 sys=0.00, real=0.00 secs]
概要说明本次GC执行情况:
因为要分配一个2M数组,但Eden内存不足,所以“Allocation Failure”,内存分配失败,所以就要触发一次Y-GC。
看一个数字,“0.410”:你的系统运行后,过了多少s发生的本次GC,此处就是系统运行后的410ms发生了GC。
此处触发的是Y-GC,所以用的也就是指定的ParNew来执行GC。
新生代可用空间4608KB,约4.5MB,Eden是4M,两个Survivor只有一个可放存活对象,另外一个必须保持空闲,所以年轻代可用空间是 Eden+1个Survivor=4.5MB。
3863K->465K:对年轻代执行一次GC,GC前使用了3863K,但GC后只有465K对象存活。
GC前,我们在Eden只放了3个1M数组,共3MB,即3072K,那为啥这里显示使用了3863K?
所以GC前,三个数组+其他未知对象=3863K内存。GC前,我们在Eden只放了3个1M数组,共3MB,即3072K,那为啥这里显示使用了3863K?
所以GC前,三个数组+其他未知对象=3863K内存。
0.0025689 secs:本次GC耗费时间,看这里来说大概耗费2.5ms,仅回收3MB对象而已。
整个Java堆内存的情况。整个Java堆内存总可用空间9728K(9.5M)=年轻代4.5MB+老年代5M。
[Times: user=0.01 sys=0.00, real=0.01 secs]
本次gc消耗的时间,这里最小单位是小数点之后两位,单位是s。
ParNew执行GC,回收掉自定义创建的三个数组,此时因为他们都无人引用,必成垃圾:
ParNew: 4030K->512K(4608K), 0.0015734 secs
gc回收后,从4030K内存使用降低到512K内存使用。即这次gc日志有512KB的对象存活,从Eden区转移到Survivor1区:
Heap
par new generation total 4608K, used 2601K [0x00000000ff600000, 0x00000000ffb00000, 0x00000000ffb00000) eden space 4096K, 51% used [0x00000000ff600000, 0x00000000ff80a558, 0x00000000ffa00000)
from space 512K, 100% used [0x00000000ffa80000, 0x00000000ffb00000, 0x00000000ffb00000) to space 512K, 0% used [0x00000000ffa00000, 0x00000000ffa00000, 0x00000000ffa80000)
concurrent mark-sweep generation total 5120K, used 62K [0x00000000ffb00000, 0x0000000100000000, 0x0000000100000000)
Metaspace used 2782K, capacity 4486K, committed 4864K, reserved 1056768K class space used 300K, capacity 386K, committed 512K, reserved 1048576K
ParNew负责的新生代共4608K(4.5MB)可用内存,目前使用2630K(2.5MB)。此时在JVM退出前,为何新生代占了2.5M?GC后,通过如下代码又分配了个2M数组:
byte[] arr2 = new byte[2 * 1024 * 1024];
所以此时在Eden一定会有个 2M数组=2048K,然后上次GC后,在From Survivor存活了个512K未知对象,那么:
2048 K B + 512 K B = 2560 K B 2048KB + 512KB = 2560KB2048KB+512KB=2560KB
每个数组会额外占据一些内存存放一些自己这个对象的元数据,可认为多出来的70K是数组对象额外使用的内存空间。
Eden此时4M内存被用52%,就因为那2M数组。然后From Survivor区,512K是100%使用率,此时被之前GC后存活下来的512K未知对象占据。
Concurrent Mark-Sweep垃圾回收器,即CMS管理的老年代内存空间共5M,此时使用了62K。
Metaspace元数据空间和Class空间,存放一些类信息、常量池之类的东西,此时他们的总容量,使用内存等。
版权说明 : 本文为转载文章, 版权归原作者所有 版权申明
原文链接 : https://javaedge.blog.csdn.net/article/details/122701941
内容来源于网络,如有侵权,请联系作者删除!