垃圾回收器

垃圾回收器

1.1概述

       gc是自动回收的，那为什么我们还要去了解GC和内存分配呢？答案很简单：当需要排查各种内存溢出，内存泄漏问题时，当垃圾回收成为系统达到更高并发量的瓶颈时，我们就需要对这些“自动化”的技术实施必要的监控和调节

       人们一直在思考GC需要完成的三件事情

               哪些内存需要回收？

               什么时候回收？

               如何回收？

1.2对象已死吗

          在堆里面存放着java世界中几乎所有的对象实例，垃圾回收期在堆进行回收前，第一件事情就是要确定这些对象之中哪些对象还“存活”着，哪些对象已“死去”

1.2.1引用计数算法

　　　很多教科书判断对象是否存活的算法是这样的：给对象中添加一个引用计数器，每当有一个地方引用它时，计数器就加１；当引用失效时，计数器就减１；任何时刻计数器为０的对象就不能再被使用。

　　　客观的说，引用计数算法的实现简单，判定效率也很高，但它很难解决对象之间相互循环引用的关系。

1.2.2可达性分析算法

            在主流的商用程序语言的主流实现中。都是通过可达性分析算法来判定对象存活的。这个算法的基本思路就是通过已些列的成为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径成为引用链，当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的。

         在java语言中，可作为GC Roots的对象包括下面几种

         虚拟机栈（栈帧中的本地变量表）中引用的对象。

         方法区中类静态属性引用的对象

          方法区中常量引用的对象

          本地方法栈中JNI（即一般说的Native方法）引用的对象

1.2.3再谈引用

        无论是通过引用计数算法判断对象的引用数量，还是通过可达性分析算法判断对象的引用链是否可达，判定对象是否存活都与“引用有关”。

        在JDK1.2之后，Java对引用的概念进行了扩充，将引用分为强引用，软引用，弱引用，虚引用4种，这4种引用强度依次逐渐减弱。

        强引用就是指程序代码中普遍存在的，类似“Object obj = new Object()”这类的引用，只要强引用还存在，垃圾回收器永远不会回收掉引用的对象

        软引用能用是用来描述一些还有用但并非必须的对象。对于软引用关联着的对象，在系统将要发生内存溢出异常前，将会把这些对象列进回收范围之中进行第二次回收。如果这次回收还没有足够的内存，才会抛出内存溢出异常。在JDK1.2之后，提供了SoftReference类来实现软引用。

        弱引用也是用来描述非必须对象的，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾回收器之前。当垃圾回收器工作时，无论当前内存是否足够，都会回收掉只被引用关联的对象。在JDK1.2之后，提供了WeakReference类来实现弱引用。

        虚引用也称为幽灵引用或幻影引用，它是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的性就是能在这个对象被回收器回收时收到一个系统的通知。在JDK1.2之后，提供了PhantomReference来实现虚引用。

1.2.4生存还是死亡

         即使在可达性分析算法中不可达的对象，也并非是“非死不可的”，这时候它们暂时处于“缓刑”阶段，要真正宣告一个对象死亡，至少要经历两次标记过程：如果对象在进行可达性分析算法后发现没有与 GC ROOT相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法，或者这个对象的finalize()已经被对象调用过，虚拟机就会将这两种条件判断为没有必要执行。

        如果这个对象被判定有必要执行finalize()方法，那么这个对象将会放置在一个叫做F-Queue的队列之中，并在稍后由一个由虚拟机简历的，低优先级的Finalizer线程去执行它。这里所谓的“执行”是指虚拟机有机会会出发这个条件，但并不允诺会等待它运行结束。稍后GC将对F-Queue中的对象进行第二次的小规模标记，如果对象重新与引用链上的某个对象关联，那么它就实现了一次自我拯救，否则将会被回收。

1.2.5回收方法区

         很多人认为方法区（HotSpot中的永久代）并没有垃圾收集的，java虚拟机规范中确实说过可以不要求虚拟机在方法区实现垃圾回收，而且方法区进行垃圾回收的“性价比”一般比较低：在堆中，尤其是在新生代中，常规应用进行一次垃圾回收便可回收70~95的空间，而永久代的回收效率要远低于此。

         方法区的垃圾回收主要回收两部分内容：废弃常量和无用的类。回收废弃常量与回收java堆中的对象非常相似。以常量池的字面量的回收为例，键入一个字符串“abc”已经进入了常量池中，但是当前系统没有任何一个String的对象叫做“abc”的，换句话说，就是么有任何String对象引用常量池中“abc常量”，也没有其他地方引用了这个字面量，如果这时发生内存回收，而且必要的话，这个“abc”常量就会被系统清理出常量池。常量池中的其他类（接口）。方法，字段的符号引用也与此相似。

         判定一个常量是无用常量比较简单，判定一个类是“无用的类”的条件则相对苛刻许多，类需要同时满足下面3个条件才是无用的类

        1. 该类的所有实例都已经被回收，也就是说java堆中不存在该类的任何实例

         2.加载该类的ClassLoader已经被回收

         3.该类对应的java.lang.Class 对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

         虚拟机可以对满足上述3个条件的无用类进行回收，但并不是象对象一样，不使用了必然会被回收。能否对类进行回收，HotSpot虚拟机提供了-Xnoclassgc参数进行控制，还可以使用-verbose:class以及-XX:+TraceClassLoading、-XX:+TraceClassUnLoading查看类加载和卸载信息，其中-verbose:class以及-XX:+TraceClassLoading可以在Product版的虚拟机使用，-XX:+TraceClassUnLoading参数需要FastDebug版的虚拟机支持

         在大量使用反射，动态代理，CGLib等ByteCode框架，动态生成JSP以及OSGi这类频繁定义ClassLoader的场景都需要虚拟机具备类卸载的功能，以保证永久代不会溢出。

