JVM垃圾回收

一、如何判定对象为垃圾对象

1、引用计数法
引用计数法的逻辑是：在堆中存储对象时，在对象头处维护一个counter计数器，如果一个对象增加了一个引用与之相连，则将counter++。如果一个引用关系失效则counter–。如果一个对象的counter变为0，则说明该对象已经被废弃，不处于存活状态。
如将一个对象赋值为null：Object obj = null;

2、可达性分析法
在主流的商用程序语言中(Java和C#)，都是使用可达性分析算法判断对象是否存活的。这个算法的基本思路就是通过一系列名为GC Roots的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链(Reference Chain)，当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的，下图对象object5, object6, object7虽然有互相判断，但它们到GC Roots是不可达的，所以它们将会判定为是可回收对象。

一般来说，如下情况的对象可以作为GC Roots：
1）虚拟机栈(栈桢中的本地变量表)中的引用的对象
2）方法区中的类静态属性引用的对象
3）方法区中的常量引用的对象
4）本地方法栈中JNI（Native方法）的引用的对象

二、如何回收

1、回收策略
1）标记-清除算法
思想就是标记哪些要被回收的对象，然后统一回收。这种方法很简单，但是会有两个主要问题：1.效率不高，标记和清除的效率都很低；2.会产生大量不连续的内存碎片，导致以后程序在分配较大的对象时，由于没有充足的连续内存而提前触发一次GC动作。

2）复制算法
为了解决效率问题，复制算法将可用内存按容量划分为相等的两部分，然后每次只使用其中的一块，当一块内存用完时，就将还存活的对象复制到第二块内存上，然后一次性清楚完第一块内存，再将第二块上的对象复制到第一块。但是这种方式，内存的代价太高，每次基本上都要浪费一般的内存。
于是将该算法进行了改进，内存区域不再是按照1：1去划分，而是将内存划分为8:1:1三部分，较大那份内存交Eden区，其余是两块较小的内存区叫Survior区。每次都会优先使用Eden区，若Eden区满，就将对象复制到第二块内存区上，然后清除Eden区，如果此时存活的对象太多，以至于Survivor不够时，会将这些对象通过分配担保机制复制到老年代中。(java堆又分为新生代和老年代)

3）标记-整理算法
该算法主要是为了解决标记-清除，产生大量内存碎片的问题；当对象存活率较高时，也解决了复制算法的效率问题。它的不同之处就是在清除对象的时候现将可回收对象移动到一端，然后清除掉端边界以外的对象，这样就不会产生内存碎片了。

4）分代手机算法
现在的虚拟机垃圾收集大多采用这种方式，它根据对象的生存周期，将堆分为新生代和老年代。在新生代中，由于对象生存期短，每次回收都会有大量对象死去，那么这时就采用复制算法。老年代里的对象存活率较高，没有额外的空间进行分配担保，所以可以使用标记-整理 或者 标记-清除。

2、垃圾回收器

1）Serial
Serial收集器是最古老的收集器，它的缺点是当Serial收集器想进行垃圾回收的时候，必须暂停用户的所有进程，即stop the world。Serial收集器由于没有线程交互的开销，专心做垃圾回收自然可以获得最高的单线程收集效率。

2）Pernew（新生代、多线程）
Serial收集器的多线程版本（使用多条线程进行GC）。它是运行在server模式下的首选新生代收集器，除了Serial收集器外，目前只有它能与CMS收集器配合工作。CMS收集器是一个被认为具有划时代意义的并发收集器，因此如果有一个垃圾收集器能和它一起搭配使用让其更加完美，那这个收集器必然也是一个不可或缺的部分了。

3）ParNew Scanvenge（新生代、多线程）
类似ParNew，但更加关注吞吐量。目标是：达到一个可控制吞吐量的收集器。
停顿时间和吞吐量不可能同时调优。我们一方买希望停顿时间少，另外一方面希望吞吐量高，其实这是矛盾的。因为：在GC的时候，垃圾回收的工作总量是不变的，如果将停顿时间减少，那频率就会提高；既然频率提高了，说明就会频繁的进行GC，那吞吐量就会减少，性能就会降低。

吞吐量：CPU用于用户代码的时间/CPU总消耗时间的比值。
吞吐量=运行用户代码的时间/(运行用户代码时间+垃圾收集时间)。比如，虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%。

可以通过 -XX:MaxGCPauseMillis(垃圾收集器最大停顿时间)和-XX:GCTimeRatio(吞吐量大小)可控制该收集器实现可控吞吐量的设置
停顿时间越短，用户体验度越好，而对于服务端更注重吞吐量，在不要太多交互的场景parallel更加适合高并发的设计

4）CMS
CMS收集器（Concurrent Mark Sweep：并发标记清除）是一种以获取最短回收停顿时间为目标的收集器。适合应用在互联网站或者B/S系统的服务器上，这类应用尤其重视服务器的响应速度，希望系统停顿时间最短。所有的收集器当中，当执行GC时，都会stop the world，但是CMS收集器却不会这样。
CMS收集器运行过程：（着重实现了标记的过程）
（1）初始标记
　　根可以直接关联到的对象
　　速度快
（2）并发标记（和用户线程一起）
　　主要标记过程，标记全部对象
（3）重新标记
　　由于并发标记时，用户线程依然运行，因此在正式清理前，再做修正
（4）并发清除（和用户线程一起）
　　基于标记结果，直接清理对象
　　
优点：
并发收集，低停顿
缺点：
（1）导致用户的执行速度降低。
（2）无法处理浮动垃圾。因为它采用的是标记-清除算法。有可能有些垃圾在标记之后，需要等到下一次GC才会被回收。如果CMS运行期间无法满足程序需要，那么就会临时启用Serial Old收集器来重新进行老年代的收集。
（3）由于采用的是标记-清除算法，那么就会产生大量的碎片。往往会出现老年代还有很大的空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前触发一次full GC。

疑问：既然标记-清除算法会造成内存空间的碎片化，CMS收集器为什么使用标记清除算法而不是使用标记整理算法：
答案：
CMS收集器更加关注停顿，它在做GC的时候是和用户线程一起工作的（并发执行），如果使用标记整理算法的话，那么在清理的时候就会去移动可用对象的内存空间，那么应用程序的线程就很有可能找不到应用对象在哪里。

5）G1
是当今收集器发展的最前言成果之一
优点：
　　它最大的优点是结合了空间整合，不会产生大量的碎片，也降低了进行gc的频率。二是可以让使用者明确指定停顿时间。（可以指定一个最小时间，超过这个时间，就不会进行回收了）它有了这么高效率的原因之一就是：对垃圾回收进行了划分优先级的操作，这种有优先级的区域回收方式保证了它的高效率。
如果你的应用追求停顿，那G1现在已经可以作为一个可尝试的选择；如果你的应用追求吞吐量，那G1并不会为你带来什么特别的好处。

三、何时回收