几种常见垃圾收集器原理及使用

GC调优是为了尽量减少stop the world的时间

1、判断对象是否可回收（存活）

之前介绍过的引用计数法存在一定的缺陷，即循环引用的对象无法被回收，因此jvm中未使用，这里介绍一种新的算法

可达性分析算法

这个算法的基本思路就是通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的。

作为GC Roots的对象包括下面几种：
1 虚拟机栈（栈帧中的本地变量表）中引用的对象。
2 方法区中类静态属性引用的对象。
3 方法区中常量引用的对象。
4 本地方法栈中JNI（即一般说的Native方法）引用的对象。

2、 四种引用级别

1. 强引用（Strong Reference
   强引用是指在程序代码中普遍存在的，类似“Object obj=new Object()”这类的引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象。只要某个对象有强引用与之关联，JVM必定不会回收这个对象，即使在内存不足的情况下，JVM宁愿抛出OutOfMemory错误也不会回收这种对象

2、软引用
java中使用SoftRefence来表示软引用，如果某个对象与软引用关联，那么JVM只会在内存不足的情况下回收该对象。（一般用于缓存，内存足够则从缓存中取数据，否则从数据库重新查找）

3．弱引用（WeakReference）
如果一个对象只具有弱引用，那就类似于可有可无的生活用品。 弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它 所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程， 因此不一定会很快发现那些只具有弱引用的对象。

4．虚引用（PhantomReference）
"虚引用"顾名思义，就是形同虚设，与其他几种引用都不同，虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收。被垃圾回收得时候会收到一个通知

应用场景：
软引用 SoftReference和弱引用 WeakReference，可以用在内存资源紧张的情况下以及创建不是很重要的数据缓存。当系统内存不足的时候，缓存中的内容是可以被释放的。例如，一个程序用来处理用户提供的图片。如果将所有图片读入内存，这样虽然可以很快的打开图片，但内存空间使用巨大，一些使用较少的图片浪费内存空间，需要手动从内存中移除。如果每次打开图片都从磁盘文件中读取到内存再显示出来，虽然内存占用较少，但一些经常使用的图片每次打开都要访问磁盘，代价巨大。这个时候就可以用软引用构建缓存。

常用的垃圾回收器

先上图

上面图片是各个垃圾收集器之间可用的搭配关系，比如新生代用serial，那么老年代只能使用cms和serial old

下面整理一下各大收集器
先讲一个垃圾收集器常见现象stop the world
stop the world:
在垃圾回收过程中经常涉及到对对象的挪动（比如对象在Survivor 0和Survivor 1之间的复制），进而导致需要对对象引用进行更新。为了保证引用更新的正确性，Java将暂停所有其他的线程（Java应用程序的其他所有除了垃圾收集收集器线程之外的线程都被挂起），这种情况被称为“Stop-The-World”，导致系统全局停顿。Stop-The-World对系统性能存在影响，因此垃圾回收的一个原则是尽量减少“Stop-The-World”的时间。

1、Serial/Serial Old

最古老的（java1.3.1之前），单线程，独占式，成熟，适合单CPU 服务器
各参数命令设置时的新生代老年代使用的收集器

命令	意义
-XX:+UseSerialGC	新生代和老年代都用串行收集器
-XX:+UseParNewGC	新生代使用ParNew，老年代使用Serial Old
-XX:+UseParallelGC	新生代使用ParallerGC，老年代使用Serial Old

2、ParNew

和Serial基本没区别，唯一的区别：多线程，多CPU的，停顿时间比Serial少

命令	意义
-XX:+UseParNewGC	新生代使用ParNew，老年代使用Serial Old

3、Parallel Scavenge（ParallerGC）/Parallel Old

关注吞吐量的垃圾收集器，高吞吐量则可以高效率地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间），虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%。