1.3垃圾回收算法

         分为标记-清除算法

         复制算法

         标记-整理算法

         分代收集算法

1.4HotSpot的算法实现

        前面介绍了对象的存活判定算法和垃圾收集算法，而在HotSpot虚拟机实现这些算法时，必须对算法的执行效率有严格的考量，才能保证虚拟机高效运行。

1.4.1枚举根节点

        从可达性分析中GCRoots节点找引用链操作为例，可作为GC Roots的节点主要在全局性的引用（例如常量和静态类引用）与执行上下文（例如栈帧中的本地变量表）中，现在很多应用仅仅方法区就有数百兆，如果要逐个检查这里面的引用，那么必然会消耗很多时间。

        另外，可达性分析对执行时间的敏感还体现在GC停顿上，因为这项分析工作必须在一个能确保一致性的快照中进行-----这里的一致性的意思是指在整个分析期间整个执行系统看起来就像被冻结在某个时间点上，不可以出现分析过程中对象引用关系还在不断变化的情况，该点不满足的话分析结果准确性就无法得到保证。这点是导致GC进行时必须停顿所有java执行线程（Sun将这件事情称为“Stop The World”）的其中一个重要原因，即使是在号称（几乎）不会发生停顿的CMS回收器中，枚举根节点时也是必须要停顿的。

        由于目前的主流java虚拟机使用的都是准确式GC，所以当执行系统停顿后，并不需要一个不漏地检查完所有的执行上下文和全局的引用位置，虚拟机应当有办法直接得知哪些地方存在对象引用。在HotSpot的实现中，是使用一组成为OopMap的数据结构来达到这个目的的，在类加载完成的时候，HotSpot就把对象内什么偏移量上是什么类型的数据计算出来，在JIT编译过程中，也会在特定的位置记录下栈和寄存器中哪些位置是引用。这样GC在扫描时就可以直接得知这些信息了。

1.4.2安全点

         在OopMap的协助下，HotSpot可以快速且准确地完成GCRoots枚举，但一个很现实的问题随之而来：可能导致引用变化，或者说OopMap内容变化的指令非常多，如果为每一条指令都生成对应的OopMap，那将会需要大量的额外空间，这样GC的空间成本将会变得很高。

         实际上，HotSpot也的确没有为每条指令都生成OopMap，前面已经提到，只是在特定的位置记录了这些信息，这些位置称为安全点（Safepoint），即程序执行时并非在所有地方都能停顿下来开始GC，只有在到达安全点时才能暂停。Safepoint的选定既不能太少以至于让GC等待时间太长，也不能过于频繁以至于过分增大运行时的负荷。所以，安全点的选定基本上是以程序“是否具有让程序长时间执行的特征”为标准选定的-------因为每条指令执行的时间都非常短暂，程序不太可能因为指令流太长的原因而过长时间运行，“长时间执行”的最明显特征就是指令序列复用，例如方法调用，循环跳转，异常跳转等，所以具有这些功能的指令才会产生Safepoint。

        对于Safepoint，另一个需要考虑的问题是如何在GC发生时让所有线程（这里不包括执行JNI调用的线程）都“跑”到最近的安全点上再停顿下来。这里有两种方案可供选择：抢先式中断和主动式中断，其中抢先式中断不需要线程的执行代码主动去配合，在GC发生时，首先把所有的线程都中断，如果发现有线程中断的地方不在安全点上，就恢复线程，让它跑到安全点上。

        而主动式中断的思想是当GC需要中断线程的时候，不直接对线程操作，仅仅简单地设置一个标志，各个线程执行时主动轮训这个标志，发现中断标志为真时就自己中断挂起，轮训标志的地方和安全点是重合的，另外再加上创建对象需要分配内存的地方。

1.4.3安全区域

        使用Safepoint似乎已经完美地就解决了如何进入GC的问题，但实际情况却不一定，Safepoint机制保证了程序执行时，在不太长的时间内就会遇到可进入GC的Safepoint。但是，程序“不执行”的时候呢？所谓的程序不执行就是没有分配CPU的时间，典型的例子就是线程处于Sleep状态或者Blocked状态，这时候线程无法相应JVM的中断请求，“走”到安全的地方去中断挂起，JVM也显然不太可能等待线程重新被分配CPU时间。对于这种情况，就需要安全区域去（Safe Region）来解决。

        安全区域是指在一段代码片段中，引用关系不会发生变化。在这个区域中的任何地方开始GC都是安全的。我们可以把安全区域看成扩展了的安全点。

        在线程执行到Safe Region 中的代码时，首先标识自己已经进入了Safe Region，那样，当在这段时间里JVM要发起GC时，就不用管标识自己为Safe Region状态的线程了。在线程要离开Safe Region时，它要检查系统是否已经完成了根节点枚举（或者是整个GC过程），如果完成了，那线程就继续执行，否则它就必须等待直到收到可以安全离开Sate Region的信号为止。

1.5垃圾回收器

        Serial回收器

        ParNew回收器

        Parallel Scavenge回收器

        Seral Old回收器

        Parallel Old回收器

        CMS 回收器

        G1回收器