JavaSE_ JVM GC垃圾回收算法

参考文章：

http://coderbee.net/index.php/jvm/20131031/547

http://blog.chinaunix.net/uid-7374279-id-4489100.html

http://blog.csdn.net/salahg/article/details/5912101

一、对象存活判断

判断对象是否存活一般有两种方式：

   1.引用计数：每个对象有一个引用计数属性，新增一个引用时计数加1，引用释放时计数减1，计数为0时可以回收。此方法简单，无法解决对象相互循环引用的问题。

  2.可达性分析（Reachability Analysis）：从GC Roots开始向下搜索，搜索所走过的路径称为引用链。当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的，即不可达对象。

  Java 中对象的存活分析使用的是可达性分析 ！

在Java语言中，GC Roots包括：

• 虚拟机栈中引用的对象。
• 方法区中类静态属性实体引用的对象。
• 方法区中常量引用的对象。
• 本地方法栈中JNI引用的对象。

二、JVM的垃圾回收过程

    首先从GC Roots开始进行可达性分析，判断哪些是不可达对象。

    对于不可达对象，判断是否需要执行其finalize方法，如果对象没有覆盖finalize方法或已经执行过finalize方法则视为不需要执行，进行回收；如果需要，则把对象加入F-Queue队列。

   对于F-Queue队列里的对象，稍后虚拟机会自动建立一个低优先级的线程去触发其finalize方法，但不会等待这个方法返回。

    如果在finalize方法的执行过程中，对象重新被引用，那么进行第二次标记时将被移出F-Queue，在finalize方法执行完成后，对象仍然没有被引用，则进行回收。

   对于被移出F-Queue的对象，如果它下一次面临回收时，将不会再执行其finalize方法。即  finalize方法只执行一次。

三、垃圾收集算法

1、引用计数（reference counting）

    原理：此对象有一个引用，则+1；删除一个引用，则-1。只用收集计数为0的对象。

    缺点：无法处理循环引用的问题。如：对象A和B分别有字段b、a，令A.b=B和B.a=A，除此之外这2个对象再无任何引用，那实际上这2个对象已经不可能再被访问，但是引用计数算法却无法回收他们。 

2、复制（copying）

     原理：把内存空间划分为2个相等的区域，每次只使用一个区域。垃圾回收时，遍历当前使用区域，把正在使用的对象复制到另外一个区域。

    优点：不会出现碎片问题。

    缺点：

     1、暂停整个应用。

     2、需要2倍的内存空间。

3、标记-清扫（Mark-and-sweep）---sun前期版本就是用这个技术。

    原理：对于“活”的对象，一定可以追溯到其存活在堆栈、静态存储区之中的引用。这个引用链条可能会穿过数个对象层次。第一阶段：从GC roots开始遍历所有的引用，对有活的对象进行标记。第二阶段：对堆进行遍历，把未标记的对象进行清除。这个解决了循环引用的问题。

   缺点：

    1、暂停整个应用；

    2、会产生内存碎片。

4、标记-压缩（Mark-Compact）自适应

    原理：第一阶段标记活的对象，第二阶段把为标记的对象压缩到堆的其中一块，按顺序放。

   优点：

      1、避免标记扫描的碎片问题；

      2、避免停止复制的空间问题。

    具体使用什么方法GC，Java虚拟机会进行监视，如果所有对象都很稳定，垃圾回收器的效率低的话，就切换到“标记-扫描”方式；同样，Java虚拟机会跟踪“标记-扫描”的效果，要是堆空间碎片出现很多碎片，就会切换回“停止-复制”模式。这就是自适应的技术。

5、分代（generational collecting）-----J2SE1.2以后使用此算法

     原理：基于对象生命周期分析得出的垃圾回收算法。把对象分为年轻代、年老代、持久代，对不同的生命周期使用不同的算法（2-3方法中的一个即4自适应）进行回收。