-XX:+UseParallerOldGC：新生代使用ParallerGC，老年代使用Parallel Old
-XX:MaxGCPauseMills ：参数允许的值是一个大于0的毫秒数，收集器将尽可能地保证内存回收花费的时间不超过设定值。不过大家不要认为如果把这个参数的值设置得稍小一点就能使得系统的垃圾收集速度变得更快，==GC停顿时间缩短是以牺牲吞吐量和新生代空间来换取的：==系统把新生代调小一些，收集300MB新生代肯定比收集500MB快吧，这也直接导致垃圾收集发生得更频繁一些，原来10秒收集一次、每次停顿100毫秒，现在变成5秒收集一次、每次停顿70毫秒。停顿时间的确在下降，但吞吐量也降下来了。
-XX:GCTimeRatio 参数的值应当是一个大于0且小于100的整数，也就是垃圾收集时间占总时间的比率，相当于是吞吐量的倒数。如果把此参数设置为19，那允许的最大GC时间就占总时间的5%（即1/（1+19）），默认值为99，就是允许最大1%（即1/（1+99））的垃圾收集时间。
-XX:+UseAdaptiveSizePolicy 自己调控的，当这个参数打开之后，就不需要手工指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX：SurvivorRatio）、晋升老年代对象年龄（-XX：PretenureSizeThreshold）等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量，这种调节方式称为GC自适应的调节策略。如果对于收集器运作原来不太了解，手工优化存在困难的时候，使用Parallel Scavenge收集器配合自适应调节策略，把内存管理的调优任务交给虚拟机去完成将是一个不错的选择。只需要把基本的内存数据设置好（如-Xmx设置最大堆），然后使用MaxGCPauseMillis参数（更关注最大停顿时间）或GCTimeRatio（更关注吞吐量）参数给虚拟机设立一个优化目标，那具体细节参数的调节工作就由虚拟机完成了。自适应调节策略也是Parallel Scavenge收集器与ParNew收集器的一个重要区别。

Concurrent Mark Sweep （CMS）

是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求。从名字（包含“Mark Sweep”）上就可以看出，CMS收集器是基于“标记—清除”算法实现的，
它的运作过程相对于前面几种收集器来说更复杂一些，整个过程分为4个步骤，包括：
初始标记-短暂，仅仅只是标记一下GC Roots能直接关联到的对象，速度很快。
并发标记 和用户的应用程序同时进行，进行GC RootsTracing的过程

重新标记-短暂，为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。
并发清除 由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，
所以，从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。

浮动垃圾：由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在当次收集中处理掉它们，只好留待下一次GC时再清理掉。这一部分垃圾就称为“浮动垃圾”。同时用户的线程还在运行，需要给用户线程留下运行的内存空间。

命令	意义
-XX:+UseConcMarkSweepGC	新生代使用ParNew，老年代的用CMS
-XX:CMSInitialOccupyFraction	CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分空间提供并发收集时的程序运作使用。在JDK 早期版本的默认设置下，CMS收集器当老年代使用了68%的空间后就会被激活，这是一个偏保守的设置，如果在应用中老年代增长不是太快，可以适当调高参数-XX：CMSInitiatingOccupancyFraction的值来提高触发百分比，以便降低内存回收次数从而获取更好的性能，在JDK 1.6中，CMS收集器的启动阈值已经提升至92%。要是CMS运行期间预留的内存无法满足程序需要，就会出现一次“Concurrent Mode Failure”失败，这时虚拟机将启动后备预案：临时启用Serial Old收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。所以说参数-XX：CMSInitiatingOccupancyFraction设置得太高很容易导致大量“Concurrent Mode Failure”失败，性能反而降低。
-XX:+UseCMSCompactAtFullCollection	CMS收集器提供了一个这个开关参数（默认就是开启的），用于在CMS收集器顶不住要进行FullGC时开启内存碎片的合并整理过程，内存整理的过程是无法并发的，空间碎片问题没有了，但停顿时间不得不变长
-XX：CMSFullGCsBeforeCompaction	这个参数是用于设置执行多少次不压缩的Full GC后，跟着来一次带压缩的（默认值为0，表示每次进入FullGC时都进行碎片整理）。

这里找到一份课堂教程的ppt对比，直接粘贴，方便比较