垃圾收集算法及各种垃圾收集器

根据对象存活周期的不同将内存分为几块，堆一般分为年轻代和老年代，根据各个代的特点选择合适的垃圾收集算法

将内存分为大小相同的两块，每次使用其中的一块，当一块的内存使用完后，就将还存活的对象复制到另一块去，然后再把使用的空间一次清理掉。

存在问题：空间只有一半

标记存活的对象，回收未被标记的对象（一般这种），或者标记所有需要回收的对象，然后统一回收

存在问题：
1、效率问题（需要标记的对象太多，效率不高）
2、空间问题（标记清除后会有大量不连续碎片）

标记出存活的对象，让所有存活的对象向一端移动，然后直接清理掉端边界以外的内存（根据老年代特点推出的一种标记算法）

单线程收集器，“单线程”指的是它仅会使用一条垃圾收集线程去完成垃圾收集工作，更重要的是它在进行垃圾收集工作的时候必须暂停其他所有的工作线程（STW），直到它收集结束。新生代采用复制算法，老年代采用标记-整理算法。

优点：简单而高效，Serial收集器由于没有线程交互开销，可以获得很高的单线程搜集效率

Serial Old收集器两大用途

Serial收集器的多线程版本，除了使用多线程进行垃圾回收外，其他与Serial收集器类似
Parallel收集器默认的收集线程数跟cpu核数相同，也可使用参数-XX：ParallelGCThreads来指定收集线程数

优点：高效率使用CPU，提高吞吐量，其他垃圾收集器关注的是STW时间

在注重吞吐量和cpu资源的场合，可使用Parallel Scanvenge和Parallel Old收集器，这也是JDK8默认的新生代和老年代收集器

新生代垃圾回收器，除了能与CMS搭配使用外，其余与Parallel类似

老年代垃圾回收器，该收集器以最短回收停顿时间为目标，虚拟机第一款真正意义上的并发收集器，实现了让垃圾收集器和用户线程同时工作

使用标记-清除算法，整个过程分为五部分：
初始标记：STW，记录下GC Roots直接引用的对象，速度很快
并发标记：从GC Roots的直接关联对象开始遍历整个对象图的过程，过程耗时较长但无需停止用户线程，让垃圾收集器线程与用户线程一起并发运行。但也因为用户程序并发运行，可能会导致已经标记过的对象状态发生改变
重新标记：为了修正并发标记期间因用户线程并发运行而导致标记状态发生改变的那部分对象的标记记录，这个阶段的停顿时间比初始标记常，但比并发标记时间短，主要用到了三色标记里的增量更新算法做重新标记
并发清理：GC线程对未标记的区域做清理，这个阶段如果有新增对象会被标记为黑色不做处理
并发重置：重置GC过程中的标记数据

优点：并发收集、低停顿

缺点：
1、对CPU资源敏感，会和应用服务抢资源
2、无法处理浮动垃圾，在并发标记和并发清理期间产生的垃圾，只能等到下一次GC处理
3、空间碎片，使用的标记-清除算法会导致空间碎片产生，可通过-XX：+UseCMSCompactAtFullCollection参数在清理后再做整理
4、不确定性，会存在上次垃圾回收还未完成，然后又被触发的情况，特别是在并发标记和并发清除阶段，回收与系统运行并发，也许还没回收完就再次出发了FullGC，就会concurrent mode failure，此时会进入STW，用Serial Old垃圾回收器来回收

背景：秒杀，每秒1000多单，三台后台服务器（4核8G），每台每秒处理300多单，每个订单对象假定为1KB，每秒300KB订单对象生成，因下单还涉及其他对象（库存、优惠券、积分等），放大20倍，则6000KB每秒（6MB），同时还有其它操作，再放大十倍，则每秒有60MB对象生成，1秒后都成为垃圾对象

原本JVM设置：java -Xms3072M -Xmx3072M -Xss1M -XX:MetaspaceSize=521M -XX:MaxMetaspaceSize=521M -jar microservice-eureka-server.jar

调整后JVM设置：会因为动态对象年龄判断原则经常产生FullGC，经过分析，将JVM参数调整为：java -Xms3072M -Xmx3072M -Xmn2048M -Xss1M -XX:MetaspaceSize=521M -XX:MaxMetaspaceSize=521M -jar microservice-eureka-server.jar

可能出现问题：秒杀场景下，某些时候服务器压力可能比预计的还大，交易处理时间会变长，那对象的存活时间可能会相应延长，导致对象可能两三秒后才能变为垃圾对象，以之前的分析，每次MinorGC后还剩余对象的大小可能为120-180M，导致会直接移动到老年代触发FullGC

优化思想：让短期存活的对象尽量都留在survivor中，不要进入老年代，这样minorgc就会回收掉，不用移到老年代触发FullGC

优化可考虑方面：
1、对象年龄多少移动到老年代：本例中一次MinorGC需要间隔二十几秒，大多数对象在几秒内就会变成垃圾，可以将默认的15改小，比如改为5，则意味着经过5次MinorGC才进入老年代，即经过120s后还未变成垃圾的对象才被移动到老年代，而不是一直在新生代区域复制
2、对象多大直接进入老年代：一般来说设置为1M，比如大的缓存List、Map对象
3、更换垃圾回收器：JDK8默认的垃圾回收器是Parallel、Parallel Old搭配，但如果内存较大（超过4G），系统对停顿时间比较敏感，可以使用ParNew+CMS
对于CMS垃圾回收器参数设置可以从以下考虑：
哪些对象会长期存活：bean、线程池对象、初始化的缓存数据等，这些一般也就几十M，还有就是某次MinorGC完了之后还有超过一两百M的对象存活，会直接进入老年代，如果5-6分钟出现一次这样的情况，那么大概半小时到一小时触发一次FullGC,因MinorGC挪动到老年代的对象一般不大，所以一般不会出现因为老年代空间分配担保机制触发FullGC,其实在秒杀场景下半小时或者一小时触发一次FullGC是可以接受的
碎片整理：因为触发FullGC差不多半小时至一小时一次，FullGC做完之后立即整理和两三次整理一次都行

其实，只要年轻代参数设置合理，老年代CMS的参数基本可用默认值，最后的调整参数为
‐Xms3072M ‐Xmx3072M ‐Xmn2048M ‐Xss1M ‐XX:MetaspaceSize=256M ‐XX:MaxMetaspaceSize=256M ‐XX:SurvivorRatio=8  ‐XX:MaxTenuringThreshold=5 ‐XX:PretenureSizeThreshold=1M ‐XX:+UseParNewGC ‐XX:+UseConcMarkSweepGC  ‐XX:CMSInitiatingOccupancyFraction=92 ‐XX:+UseCMSCompactAtFullCollection ‐XX:CMSFullGCsBeforeCompaction=0

黑色

灰色

白色

多标-浮动垃圾（本该为白色即不标记的标记了颜色）

漏标-读写屏障（本该标记颜色的对象未被标记颜色）