6、自适应算法(Adaptive Collector)

    在特定的情况下，一些垃圾收集算法会优于其它算法。基于Adaptive算法的垃圾收集器就是监控当前堆的使用情况，并将选择适当算法的垃圾收集器。

        如上图所示：为Java的各代分布图

年轻代（young）

    年轻代分三个区。一个Eden区，两个Survivor区。

    大部分对象在Eden区中生成。当Eden区满时，还存活的对象将被复制到Survivor区（两个中的一个），当这个Survivor区满时，此区的存活对象将被复制到另外一个Survivor区，当第二个Survivor区也满了的时候，从第一个Survivor区复制过来的并且此时还存活的对象，将被复制到tenured generation。

  而且，Survivor区总有一个是空的。young generation的gc称为minor gc。经过数次minor gc，依旧存活的对象，将被移出young generation，移到tenured generation。

需要注意，Survivor的两个区是对称的，没先后关系，所以同一个区中可能同时存在从Eden复制过来对象，和从前一个 Survivor复制过来的对象，而复制到年老区的只有从第一个Survivor去过来的对象.

年老代（tenured）

    存放从年轻代（young）复制过来的对象。生命周期较长的对象，归入到tenured generation。一般是经过多次minor gc，还依旧存活的对象，将移入到tenured generation。（当然，在minor gc中如果存活的对象的超过survivor的容量，放不下的对象会直接移入到tenured generation）。tenured generation的gc称为major gc，就是通常说的full gc。

    采用compaction算法。由于tenured generaion区域比较大，而且通常对象生命周期都比较长，compaction需要一定时间。所以这部分的gc时间比较长。

   minor gc可能引发full gc。当eden＋from space的空间大于tenured generation区的剩余空间时，会引发full gc。这是悲观算法，要确保eden＋from space的对象如果都存活，必须有足够的tenured generation空间存放这些对象。

持久代（perm）

    用于存放静态文件，如Java类、方法等。持久代对垃圾回收没有显著的影响，但是有些应用可能动态生成或者调用一些class。持久代大小通过-XX:MaxPermSize=N进行设置

   该区域比较稳定，主要用于存放classloader信息，比如类信息和method信息。

   对于spring hibernate这些需要动态类型支持的框架，这个区域需要足够的空间。(这部分空间应该存在于方法区而不是heap中)。

四、Minor collections 和 Major collections 

   Minor collection当young space被占满时执行。它比major collections快，因为minor collection仅仅检查major collection相应的一个子集对象。minor collection比major collection发生的频率高。

   Major collection当tenured space被占满时执行。他会清理tenured和young。

   Thinking in java给java gc取了一个罗嗦的称呼：“自适应、分代的、停止-复制、标记-扫描”式的垃圾回收器。

五、导致GC的情况：

1、tenured被写满

2、perm被写满

3、System.gc()的显式调用。

4、上一次GC之后heap的各域分配策略动态变化。

六、GC运行的三种方式 

  在java5和java6中有4种 垃圾回收的算法，有一种算法将不再支持，剩余的三种垃圾回收算法是：serial, throughput and concurrent low pause。 

   Stop the world（停止所有程序的方式）：在这种方式运行的GC，在GC完成前，JVM中的所有程序都不允许运行。Serial collector此时做minor和major收集。Throughput collector此时做major collector。

   Incremental（增量运行方式）：目前没要Java GC算法支持这种运行方式。GC以这种方式运行时，GC允许程序做一小段时间的工作，然后做垃圾回收工作。

   Concurrent（并行运行）：Throughput collector此时做minor collect，Concurrent low pause collector此时做minor和major收集。在这种运行方式下，GC和程序并行的运行，因此程序仅仅被短暂的暂停。

