（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进程的结束
