黑马JVM总结（十五）

（1）GC_相关参数

（2）GC_分析1

下面通过一个案例去读懂垃圾回收的一个过程，学会读懂垃圾回收的日志

-XX：UseSerialGC：是一个垃圾回收器，jdk8下默认的垃圾回收器不是它，改为UseSerialGC它的幸存区的比例才不会调整

设置虚拟机参数：

 没有任何代码是堆的占用情况：

没有任何对象，20兆空间是足够用的，没有打印任何的GC信息，只打印了程序结束后堆的运行情况：

新生代：总共9兆多，因为8兆划分非伊甸园，1兆幸存区From，1兆幸存区To ，幸存区To始终空着，所以计算空间时去掉了总共9兆多

total总共大小  used使用大小 后面是内存地址 

伊甸园Eden space 为啥会有东西呢因为再简单的java应用程序运行时需要加载一些类，创建一些对象，这些对象也是使用伊甸园的区域

 

老年代：

元空间，他并不是堆的一部分 

（3）GC_分析2

放一个7兆，伊甸园已经占用28%，在放8兆放不下，会进行一次垃圾回收 

 

 GC代表Minor GC  DefNew代表新生代  1984k回收前内存占用667k回收后的内存占用（9216k区域总大小）后面是回收时间  ] 后面是堆的回收前回收后以及堆总大小和时间 

可以看到回收后伊甸园 From To发生了一些变化，一些对象放到了TO中，放入To以后form跟To交换了，显示From的占用情况

伊甸园呢有90%都被占用了，7兆的对象进入了伊甸园的区域，其他部分没变

再放一个512k的：7兆+512k可以放的下，只会触发第一次的垃圾回收，伊甸园几乎呗放满了已经到了98%的占用

再放512K就放不下了触发第二次垃圾回收：新生代已经容纳不了那么多对象了，很多对象晋升到了老年代，没有等到阈值15次，直接晋升到老年代

（4）GC_分析_大对象_oom

我们研究一下之前没有提过的大对象直接晋升到老年代

我们存放一个8兆的byte数组，它超过了伊甸园的总容量，包括from也放不下，新生代计算了一遍发现这个对象新生代容不下它，无论再怎么回收，也放不下这个8兆的对象，那么会有这么一种策略，当老年代空间多直接把这个对象放到老年代中去，这种情况下不会触发垃圾回收

 我们发现伊甸园还是28%最初是状态，老年代直接到了80%，并没有触发垃圾回收现象

存放2个Byte数组的8兆对象：新生代和老年代都容不下这个对象，这两个数组都由一个GC Root根对象所引用不能释放，那么会报内存溢出 

内存溢出前会做一个自救工作触发新生代和老年代的垃圾回收，做完发现还是不够会抛出一个异常

当这个内存溢出发生在一个线程里面，发生内存溢出，那么他会不会导致主线程受到影响呢？

主线程此时还没有结束 

主线程等待时间结束后，有正确的结束符号，主线程没有受到影响，一个线程内的内存溢出，并不会导致java进程的结束