七、关于finalize方法的问题

   finalize方法使得GC过程做了更多的事情，增加的GC的负担。如果某个对象的finalize方法运行时间过长，它会使得其他对象的finalize方法被延迟执行。

  finalize方法中如果创建了strong reference引用了其他对象，这会阻止此对象被GC。

  finalize方法有可能以不可确定的顺序执行（也就是说要在安全性要求严格的场景中尽量避免使用finalize方法）。

  不确保finalize方法会被及时调用，也许程序都退出了，但是finalize方法还没被调用。

八、对象引用的类型 

•    Reference(or named Strong Reference)（ 强引用）：

     普通类型的引用。

•    SoftReference（ 软引用）：

      被这种引用指向的对象，如果此对象没要再被其他Strong Reference引用的话，可能在任何时候被GC。虽然是可能在任何时候被GC，但是通常是在可用内存数比较低的时候，并且在程序抛出OutOfMemoryError之前才发生对此对象的GC。SoftReference通常被用作实现Cache的对象引用，如果这个对象被GC了，那么他可以在任何时候再重新被创建。另外，根据JDK文档中介绍，实际JVM的实现是鼓励不回收最近创建和最近使用的对象。SoftReference 类的一个典型用途就是用于内存敏感的高速缓存。

•    WeakReference（弱引用）：

      如果一个被WeakReference引用的对象，当没要任何SoftReference和StrongReference引用时，立即会被GC。和SoftReference的区别是：WeakReference对象是被eagerly collected，即一旦没要任何SoftReference和StrongReference引用，立即被清楚；而只被SoftReference引用的对象，不回立即被清楚，只有当内存不够，即将发生OutOfMemoryError时才被清除，而且是先清除不常用的。SoftReference适合实现Cache用。WeakReference 类的一个典型用途就是规范化映射（ canonicalized mapping ）

•  PhantomReference（虚引用）：

    当没有StrongReference，SoftReference和WeakReference引用时，随时可被GC。通常和ReferenceQueue联合使用，管理和清除与被引用对象（没有finalize方法）相关的本地资源。

二、垃圾回收器

目前的收集器主要有三种：串行收集器、并行收集器、并发收集器。

1. 串行收集器

   使用单线程处理所有垃圾回收工作，因为无需多线程交互，所以效率比较高。但是，也无法使用多处理器的优势，所以此收集器适合单处理器机器。当然，此收集器也可以用在小数据量（100M左右）情况下的多处理器机器上。可以使用-XX:+UseSerialGC打开。

2. 并行收集器 

  1) 对年轻代进行并行垃圾回收，因此可以减少垃圾回收时间。一般在多线程多处理器机器上使用。使用-XX:+UseParallelGC.打开。并行收集器在J2SE5.0第六6更新上引入，在Java SE6.0中进行了增强--可以堆年老代进行并行收集。如果年老代不使用并发收集的话，是使用单线程进行垃圾回收，因此会制约扩展能力。使用-XX:+UseParallelOldGC打开。

  2) 使用-XX:ParallelGCThreads=<N>设置并行垃圾回收的线程数。此值可以设置与机器处理器数量相等。 

  3)此收集器可以进行如下配置： 

   * 最大垃圾回收暂停:指定垃圾回收时的最长暂停时间，通过-XX:MaxGCPauseMillis=<N>指定。<N>为毫秒.如果指定了此值的话，堆大小和垃圾回收相关参数会进行调整以达到指定值。设定此值可能会减少应用的吞吐量。 

  * 吞吐量:吞吐量为垃圾回收时间与非垃圾回收时间的比值，通过-XX:GCTimeRatio=<N>来设定，公式为1/（1+N）。例如，-XX:GCTimeRatio=19时，表示5%的时间用于垃圾回收。默认情况为99，即1%的时间用于垃圾回收。

