美文网首页java后端程序员
深入理解java虚拟机 摘要(四)--垃圾收集器与内存分配策略

深入理解java虚拟机 摘要(四)--垃圾收集器与内存分配策略

作者: 程序员wp | 来源:发表于2017-12-27 16:23 被阅读0次

    深入理解java虚拟机 摘要


    目录:
    一、自动内存管理机制

    1. 运行时数据区域
    2. HotSpot虚拟机对象探秘
    3. 实战:OutOfMemoryError异常
    4. 垃圾收集器与内存分配策略

    一、自动内存管理机制


    4.垃圾收集器与内存分配策略

    主要考虑 Java堆和方法区 内存

    • 对象死亡判断

      在堆里面存放着Java世界中几乎所有的对象实例,垃圾收集器在对堆进行回收前,第一件事情就是要确定这些对象之中哪些还“存活”着,哪些已经“死去”(即不可能再被任何途径使用的对象)。

      1. 引用计数算法

      给对象中添加一个引用计数器,每当有一个地方引用它时,计数器值就加1;当引用失效时,计数器值就减1;任何时刻计数器为0的对象就是不可能再被使用的。
      主流的Java虚拟机里面没有选用引用计数算法来管理内存,其中最主要的原因是它很难解决对象之间相互循环引用的问题。

      例子:

      public class Tests {
      public Object instance=null;
      private static final int MB=1024*1024;
      /**
      *这个成员属性的唯一意义就是占点内存,以便能在GC日志中看清楚是否被回收过
      */
      public static void main(String[] args){
        Tests objA=new Tests();
        Tests objB=new Tests();
        objA.instance=objB;
        objB.instance=objA;
        objA=null;
        objB=null;
        //假设在这行发生GC,objA和objB是否能被回收?
        System.gc();
        }
      }
      

      启动参数

      -XX:+PrintGCDetails
      

      运行结果(部分)
      [GC (System.gc()) [PSYoungGen: 4601K->1144K(37888K)] 4601K->1152K(123904K), 0.0086625 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
      从运行结果中可以清楚看到,GC日志中包含“4601K->1144K”,意味着虚拟机并没有因为这两个对象互相引用就不回收它们,这也从侧面说明虚拟机并不是通过引用计数算法来判断对象是否存活的。

      1. 可达性分析算法

      在主流的商用程序语言(Java、C#,甚至包括前面提到的古老的Lisp)的主流实现中,都是称通过可达性分析(Reachability Analysis)来判定对象是否存活的。这个算法的基本思路就是通过一系列的称为“GC Roots”的对象作为起始点,从这些节点开始向下搜索,搜索所走过的路径称为引用链(Reference Chain),当一个对象到GC Roots没有任何引用链相连时,则证明此对象是不可用的。

      在Java语言中,可作为GC Roots的对象包括下面几种:
      虚拟机栈(栈帧中的本地变量表)中引用的对象。
      方法区中类静态属性引用的对象。
      方法区中常量引用的对象。
      本地方法栈中JNI(即一般说的Native方法)引用的对象。

      在JDK 1.2之后,Java对引用的概念进行了扩充,将引用分为强引用(StrongReference)、软引用(Soft Reference)、弱引用(Weak Reference)、虚引用(PhantomReference)4种,这4种引用强度依次逐渐减弱。

    • 垃圾收集算法

      1. 标记-清除算法

      最基础的收集算法是“标记-清除”(Mark-Sweep)算法,如同它的名字一样,算法分为“标记”和“清除”两个阶段:首先标记出所有需要回收的对象,在标记完成后统一回收所有被标记的对象,它的标记过程其实在前一节讲述对象标记判定时已经介绍过了。之所以说它是最基础的收集算法,是因为后续的收集算法都是基于这种思路并对其不足进行改进而得到的。
      它的主要不足有两个:一个是效率问题,标记和清除两个过程的效率都不高;另一个是空间问题,标记清除之后会产生大量不连续的内存碎片,空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时,无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

      1. 复制算法

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

      1. 标记-整理算法

      复制收集算法在对象存活率较高时就要进行较多的复制操作,效率将会变低。更关键的是,如果不想浪费50%的空间,就需要有额外的空间进行分配担保,以应对被使用的内存中所有对象都100%存活的极端情况,所以在老年代一般不能直接选用这种算法。
      根据老年代的特点,有人提出了另外一种“标记-整理”(Mark-Compact)算法,标记过程仍然与“标记-清除”算法一样,但后续步骤不是直接对可回收对象进行清理,而是让所有存活的对象都向一端移动,然后直接清理掉端边界以外的内存,

      1. 分代收集算法

      当前商业虚拟机的垃圾收集都采用“分代收集”(Generational Collection)算法,这种算法并没有什么新的思想,只是根据对象存活周期的不同将内存划分为几块。一般是把Java堆分为新生代和老年代,这样就可以根据各个年代的特点采用最适当的收集算法。在新生代中,每次垃圾收集时都发现有大批对象死去,只有少量存活,那就选用复制算法,只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保,就必须使用“标记—清理”或者“标记—整理”算法来进行回收。

    相关文章

      网友评论

        本文标题:深入理解java虚拟机 摘要(四)--垃圾收集器与内存分配策略

        本文链接:https://www.haomeiwen.com/subject/eqbugxtx.html