java垃圾收集器

堆中几乎存放着Java世界中所有的对象实例，垃圾收集器在对堆进行回收前首先要确定哪些对象还活着，哪些对象已经死去。

1，判断对象是否已死

1.1引用计数算法

给对象中添加一个引用计数器，每当有一个地方引用它时，计数器就加1，当引用失效时，计数器就减1；任何时刻计数器都为0的对象是不可能在被使用的。

引用计数算法无法对象之间循环引用的问题。

1.2 根搜索算法

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

在Java中，下面几种对象可以作为GC Roots：

• 虚拟机栈（栈帧中的本地变量表）中引用的对象；
• 方法区中类静态属性引用的对象；
• 方法区中常量引用的对象；
• 本地方法栈中JNI（即Native方法）引用的对象；

1.3 java中的引用类型

有强到弱分为强引用（Strong Reference）,软引用（Soft Reference），弱引用(Weak Reference)和虚引用(Phantom Reference) 四种。

• 强引用（Strong Reference）：就是指在程序代码中普遍存在的，类似Object obj = new Object()这类的引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象。

强引用具备以下三个个特点：

1. 强引用可以直接访问目标对象；

2. 强引用所指向的对象在任何时候都不会被系统回收。JVM宁愿抛出OOM异常也不回收强引用所指向的对象； 

3. 强引用可能导致内存泄露；

• 软引用（Soft Reference）：是用来描述一些还有用但并非必须的对象。对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行第二次回收。如果这次回收还没有足够的内存，才会抛出内存溢出异常。在 JDK 1.2 之后，提供了 SoftReference 类来实现软引用。
• 弱引用(Weak Reference)： 用来描述非必须的对象，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发送之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。一旦一个弱引用对象被垃圾回收器回收，便会加入到一个注册引用队列中。在 JDK 1.2 之后，提供了 WeakReference类来实现弱引用。

软引用、弱引用都非常适合来保存那些可有可无的缓存数据。如果这么做，当系统内存不足时，这些缓存数据会被回收，不会导致内存溢出。而当内存资源充足时，这些缓存数据又可以存在相当长的时间，从而起到加速系统的作用。

• 虚引用(Phantom Reference)：虚引用也称为幽灵引用或者幻影引用，它是最弱的一种引用关系。一个持有虚引用的对象，和没有引用几乎是一样的，随时都有可能被垃圾回收器回收。当试图通过虚引用的get()方法取得强引用时，总是会失败。并且，虚引用必须和引用队列一起使用，它的作用在于跟踪垃圾回收过程。在 JDK 1.2 之后，提供了 PhantomReference类来实现虚引用。

2，垃圾收集算法

（1）标记-清除算法

标记-清除（Mark-Sweep）算法是最基础的收集算法，算法名字表明这个算法的垃圾收集过程包括两步：标记和清除。前面介绍的判定垃圾的过程就是标记过程，在标记过后的清除过程中会清理标记为垃圾的对象。后序的垃圾收集算法都是在这个算法的基础上改进而成的。这个算法有两个不足：一个就是标记和清除的效率不高；第二个是空间问题，标记清除后会产生大量不连续的内存碎片，空间碎片太多的话可能导致以后分配大块内存时失败的问题，这样就会触发另一次垃圾收集操作。算法的执行过程如下图：

（2）复制算法

复制算法是为了解决标记-清除算法效率不高的问题的，它将可用内存按照容量分为大小相等的两部分，每次只使用其中的一块。当一块的内存用完了，就将还存活的对象复制到另一块，然后再把已经使用过的内存空间一次性清理掉。这样使得每次是对整个半区进行内存回收，内存分配时也不需要考虑内存碎片的问题，只要移动堆顶指针，按顺序进行分配就好。算法的执行过程如下图：

不过这个算法使得内存只能一半能用，代价太高了。现在的虚拟机都采用这种方法来回收新生代，不过不是1:1分配的，而是将堆内存分为以块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和一个Survivor空间。当回收时，将Eden和Survivor中还存活的对象复制到另一块Survivor中，然后清理Eden和使用过的Survivor空间。HotSpot虚拟机默认的Eden和Survivor比例是8:1，即Eden占堆的80%空间，Survivor占10%的空间，每次只能使用90%的堆空间。

不过，我们并不能保证每次回收只有不多于10%的对象存活，当Survivor空间不够时，需要使用其他内存空间（老年代）进行分配担保，即如果Survivor空间不够，存活的对象直接进入老年代。

