Java虚拟机--垃圾收集

时间:2022-12-15 06:41:41

Java虚拟机

1. JVM运行时数据区域

  • 参考书籍:《深入理解Java虚拟机:JVM高级特性与最佳实践,第二版》
  • 资料参考:http://blog.csdn.net/nms312/article/details/37361121
    Java虚拟机--垃圾收集

    2. 垃圾收集及内存分配

  • GC需要考虑的三个问题:
    1. 哪些内存需要回收?
    2. 什么时候回收?
    3. 怎么回收?
  • JVM中主要讨论堆和方法区里的内存回收。 为了解决上面三个问题:
    1. 哪些内存需要回收?即如何确定需要回收的对象
      1. 引用计数算法
      • 主流的java虚拟机里都没有采用这种方法,因为它很难解决对象直接循环引用的问题。
      1. 可达性分析算法
      • 当一个对象到GC Roots没有任何引用链时,则证明对象是不可用的。
      • 在JDK1.2之后,java将引用分为强引用(Strong Reference),软引用(Soft Reference),弱引用(weak Reference),虚引用(Phantom Reference)。
      • 在JVM中可达性分析算法要判断一个对象需要回收,至少要经过两次标记过程:
      • 如果对象在进行可达性分析后发现没有与GC Roots的引用链,那它将会被第一次标记并进行一次筛选,筛选条件是是否有必要执行finalize()方法。当对象没有覆盖该方法,或者finalize()方法已经被虚拟机调用过,虚拟机将这两种情况都视为“没有必要执行”。
      • 如果判断有必要执行,加入F-Queue队列中。finalize()方法是对象逃脱被GC的最后一次机会,稍后GC将对队列中的对象进行第二次标记,如果还是无法与GC roots建立关联,将被真正回收。
    2. 怎么回收?即垃圾收集算法
    • 标记-清除算法
      • 最基础的收集算法,它主要有两个不足:一个是效率问题,另一个是空间问题,产生碎片太多。
    • 复制算法
      • 它将可用内存按容量划分为大小相等的两块, 每次只使用其中的一块
      • 现在商业虚拟机都采用这种收集算法来回收新生代。
      • HotSpot虚拟机默认Eden和Survivor的大小比例是8:1
    • 标记-整理算法
      • 复制收集算法在对象存活率较高时就要进行较多的复制操作, 效率将会变低。所以在老年代里一般不直接使用这种算法。
      • 标记过程仍然与“标记-清除”算法一样, 但后续步骤不是直接对可回收对象进行清理, 而是让所有存活的对象都向一端移动, 然后直接清理掉端边界以外的内存。
    • 分代收集算法
      • 当前商业虚拟机的垃圾收集都采用“分代收集”( Generational Collection) 算法。根据对象存活周期的不同将内存划分为几块。 一般是把Java堆分为新生代和老年代, 这样就可以根据各个年代的特点采用最适当的收集算法。

