前言
在进行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套哦~
