垃圾回收机制(GC)

垃圾收集器(GC)与内存分配策略

GC需要完成的三件事：

判断哪些内存需要回收
什么时候回收
如何回收

　　在java内存运行时区域的各个部分中，程序计数器、虚拟机栈、本地方法栈3个区域随线程而生，随线程而灭；栈中的栈帧随方法的进入和退出而有条不紊地执行出栈和入栈操作。每一个栈帧中分配多少内存基本上是在类结构确定下来时已知的，因此这几个区域的内存分配和回收都具备确定性，在这几个区域内就不需要过多考虑回收问题，因为方法结束或者线程结束时，内存自然就跟着回收了。

　　而java堆和方法区则不一样，一个接口中的多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存可能也不一样，我们只有在程序运行期间才能知道会创建哪些对象，这部分内存的分配和回收是动态的，垃圾收集器所关注的便是这部分内存。

一、对象已经死了吗？

　　垃圾收集器在对堆回收之前，首先要确定哪些对象还 “存活” ，哪些对象已经 “死去” 。

　　1. 引用计数算法

　　一个对象被引用计数器加一，取消引用计数器减一，引用计数器为0才能被回收。　　　　

优点：实现简单，判定效率也较高。
缺点：不能解决循环引用的问题，比如A引用B，B引用A，但是这两个对象没有被其他任何对象引用，属于垃圾对象，却不能回收；每次引用都会附件一个加减法，影响性能。

class ReferenceCountingGC {

    /**
     * -verbose:gc -XX:+PrintGCDetails -Xms30M -Xmx30M -Xmn10M 
     */
    public static final int _1M = 1024 * 1024;
    private ReferenceCountingGC ref = null;
    private byte[] content = new byte [_1M * 1];

    public void testGC() {
        ReferenceCountingGC a = new ReferenceCountingGC();
        ReferenceCountingGC b = new ReferenceCountingGC();
        a.ref = a;
        b.ref = b;
        a = null;
        b = null;
        System.gc();

    }

    public static void main(String[] args) {
        new ReferenceCountingGC().testGC();
    }

}

　　Run：java -XX:+PrintGCDateStamps -XX:+PrintGCDetails ReferenceCountingGC

　　从运行结果看，GC日志中包 " 3706k->1376k " ,意味着虚拟机并没有因为这两个对象相互引用而不去回收它们，这也从侧面说明了虚拟机并不是通过引用计数算法来判断对象是否是存活的。

　　2. 可达性分析算法

　　算法的基本思路：通过一系列的称为 “GC Roots" 的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain）。当一个对象到GC Roots没有任何引用链相连（以图论的角度看，就是GC Roots到这个对象不可达），则证明该对象是不可用的（判定为可回收对象）。

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

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

　3.回收方法区

　　java虚拟机在方法区中进行垃圾收集的 “性价比” 一般较低，尤其是在新生代中，常规应用进行一次垃圾收集一般可以回收70%~95%，而永久代的垃圾收集效率远低于此。

　　永久代的垃圾收集主要回收两部分内容：（1）废弃常量（2）无用类

　　废弃常量：以常量池中字面量的回收为例，假如一个字符串 “abc” 进入常量池中，但是当前系统没有任何一个String对象引用常量池的 “abc” 常量，也没有其他地方引用这个常量。此时　　　　　　　“abc” 便是所谓的废弃常量，需要被回收。

　　无用类：满足以下三个条件的类。

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

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

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

二、垃圾收集算法　

　　1. 标记-清除算法

　　该算法分为 “标记” 和 “清除” 两个阶段。首先标记出所有需要回收的对象，然后统一回收。

　　缺点：（1）效率问题。标记和清除两个过程效率都不高

　　　　　（2）空间问题。标记清除后会产生大量不连续的内存碎片，空间碎片太多会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

　　2. 复制算法

　　　　为了解决效率问题，一种称为 “复制” 的收集算法出现了，它将可用内存按容量划分为大小相等的两块，每一次只使用其中一块。当这一块内存用完了，就将还存活着的对象复制到另一块上面，然后再把已经使用过的内存一次清理掉。这使得每次都是对整个半　区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。　　

　　缺点：（1）这种算法的代价将内存缩小为原来的一半，未免太高了些。

　　　　　（2）在对象存活率较高时会进行较多的复制操作，效率会变低。