3. JDK的HotSpot虚拟机的垃圾收集器

  • 这里讨论的收集器基于JDK 1.7 Update 14之后的HotSpot虚拟机
    Java虚拟机--垃圾收集
  • 展示了7种作用于不同分代的收集器,如果两个收集器之间存在连线, 就说明它们可以搭配使用。 虚拟机所处的区域, 则表示它是属于新生代收集器还是老年代收集器。
  • Serial收集器
    • Serial收集器是最基本,发展历史最悠久的收集器,曾经(再JDK1.3之前)是虚拟机新生代收集的唯一选择。
    • 它是一个单线程收集器,它在进行垃圾收集时,必须暂停其他所有的工作线程,直到收集结束。
    • 它是虚拟机运行在client模式下的默认新生代收集器。
    • 优于其他收集器的地方: 简单而高效( 与其他收集器的单线程比) , 对于限定单个CPU的环境来说, Serial收集器由于没有线程交互的开销, 专心做垃圾收集自然可以获得最高的单线程收集效率。
  • ParNew收集器
    • ParNew收集器其实就是Serial收集器的多线程版本。
    • ParNew收集器除了多线程收集之外, 其他与Serial收集器相比并没有太多创新之处, 但它却是许多运行在Server模式下的虚拟机中首选的新生代收集器, 其中有一个与性能无关但很重要的原因是, 除了Serial收集器外, 目前只有它能与CMS收集器配合工作。
    • 并发和并行:这两个名词都是并发编程中的概念
    • 并行( Parallel) : 指多条垃圾收集线程并行工作, 但此时用户线程仍然处于等待状态。
    • 并发( Concurrent) : 指用户线程与垃圾收集线程同时执行( 但不一定是并行的, 可能会交替执行) , 用户程序在继续运行, 而垃圾收集程序运行于另一个CPU上。
  • Parallel Scavenge收集器
    • Parallel Scavenge收集器是一个新生代收集器, 它也是使用复制算法的收集器, 又是并行的多线程收集器。
    • Parallel Scavenge收集器的目标是达到一个可控制的吞吐量( Throughput)。
    • 吞吐量=运行用户代码时间/( 运行用户代码时间+垃圾收集时间)
    • 由于与吞吐量关系密切, Parallel Scavenge收集器也经常称为“吞吐量优先”收集器。
    • 自适应调节策略也是ParallelScavenge收集器与ParNew收集器的一个重要区
      别。
  • Serial Old收集器
    • Serial Old是Serial收集器的老年代版本, 它同样是一个单线程收集器, 使用“标记-整理”算法。
    • 这个收集器的主要意义也是在于给Client模式下的虚拟机使用。
    • 在Server模式下, 那么它主要还有两大用途:
      • 一种用途是在JDK 1.5以及之前的版本中与Parallel Scavenge收集器搭配使用
      • 另一种用途就是作为CMS收集器的后备预案
  • Parallel Old收集器
    • Parallel Old是Parallel Scavenge收集器的老年代版本, 使用多线程和“标记-整理”算法。
    • 这个收集器是在JDK 1.6中才开始提供的, 在此之前, 新生代的Parallel Scavenge收集器一直处于比较尴尬的状态。 原因是, 如果新生代选择了ParallelScavenge收集器, 老年代除了Serial Old( PS MarkSweep) 收集器外别无选择
    • 直到Parallel Old收集器出现后, “吞吐量优先”收集器终于有了比较名副其实的应用组合,在注重吞吐量以及CPU资源敏感的场合, 都可以优先考虑Parallel Scavenge加Parallel Old收集器。
  • CMS收集器
    • 在JDK 1.5时期,HotSpot推出了一款在强交互应用中几乎可认为有划时代意义的垃圾收集器——CMS收集器( Concurrent Mark Sweep)
    • 这款收集器是HotSpot虚拟机中第一款真正意义上的并发( Concurrent) 收集器, 它第一次实现了让垃圾收集线程与用户线程( 基本上) 同时工作
    • CMS( Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。基于“标记—清除”算法实现,整个过程分为4个步骤:
      • 初始标记( CMS initial mark)
      • 并发标记( CMS concurrent mark)
      • 重新标记( CMS remark)
      • 并发清除( CMS concurrent sweep)
    • 优点:并发收集、 低停顿
    • 缺点:
      • CMS收集器对CPU资源非常敏感。
      • CMS收集器无法处理浮动垃圾,可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。
      • CMS是一款基于“标记—清除”算法实现的收集器。意味着收集结束时会有大量空间碎片产生。
  • G1收集器
    • G1( Garbage-First) 收集器是当今收集器技术发展的最前沿成果之一,被视为JDK 1.7中HotSpot虚拟机的一个重要进化特征。
    • 特点:并行与并发,分代收集,空间整合,可预测的停顿。
    • 与CMS的“标记—清理”算法不同, G1从整体来看是基于“标记—整理”算法实现的收集器, 从局部( 两个Region之间) 上来看是基于“复制”算法实现的, 但无论如何, 这两种算法都意味着G1运作期间不会产生内存空间碎片,收集后能提供规整的可用内存。