jvm- 垃圾收集器

Serial 收集器：串行收集器(点线程)，stw ，如果当前用这个垃圾回收器，会把当前所有的应用线程，全部停止掉，只留一个垃圾回收的线程，GC结束后，会把所有停止的下线程全部激活。

新生代：复制算法，老年代：标记整理算法

ParNew收集器：

如果当前用这个垃圾回收器，会把当前所有的应用线程，全部停止掉，线程数和cpu的核数相同（垃圾回收的线程），GC结束后，会把所有停止的下线程全部激活。

新生代：复制算法，老年代：标记整理算法

parallel 收集器：可以设置线程停止时间

CMS收集器：以最短回收停顿时间为目标的收集器，

1：初次标记：暂停其它所有线程，病例路 gcroots 直接引用的对象，速度很快

2：并发标记：同时开启GC和用户线程，记录 gc root可达对象 。 这个阶段结束，闭包结构不能保证包含当前所有的可达对象，因为用户线程不断地更新对象，所以新的的对象产生，这个阶段可能就结束了，这样，新的对象没有标记在内。这个极端不会产生 STW

3：重新标记：这个阶段会停止用户线程，重新标记阶段是为了把 并发标记没有标记的对象，重新标记这个时间比初次标记要时间长，但是比并发标记时间段。

4：并发清理：开始用户线程，同时GC线程开始对未标记的区域做清扫

5：并发重置：

如果并发清理失败：会执行  serial 垃圾回收

 

 

G1收集器：和cms回收差不多

G1将java堆划分为多个大小相等的独立区域 （Region）,JVM最多可以有2048个 Region

1：一般Region的大小等于 堆大小除以2048，比如堆大小是4096M，则Region的大小为2m,当然也可以手动设置，但是推荐默认。

2：G1保留了年轻代和老年代的概念，中间没有隔阂，全部都是一个个的Region

默认年轻代对堆内存的占比是5%,如果堆大小是4096M，那么年轻代占据200MB左右的内存，对应大概是100个Region.(可以设置堆内存的占比，但是不会超过堆内存的60%)。

3：年轻代中的 eden区和Survivor对应的比例 默认是：8:1，假设年轻代有1000个region，eden区对应800，s0对应100，s1对应100.

4：一个Region之前是年轻代，进行了垃圾回收，可能会变成老年代，Region的功能可能会动态变化

5:垃圾收集器对于对象什么时候，会转移到老年代和之前的原则一样。不同的是对于大对象的处理，G1有专门分配大对象的Region叫做，Humongous区，而不是让大对象直接进入老年代的Region，在G1中，大对象的规定，如果大对象超过了一个Region的50%(如果一个Region是2M,只要一个对象超过了1M，就会直接放入Humongs中，如果一个对象是6M,会横跨多个Region来存放。)。Humongs区域是专门存放短期巨型的对象，不用直接进入老年代，，可以节约老年代的空间，避免因为老年代空间不够的GC开销。 

5：Yong GC 并不是，现在说的Eden区域放满，就会触发，G1会计算现在的Eden区回收的大概需要多少时间，如果回收的时间远远小于参数 设置回收时间，那么增加年轻代的region,继续给新的对象存放，不会马上做Yong GC,直到下一次Eden区放满，G1计算回收的时间，接近设定的回收时间，就会触发 Yong GC。

6：Mixed GC  不是FULL GC，老年代的堆占有率达到设置的45%.会触发，回收，所有的yong GC和和老年代，以及大对象区域，正常的G1的垃圾回收，是做Mined GC, 主要 使用复制算法，需要把各个region中存活的对象拷贝到别的region里去，拷贝过程如果发现没有足够的空 Region，能够承载拷贝的对象，就会触发 FULL GC.

7: FULL GC，停止系统线程，然后用单线程标记，清理和压缩和整理，好空闲出来一批新的region来提供下一次Mixed GC使用，这个过程非常消耗时间。

 

G1垃圾回收优化建议：

  假设参数设置的值很大，导致系统运行很久，年轻代可能都占用了堆内存的60%,此时才出发 年轻代的gc，那么存活的对象可能会很多，此时会导致Survivor区域放不下那摩多的对象，直接会进入老年代中

或者年轻代gc后，存活下来的对象很多，导致Suvivor区域触发动态年龄判断规则，达到了Survivor的50%,也会快速导致一些对象进入老年代里面去。

这里的核心：还是在于，保证年轻代gc别太过于频繁，还得考虑，GC过后存活的对象别太多直接，进入老年代，频繁触发 mixed GC

什么情景适合使用 G1

1:50%医生的堆被活对象占用。

2：垃圾回收的时间特别长，超过1秒

3:8G以上的堆内存，建议使用

4：停顿时间是500ms 以内