（3）标记-整理算法

复制收集算法在对象存活率较高时就需要进行较多的复制操作，效率就会降低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都存活的极端情况，所以在老年代中一般不使用这种算法。

根据老年代的特点，可以使用另一种标记-整理（Mark-Compact）算法，标记过程和标记-清除算法一样，但后续步骤不是直接对可回收对象进行清理，而是整理存活的对象，将存活的对象都向一端移动，然后直接清理掉边界外的内存。算法的执行过程如下：

这样，也没有了内存碎片的问题。

（4）分代收集算法

现在的虚拟机都使用“分代收集”算法，这种算法只是根据对象的存活周期的不同将内存划分为几块。一般把Java堆空间分为新生代和老年代，这样就可以根据各个年代的特点采用最适合的收集算法。在新生代，每次垃圾收集都会有大量的对象死去，只有少量存活，这样就可以选择复制算法，只需复制少量存活的对象就可以完成垃圾收集。在老年代中，对象的存活率高、没有额外的空间对它进行分配担保，就必须采用标记-清除或标记-整理算法来进行回收。

3，HotSpot虚拟机中的垃圾收集器

（1）Serial收集器

Serial收集器是最基本的、历史最悠久的收集器，曾经是JDK 1.3.1之前虚拟机的新生代收集的唯一选择。Serial这个名字揭示了这是一个单线程的垃圾收集器，特点如下：

• 仅仅使用一个线程完成垃圾收集工作；
• 在垃圾收集时必须暂停其他所有的工作线程，知道垃圾收集结束；
• Stop the World是在用户不可见的情况下执行的，会造成某些应用响应变慢；
• 使用复制算法；

Serial收集器的工作流程如下图：

虽然如此，Serial收集器依然是虚拟机运行在Client模式下的默认新生代收集器。它的优点同样明显：简单而高效（单个线程相比），并且由于没有线程交互的开销，专心做垃圾收集自然课获得最高的单线程效率。在一般情况下，垃圾收集造成的停顿时间可以控制在几十毫秒甚至一百多毫秒以内，还是可以接受的。

（2）ParNew收集器

ParNew收集器其实是Serial收集器的多线程版本，与Serial不同的地方就是在垃圾收集过程中使用多个线程，剩下的所有行为包括控制参数、收集算法、Stop the World、对象分配规则和回收策略等都一样。ParNew收集器也使用复制算法。ParNew收集器的工作流程如下图：

ParNew收集器看似没有多大的创新之处，但却是许多运行在Server模式下的虚拟机中首选的新生代收集器，因为，除了Serial收集器外，目前只有ParNew收集器能够与CMS收集器配合工作，而CMS收集器是HotSpot在JDK 1.5时期推出的具有划时代意义的垃圾收集器（后面会介绍到）。

ParNew收集器在单个线程的情况下由于线程交互的开销没有Serial收集器的效果好。不过，随着CPU个数的增加，它对于GC时系统资源的有效利用还是很有好处的。它默认开启的收集线程数与CPU的数量相同。可以使用-XX:ParallelGCThreads参数来限制垃圾收集的线程数。

并发和并行

• 并发（Concurrent），是在同一个cpu上同时（不是真正的同时，而是看来是同时，因为cpu要在多个程序间切换）运行多个程序。
• 并行（Parallel），多个cpu在运行多个程序，每个cpu运行一个程序。

打个比方。并发，就像一个人（cpu）喂2个孩子（程序），轮换着每人喂一口，表面上两个孩子都在吃饭。并行，就是2个人喂2个孩子，两个孩子也同时在吃饭。

（3）Parallel Scavenge收集器

Parallel Scavenge收集器和ParNew类似，是一个新生代收集器，使用复制算法，又是并行的多线程收集器。不过和ParNew不同的是，Parallel Scavenge收集器的关注点不同。

CMS等收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目的则是达到一个可控制的吞吐量。吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间+运行垃圾收集时间）。如果虚拟机一共运行100分钟，垃圾收集运行了1分钟，那么吞吐量就是99%。

停顿时间越短就越适合与用户交互的程序，良好的响应速度能提升用户体验，而高吞吐量则可以高效的利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。

Parallel Scavenge收集器提供了两个参数来精确控制吞吐量，分别是控制最大垃圾收集停顿时间的-XX:MaxGCPauseMillis参数以及直接设置吞吐量大小的-XX:GCTimeRatio参数。

