Java虚拟机--垃圾收集

Java虚拟机

1. JVM运行时数据区域

• 参考书籍：《深入理解Java虚拟机：JVM高级特性与最佳实践，第二版》

• 资料参考：http://blog.csdn.net/nms312/article/details/37361121
  

  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虚拟机
  
• 展示了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运作期间不会产生内存空间碎片，收集后能提供规整的可用内存。