JVM垃圾回收

对上篇文章的一些补充：

      1.Native方法：指本地方法，当在方法中调用一些不是由java语言写的代码或者在方法中用java语言
直接操纵计算机硬件时要声明为native方法。

      2.直接内存：在JDK1.4中新加入类NIO类，引入了一种基于通道与缓冲区的I/O方式，它可以使用Native函数库直接分配堆外内存，即我们所说的直接内存，这样在某些场景中会提高程序的性能。

      我们讨论的GC其实是针对于方法区和堆的，其他的例如程序计数器、JVM栈、本地方法栈，它们的生命周期是和线程同步的，随着线程的销毁，它们占用的内存会自动释放。什么时候对象被回收呢？答：如果某个对象已经不存在任何引用，那么它可以被回收。

       那么我们如何来确定这个对象是未被引用，是需要被回收的？一般我们有引用计数法和根搜索算法，接下来我们一一阐述下：

       1.引用计数法

       为每个对象添加一个引用计数器，每被引用一次，计数器加1，失去引用，计数器减1，当计数器在一段时间内保持为0时，该对象就认为是可以被回收。但是有个明显的缺陷：当两个对象相互引用，但是实际上二者已经没有作用时，按照常规，应该对其进行垃圾回收，但由于相互引用，又不符合垃圾回收的条件，因此无法处理这块内存清理，因此Sun的JVM并没有采用引用计数算法来进行垃圾回收。而是采用一个叫：根搜索算法，如下图：

                                           

       2.根搜索算法

        如上图所示：基本思想就是：从一个叫GC Roots的对象开始，向下搜索，如果一个对象不能到达GC Roots对象的时候，说明它已经不再被引用，可以被垃圾回收（暂且这样理解，其实事实还有一些不同，当一个对象不再被引用时，并没有完全“死亡”，如果类重写了finalize()方法，且没有被系统调用过，那么系统会调用一次finalize()方法，以完成最后的工作，在这期间，如果可以将对象重新与任何一个和GC Roots有引用的对象相关联，则该对象可以“重生”，如果不可以，那么就说明彻底可以被回收了），如上图中的Object5、Object6、Object7可能相互引用，但是总体来说，它们已经没有作用了，这样就解决了引用计数算法无法解决的问题。

       因为我们这边要被回收的内存有三块：新生代，老生代，方法区，这三个的特点不同，造就了他们所用的GC算法不同，新生代适合那些生命周期较短，频繁创建及销毁的对象，旧生代适合生命周期相对较长的对象，首先介绍下新生代、旧生代、方法区的概念及特点：

                                             

新生代：分为Eden区和Survivor区，Survivor区又分为大小相同的两部分：FromSpace 和ToSpace。新建的对象都是用新生代分配内存，Eden空间不足的时候，会把存活的对象转移到Survivor中，新生代的大小可以由-Xmn来控制，也可以用-XX:SurvivorRatio来控制Eden和Survivor的比例,默认的Eden区和两个Survivor区比例是8：1：1,垃圾回收的时候，总有一个Survivor区是空的，用来存放垃圾回收之后的存活的对象

旧生代：Old Generation。用于存放新生代中经过多次垃圾回收仍然存活的对象，例如缓存对象。每个对象都会有一个年龄，每回收一次存活的对象年龄加1，默认是15，到了设定的这个年纪，JVM就会把对象从新生代中迁移到老生代中。当然大对象我们直接在老生代中分配内存。旧生代占用大小为-Xmx值减去-Xmn对应的值。

持久代：Permanent Generation。在JDK7中开始摒弃，在JDK8中用元空间代替了持久代。持久代中主要存放常量及类的一些信息默认最小值为16MB，最大值为64MB，可通过-XX:PermSize及-XX:MaxPermSize来设置最小值和最大值。

常见的GC算法：

标记-清除算法（Mark-Sweep）

     最基础的GC算法，将需要进行回收的对象做标记，之后扫描，有标记的进行回收，这样就产生两个步骤：标记和清除。这个算法效率不高，而且在清理完成后会产生内存碎片，这样，如果有大对象需要连续的内存空间时，还需要进行碎片整理，所以，此算法需要改进。一般用于老年代。

复制算法（Copying）

     前面我们谈过，新生代内存分为了三份，Eden区和2块Survivor区，一般Sun的JVM会将Eden区和Survivor区的比例调为8:1，保证有一块Survivor区是空闲的，这样，在垃圾回收的时候，将不需要进行回收的对象放在空闲的Survivor区，然后将Eden区和第一块Survivor区进行完全清理，这样有一个问题，就是如果第二块Survivor区的空间不够大怎么办？这个时候，就需要当Survivor区不够用的时候，暂时借持久代的内存用一下。此算法适用于新生代。

标记-整理（或叫压缩）算法（Mark-Compact）

     和标记-清除算法前半段一样，只是在标记了不需要进行回收的对象后，将标记过的对象移动到一起，使得内存连续，这样，只要将标记边界以外的内存清理就行了。此算法适用于持久代。