　　3. 标记-整理算法

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

　　因此，我们根据老年代的特点，提出了 “标记-整理“ 算法。该算法的标记过程仍然与 ”标记-清楚“ 算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。

　　4. 分代收集算法

　　　　当前商业虚拟机的垃圾收集都采用 ”分代收集“ 算法，该算法只是根据对象存活周期的不同将内存划分为几块。一般是把java堆分为新生代和老生代，这样就可以根据各个年代的特点采用最合适的收集算法。

　　在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率较高、没有额外空间对它进行分配

　　担保，就必须使用 ”标记-整理“ 或者 ”标记-整理“ 算法来进行回收。

三、HotSpot的算法实现

　　1.枚举根节点

　　1.目前主流的Java虚拟机使用的都是准确式GC，当执行系统停顿下来后并不需要一个不漏的检查完所有执行上下文和全局的引用变量，虚拟机应当有办法直接得知哪些地方存着对象的引用
　　2.HotSpot使用一组称为OopMap的数据结构来记录哪些地方存着对象的引用
　　3.在类加载过程中，HotSpot就把对象内什么偏移量上是什么类型的数据计算出来，在JIT编译过程中会在特定的位置记录下栈和寄存器中哪些位置是引用

　　2.安全点

　　1.HotSpot没有为每条指令都生成OopMap，只是在特定位置记录了这些信息，这些位置称为安全点
　　2.程序执行时并非在所有地方都能停顿下来开始GC，只有在到达安全点时才能暂停
　　3.给多线程记录安全点时有两种方案：抢先式中断和主动式中断
　　4.主动式中断的思想是当GC需要中断线程时不直接对线程进行操作，仅仅简单的设置一个标志，各个线程执行时主动去轮询这个标志，发现中断标志为真时就自己中断挂起

　　3.安全区域

　　1.为了处理“不执行”的程序的安全点问题，提出了安全区域来解决问题
　　2.安全区域是指在一段代码片段之中，引用关系不会发生变化，在这个区域内的任何地方进行GC都是安全的
　　3.虚拟机如歌具体的进行内存回收是由虚拟机所采用的GC收集器决定的，而通常虚拟机中往往不止有一种GC收集器

　　四、垃圾收集器

　　HotSpot 虚拟机的垃圾收集器

如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现
不同的收集器应用的区域不同，到现在为止没有最好的收集器，也没有万能的收集器

　　1.Serial收集器

　　　　1.Serail收集器是“单线程”的，他在进行垃圾收集时必须暂停其他的所有线程，直到收集结束
　　　　2.随着收集器的发展，用户线程的停顿时间越来越段，但任然无法消除
　　　　3.Serial收集器是虚拟机运行在Client模式下默认的新生代收集器
　　　　4.对于单个CPU坏境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集，可以获得很高的单线程收集效率

　　2.ParNew收集器

　　　　1.ParNew收集器是Serial收集器的多线程版本
　　　　2.ParNew收集器是运行在Server模式下虚拟机中首选的新生代收集器
　　　　3.在垃圾收集器中“并发”与“并行”的概念：

并行：多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态
并发：用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替执行），用户程序在继续运行，而垃圾收集程序运行在另一个CPU上

　 3.Parallel Scavenge收集器

　　　　1.Parallel Scavenge收集器是一个新生代收集器，采用复制算法
　　　2.Parallel Scavenge收集器的特点是他的关注点与其他收集器不同。其他收集器的目标是尽可能的缩短用户线程的停顿时间，而Parallel Scavenge收集器的目标是达到一个可控的吞吐量
　　　3.高吞吐量可以高效的利用CPU时间，尽快得完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务
　　　4.GC停顿时间的缩短是以牺牲吞吐量和新生代空间来换取的
　　　5.Parallel Scavenge收集器也经常被称为“吞吐量优先”收集器

　4.Serail Old收集器

　　　　1.Serial Old收集器是Serail收集器的老年代版本，是一个单线程收集器，使用标记-整理算法
　　　　2.Serail Old收集器主要用于Clinet模式下
　　　　3.Serail Old收集器另一种用途是作为CMS收集器的后备预案

　 5.Parallel Old收集器

　　　　1. Parallel Old收集器是Parallel Scavenge收集器的老年代版本，使用多线程和标记-整理算法
　　　　2. 在注重吞吐量和CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器