3. 并发收集器 

   可以保证大部分工作都并发进行（应用不停止），垃圾回收只暂停很少的时间，此收集器适合对响应时间要求比较高的中、大规模应用。使用-XX:+UseConcMarkSweepGC打开。 

   1)  并发收集器主要减少年老代的暂停时间，他在应用不停止的情况下使用独立的垃圾回收线程，跟踪可达对象。在每个年老代垃圾回收周期中，在收集初期并发收集器会对整个应用进行简短的暂停，在收集中还会再暂停一次。第二次暂停会比第一次稍长，在此过程中多个线程同时进行垃圾回收工作。 

  2) 并发收集器使用处理器换来短暂的停顿时间。在一个N个处理器的系统上，并发收集部分使用K/N个可用处理器进行回收，一般情况下1<=K<=N/4。 

  3) 在只有一个处理器的主机上使用并发收集器，设置为incremental mode模式也可获得较短的停顿时间。 

  4) 浮动垃圾：由于在应用运行的同时进行垃圾回收，所以有些垃圾可能在垃圾回收进行完成时产生，这样就造成了“Floating Garbage”，这些垃圾需要在下次垃圾回收周期时才能回收掉。所以，并发收集器一般需要20%的预留空间用于这些浮动垃圾。 

  5) Concurrent Mode Failure：并发收集器在应用运行时进行收集，所以需要保证堆在垃圾回收的这段时间有足够的空间供程序使用，否则，垃圾回收还未完成，堆空间先满了。这种情况下将会发生“并发模式失败”，此时整个应用将会暂停，进行垃圾回收。 

 6) 启动并发收集器：因为并发收集在应用运行时进行收集，所以必须保证收集完成之前有足够的内存空间供程序使用，否则会出现“Concurrent Mode Failure”。通过设置-XX:CMSInitiatingOccupancyFraction=<N>指定还有多少剩余堆时开始执行并发收集

4. 小结 

* 串行处理器： 

--适用情况：数据量比较小（100M左右）；单处理器下并且对响应时间无要求的应用。 

--缺点：只能用于小型应用 

* 并行处理器： 

--适用情况：“对吞吐量有高要求”，多CPU、对应用响应时间无要求的中、大型应用。举例：后台处理、科学计算。 

--缺点：应用响应时间可能较长 

* 并发处理器： 

--适用情况：“对响应时间有高要求”，多CPU、对应用响应时间有较高要求的中、大型应用。举例：Web服务器/应用服务器、电信交换、集成开发环境。

五、增量式GC

    增量式GC（Incremental GC），是GC在JVM中通常是由一个或一组进程来实现的，它本身也和用户程序一样占用heap空间，运行时也占用CPU。

   当GC进程运行时，应用程序停止运行。因此，当GC运行时间较长时，用户能够感到Java程序的停顿，另外一方面，如果GC运行时间太短，则可能对象回收率太低，这意味着还有很多应该回收的对象没有被回收，仍然占用大量内存。因此，在设计GC的时候，就必须在停顿时间和回收率之间进行权衡。一个好的GC实现允许用户定义自己所需要的设置，例如有些内存有限的设备，对内存的使用量非常敏感，希望GC能够准确的回收内存，它并不在意程序速度的快慢。另外一些实时网络游戏，就不能够允许程序有长时间的中断。

增量式GC就是通过一定的回收算法，把一个长时间的中断，划分为很多个小的中断，通过这种方式减少GC对用户程序的影响。虽然，增量式GC在整体性能上可能不如普通GC的效率高，但是它能够减少程序的最长停顿时间。

   Sun JDK提供的HotSpot JVM就能支持增量式GC。HotSpot JVM缺省GC方式为不使用增量GC，为了启动增量GC，我们必须在运行Java程序时增加-Xincgc的参数。

    HotSpot JVM增量式GC的实现是采用Train GC算法，它的基本想法就是：将堆中的所有对象按照创建和使用情况进行分组（分层），将使用频繁高和具有相关性的对象放在一队中，随着程序的运行，不断对组进行调整。当GC运行时，它总是先回收最老的（最近很少访问的）的对象，如果整组都为可回收对象，GC将整组回收。这样，每次GC运行只回收一定比例的不可达对象，保证程序的顺畅运行。