JVM学习笔记-GC日志分析（对象优先在Eden区分配）

56 阅读 0 评论 37 点赞

我是靠谱客的博主傻傻万宝路，最近开发中收集的这篇文章主要介绍JVM学习笔记-GC日志分析（对象优先在Eden区分配），觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

前言

在进行GC日志分析前，先了解一下JVM虚拟机运行时数据区的主要划分：

在这里插入图片描述

Java虚拟机在执行Java程序的过程中会把它所管理的内存划分为若干个不同的数据区域。这些区域有各自的用途，以及创建和销毁的时间，有的区域随着虚拟机进程的启动而一直存在，有些区域则是依赖用户线程的启动和结束而建立和销毁。根据《Java虚拟机规范》的规定，Java虚拟机所管理的内存将会包括以上几个运行时数据区域。

由于GC垃圾收集器主要回收的区域是堆区域，所以这里其他的概念用途我这里就不在讲解。

堆

堆是java虚拟机中比较占内存的一部分，也是GC垃圾收集器垃圾回收的重点部分。一个进程有一个java虚拟机实例，一个进程有多个线程，而java堆可被多个线程共享。在虚拟机启动创建时，这个区域的主要目的就是存放对象实例。在《Java虚拟机规范》中对Java堆的描述是：“所有的对象实例以及数组都应当在堆上分配”。

堆内存区域划分

当前主流的垃圾收集器都采用分代收集算法进行垃圾回收。根据对象的生命周期的不同将内存划分为几块，然后根据各块的特点采用最适当的收集算法。大批对象死去、少量对象存活的，使用复制算法，复制成本低；对象存活率高、没有额外空间进行分配担保的，采用标记-清除算法或者标记-整理算法。

在这里插入图片描述
如上图可知，堆空间(heap)主要可分为新生代（Young）和老年代（Old Space）区。新生代又可分为
Eden、From Survivor、To Survivor区。

堆的内存模型大致可分为：

在这里插入图片描述

先大概了解了java虚拟机的堆空间内存分布，接下来我们就可以去实操查看GC日志，
了解虚拟机的内存分配与回收策略。

对象优先在Eden分配

在大多数情况下，对象在新生代Eden区域内存，当Eden区域没有足够内存进行分配时，虚拟机讲进行一次Minor GC。

新生代收集（Minor GC/Young GC）：指目标只是新生代的垃圾收集。

代码分析
在代码的testAllocation()方法中，尝试分配三个2MB大小和一个4MB大小的对象

package com.jvm.slot;
/**
* @PackageName: com.jvm.slot
* @author: youjp
* @create: 2020-09-26 17:01
* @description: -XX:+UseSerialGC -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8
*
* -XX:+UseSerialGC 表示强制使用Serial+SerialOld收集器组合
* -Xms20m 表示堆空间初始大小为 20 M。
* -Xmx20m 表示堆空间最大大小为 20 M。
* -Xmn10m 表示新生代大小为 10M。
* -XX:SurvivorRatio=8 表示Eden:Survivor=8:1
*
* @Version: 1.0
*/
public class TestGC {
public static void main(String[] args) {
testAllocation();
}
public static void testAllocation(){
byte a1[],a2[],a3[],a4[];
a1=new byte[2 * 1024*1024]; //2M
a2=new byte[2 * 1024*1024];// 2M
a3=new byte[2 * 1024*1024];//2M
a4=new byte[4 * 1024*1024]; //4M出现一次Minor GC
}
}

IDEA虚拟机参数配置：

-XX:+UseSerialGC -Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8 -XX:+PrintGCDetails

在这里插入图片描述
在运行时通过-Xms20M、-Xmx20M、-Xmn10M这三个参数限制了Java堆大小为20MB，不可扩展，其中 10MB分配给新生代，剩下的10MB分配给老年代。
-XX:SurvivorRatio=8决定了新生代中Eden区与一个Survivor区的空间比例是8∶1。
-XX:+UseSerialGC指定使用Serial(年轻代）垃圾收集器。其他垃圾收集器可自我尝试。

配置完成后点击运行，查看控制台。

[GC (Allocation Failure) [DefNew: 6612K->1024K(9216K), 0.0075543 secs] 6612K->3201K(19456K), 0.0090275 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
[GC (Allocation Failure) [DefNew: 5275K->0K(9216K), 0.0067555 secs] 7453K->7231K(19456K), 0.0068390 secs] [Times: user=0.00 sys=0.02, real=0.01 secs]
Heap
def new generation
total 9216K, used 4178K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
eden space 8192K,
51% used [0x00000000fec00000, 0x00000000ff014930, 0x00000000ff400000)
from space 1024K,
0% used [0x00000000ff400000, 0x00000000ff400000, 0x00000000ff500000)
to
space 1024K,
0% used [0x00000000ff500000, 0x00000000ff500000, 0x00000000ff600000)
tenured generation
total 10240K, used 7231K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
the space 10240K,
70% used [0x00000000ff600000, 0x00000000ffd0feb8, 0x00000000ffd10000, 0x0000000100000000)
Metaspace
used 3523K, capacity 4496K, committed 4864K, reserved 1056768K
class space
used 382K, capacity 388K, committed 512K, reserved 1048576K
Process finished with exit code 0

从输出的结果也清晰地看到“eden space 8192K、from space 1024K、to space 1024K”的信息，新生代总可用空间为9216KB（Eden区+1个Survivor区的总容量）

执行testAllocation()中分配allocation4对象的语句时会发生一次Minor GC，这次回收的结果是新生代6612KB变为1024KB，而总内存占用量则几乎没有减少（因为allocation1、2、3三个对象都是存活的，虚拟机几乎没有找到可回收的对象）。

产生这次垃圾收集的原因是为allocation4分配内存时，发现 Eden已经被占用了6MB，剩余空间已不足以分配allocation4所需的4MB内存，因此发生MinorGC。垃圾收集期间虚拟机又发现已有的三个2MB大小的对象全部无法放入Survivor空间（Survivor空间只有 1MB大小），所以只好通过分配担保机制提前转移到老年代去。

这次收集结束后，4MB的allocation4对象顺利分配在Eden中。因此程序执行完的结果是Eden占用 4MB（被allocation4占用），Survivor空闲，老年代被占用6MB（被allocation1、2、3占用）。通过GC 日志可以证实这一点。
在这里插入图片描述
为了便于理解，我画了对象进入堆后内存分配流程图

在这里插入图片描述

参考博文：
https://www.cnblogs.com/baizhanshi/p/6140925.html?utm_source=itdadao&utm_medium=referral
https://blog.csdn.net/qq_32534441/article/details/86307997

有兴趣的老爷，可以关注我的公众号【一起收破烂】，回复【006】获取2021最新java面试资料以及简历模型120套哦~
在这里插入图片描述