　 6.CMS收集器

　　　　1.CMS收集器是一种以获取最短的回收停顿时间为目标的收集器
　　　　2.CMS收集器基于标记-清楚算法实现，分为四个步骤：初始标记、并发标记、重新标记、并发清除
　　　　3.步骤详解：

初始标记：标记一下GC Roots能直接关联到的对象，速度很快
并发标记：进行GC Roots Tracing
重新标记：是为了修正那些在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，在这一阶段的停顿时间会比初始标记阶段稍长一点

　　　　4.从总体上说，CMS收集器的内存回收过程是与用户线程一起并发执行的
　　　　5.CMS收集器的缺点：

CMS收集器对CPU资源非常敏感
CMS收集器无法处理浮动垃圾，可能出现“Concurrent Mode Failure”失败而导致另一次Full FC的产生
由于CMS收集器采用了标记-清除算法，所以在回收结束时会有大量空间碎片产生，碎片过多时，在给大对象分配内存时会有很大麻烦

　7.G1收集器

　　　　1.G1收集器是一款面向服务端应用的垃圾收集器
　　　　2.G1收集器具备以下特点：

　　　　　　（1）并行与并发

　　　　　　（2）分代收集

　　　　　　（3）空间整合：从整体上来看是基于“标记-整理”算法实现的，在局部上是基于复制算法实现的

　　　　　　（4）可预测的停顿

　　　 3.G1收集器将整个Java堆划分为多个大小相等的独立区域，虽然还保留有新生代和老生代的概念，但新生代和老生代不再是物理隔的了，他们是一部分Region的集合

　　　　4.G1收集器可以有计划地避免在整个Java堆中进行全区域的垃圾收集：跟踪各个Region里面的垃圾堆积的价值大小，在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region
　　　　5.在G1收集器中，使用Remembered Set来避免全堆扫描

五、内存分配与回收的策略

　　对象的内存分配，往大方向讲，就是在堆上分配，主要分配在新生代的Eden区上，如果启动了本地线程分配缓冲，将按线程优先在TLAB上分配，少数情况也可能会直接分配在老年代中，具体的分配规则取决于虚拟机自己的设置

　　1.对象优先在Eden区分配

　　　　1.大多数情况下，对象优先在新生代的Eden区分配
　　　　2.当Eden区没有足够的空间时，虚拟机将发起一次Minor GC
　　　　3.Minor GC与Full GC：

Minor GC：新生代GC，非常频繁，回收速度快
Fulll GC：老年代GC，又称为Major GC，经常会伴随一次Minor GC，速度比较慢

　　2.大对象直接进入老年代

　　　　1.大对象是指需要大量连续的内存空间的Java对象
　　　　2.虚拟机提供了一个参数：PretenureSizeThreshold，大于这个参数的对象将直接在老年代分配

　　3.长期存活的对象将进入老年代

　　　　1.虚拟机给每个对象定义了一个对象年龄计数器（Age），对象每经过一次Minor GC后仍然存活，且能被Survivor容纳的话，年龄就 +1 ，当年龄增加到一定程度（默认为15），就会被晋升到老年代中，这个阈值可以通过参数 MaxTenuringThreshold 来设置

　　4.动态对象年龄的判定

　　　　1.为了更好的适应不同程序的内存状况，对象年龄不是必须到达阈值才会进入老年代
　　　　2.当Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，或年龄大于等于该年龄的对象就可以直接进入老年代

　　5.空间分配担保

　　　　1.在发生Minor GC之前，虚拟机会首先检查老年代可用最大内存空间是否大于新生代对象总空间—若大于，则会进行一次安全的Minor GC
　　　　2.若上述条件不成立，则虚拟机会查看HandlePromotionFailure设置值是否允许担保失败，若不允许，则进行一次FULL GC
　　　　3.若允许担保失败，则虚拟机会检查老年代最大可用的连续空间是否大于历次晋升到老年代的对象的平均大小，若大于，则进行一次冒险的Minor GC，否则进行一次FULL GC
　　　　4.若担保失败，还是会进行一次FULL GC。之所以要冒险的原因是为了避免频繁的FULL GC

posted @ 2017-10-18 12:30 涛声依旧~ 阅读(213) 评论(0) 编辑收藏举报

刷新页面返回顶部

Tao-Coder