MaxGCPauseMillis参数允许的值是一个大于0的毫秒数，收集器将尽可能在给定时间内完成垃圾收集。不过垃圾收集时间的缩短是以牺牲吞吐量和新生代空间为代价的，短的垃圾收集时间会导致更加频繁的垃圾收集行为，从而导致吞吐量的降低。

GCTimeRatio参数的值是一个大于0且小于100的整数，也就是垃圾收集时间占总时间的比率，相当于吞吐量的倒数。如果设置为19，那允许的最大GC时间就是总时间的5%（1/(1+19)）。默认是99，也就是允许最大1%的垃圾收集时间。

Parallel Scavenge收集器也叫吞吐量优先收集器，它还有一个参数-XX:UseAdaptiveSizePolicy，这是一个开关参数，当这个参数打开后，就不需要手工指定新生代的大小（-Xmn）、Eden和Survivor的比例（-XX:SurvivorRatio）、晋升老年代对象年龄（-XX:PretenureSizeThreshold）等细节了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最适合的停顿时间或最大的吞吐量，这叫GC自适应的调节策略。这也是Parallel Scavenge收集器和ParNew收集器的一个重要区别。

（4）Serial Old收集器

Serial Old是Serial的老年版本，在Serial的工作流程图中可以看到，Serial Old收集器也是一个单线程收集器，使用“标记-整理”算法。这个收集器主要给Client模式下的虚拟机使用。如果在Serve模式下，它有两个用途：一个是在JDK 1.5之前的版本中与Parallel Scavenge收集器搭配使用；另一个就是作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用。这个收集器的工作流程在Serial的后半部分有所体现。

（5）Parallel Old收集器

Parallel Old收集器是Parallel Scavenge收集器的老年版本，它也使用多线程和“标记-整理”算法。这个收集器是在JDK 1.6开始提供。

在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器的组合。Parallel Old收集器的工作流程如下：

（6）CMS收集器

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。在重视响应速度和用户体验的应用中，CMS应用很多。

CMS收集器使用“标记-清除”算法，运作过程比较复杂，分为4个步骤：

• 初始标记（CMS initial mark）
• 并发标记（CMS Concurrent mark）
• 重新标记（CMS remark）
• 并发清除（CMS Concurrent Sweep）

其中，初始标记和并发标记仍然需要Stop the World、初始标记仅仅标记一下GC Roots能直接关联到的对象，速度很快，并发标记就是进行GC RootsTracing的过程，而重新标记阶段则是为了修正并发标记期间因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段长，但远比并发标记的时间短。

由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以整体上说，CMS收集器的内存回收过程是与用户线程一共并发执行的。下图是流程图：

CMS的优点就是并发收集、低停顿，是一款优秀的收集器。不过，CMS也有缺点，如下：

• CMS收集器对CPU资源非常敏感。CMS默认启动的回收线程数是（CPU数量+3）/4，当CPU个数大于4时，垃圾收集线程使用不少于25%的CPU资源，当CPU个数不足时，CMS对用户程序的影响很大；
• CMS收集器无法处理浮动垃圾，可能出现“Concurrent Mode Failure”失败而导致另一次Full GC；
• CMS使用标记-清除算法，会产生内存碎片；

（7）G1收集器

G1（Garbage first）收集器是最先进的收集器之一，是面向服务端的垃圾收集器。与其他收集器相比，G1收集器有如下优点：

• 并行与并发：有些收集器需要停顿的过程G1仍然可以通过并发的方式让用户程序继续执行；
• 分代收集：可以不使用其他收集器配合管理整个Java堆；
• 空间整合：使用标记-整理算法，不产生内存碎片；
• 可预测的停顿：G1除了降低停顿外，还能建立可预测的停顿时间模型；

G1中也有分代的概念，不过使用G1收集器时，Java堆的内存布局与其他收集器有很大的差别，它将整个Java堆划分为多个大小相等的独立区域（Region），G1收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划的避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里垃圾堆积的价值大小（回收所获得的空间大小以及回收所需要的时间的经验值），在后台维护一个优先列表，每次优先收集价值最大的那个Region。这样就保证了在有限的时间内尽可能提高效率。

G1收集器的大致步骤如下：

• 初始标记（Initial mark）
• 并发标记（Concurrent mark）
• 最终标记（Final mark）
• 筛选回收（Live Data Counting and Evacuation）

收集器的流程如下图：