常见的垃圾收集器： 

根据上面说的诸多算法，每天JVM都有不同的实现，我们先来看看常见的一些垃圾收集器：

                          

首先介绍三种实际的垃圾回收器：串行GC（SerialGC）、并行回收GC（Parallel Scavenge）和并行GC（ParNew）。

      1、Serial GC是一种单线程垃圾回收机制，它最大的特点就是在进行垃圾回收的时候，需要将所有正在执行的线程暂停（Stop The World），只要将它所停顿的时间控制在一定时间内，我们还是可以接受的，结果也是如我们所要，几十毫米的停顿我们作为客户机（Client）是完全可以接受的，该收集器适用于单CPU、新生代空间较小及对暂停时间要求不是非常高的应用上，是client级别默认的GC方式，可以通过-XX:+UseSerialGC来强制指定。
       2、ParNew GC。多线程机制版的Serial GC，提高了效率，可以被用在服务器端上，同时它可以与CMS GC配合，所以，更加有理由将它置于Server端。

      3、Parallel Scavenge GC。在整个扫描和复制过程采用多线程的方式来进行，适用于多CPU、对暂停时间要求较短的应用上，是server级别默认采用的GC方式，可用-XX:+UseParallelGC来强制指定，用-XX:ParallelGCThreads=4来指定线程数。以下给出几组使用组合：

                           

       4、CMS (Concurrent Mark Sweep)收集器。该收集器目标就是解决Serial GC 的停顿问题，以达到最短回收时间。常见的B/S架构的应用就适合用这种收集器，因为其高并发、高响应的特点。CMS收集器是基于“标记-清除”算法实现的，整个收集过程大致分为4个步骤：
      初始标记(CMS initial mark)、并发标记(CMS concurrenr mark)、重新标记(CMS remark)、并发清除(CMS concurrent sweep)。
      其中初始标记、重新标记这两个步骤任然需要停顿其他用户线程。初始标记仅仅只是标记出GC ROOTS能直接关联到的对象，速度很快，并发标记阶段是进行GC ROOTS 根搜索算法阶段，会判定对象是否存活。而重新标记阶段则是为了修正并发标记期间，因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间会比初始标记阶段稍长，但比并发标记阶段要短。由于整个过程中耗时最长的并发标记和并发清除过程中，收集器线程都可以与用户线程一起工作，所以整体来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。
CMS收集器的优点：并发收集、低停顿，但是CMS还远远达不到完美。
CMS收集器主要有三个显著缺点：
     1.CMS收集器对CPU资源非常敏感。在并发阶段，虽然不会导致用户线程停顿，但是会占用CPU资源而导致引用程序变慢，总吞吐量下降。CMS默认启动的回收线程数是：(CPU数量+3) / 4。
     2.CMS收集器无法处理浮动垃圾，可能出现“Concurrent Mode Failure“，失败后而导致另一次Full GC的产生。由于CMS并发清理阶段用户线程还在运行，伴随程序的运行自热会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在本次收集中处理它们，只好留待下一次GC时将其清理掉。这一部分垃圾称为“浮动垃圾”。也是由于在垃圾收集阶段用户线程还需要运行，即需要预留足够的内存空间给用户线程使用，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分内存空间提供并发收集时的程序运作使用。在默认设置下，CMS收集器在老年代使用了68%的空间时就会被激活，也可以通过参数-XX:CMSInitiatingOccupancyFraction的值来提供触发百分比，以降低内存回收次数提高性能。要是CMS运行期间预留的内存无法满足程序其他线程需要，就会出现“Concurrent Mode Failure”失败，这时候虚拟机将启动后备预案：临时启用Serial Old收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。所以说参数-XX:CMSInitiatingOccupancyFraction设置的过高将会很容易导致“Concurrent Mode Failure”失败，性能反而降低。
     3.最后一个缺点，CMS是基于“标记-清除”算法实现的收集器，使用“标记-清除”算法收集后，会产生大量碎片。空间碎片太多时，将会给对象分配带来很多麻烦，比如说大对象，内存空间找不到连续的空间来分配不得不提前触发一次Full GC。为了解决这个问题，CMS收集器提供了一个-XX:UseCMSCompactAtFullCollection开关参数，用于在Full GC之后增加一个碎片整理过程，还可通过-XX:CMSFullGCBeforeCompaction参数设置执行多少次不压缩的Full GC之后，跟着来一次碎片整理过程。
5、G1收集器。相比CMS收集器有不少改进，首先基于标记-整理算法，不会产生内存碎片问题，其次，可以比较精确的控制停顿。
6、Serial Old。Serial Old是Serial收集器的老年代版本，它同样使用一个单线程执行收集，使用“标记-整理”算法。主要使用在Client模式下的虚拟机。
7、Parallel Old。Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。

以上的所有分析都是基于对Sun的HotSpot来分析的

参考：

        https://blog.csdn.net/zhangerqing/article/details/8214365