关于Jvm垃圾回收的总结

这是第一次写东西，有什么不对的地方请大家指教，

这篇是对周志明老师的那本书有关Jvm垃圾收集器的总结

1.对象已死

    引用计数

    根搜索

    判断对象是否已死亡需要进行两次标记

 

 

2.垃圾收集算法

    标记-清除：标记需要回收的对象，然后进行清除，这个效率不高，也容易产生内存碎片

    复制算法：就是把内存分块（可以按不同的比例），两块儿中始终有一块儿为空，当一块儿满了之后，把存活的对象复制到另一块，死亡的对象进行清除，这个理念也就产生了HotPot的eden与survivor之分了（老年代一般都不用这个算法）

    标记-整理：让活着的对象向内存的一端移动，剩余死亡的对象清除

    分代收集算法：分为老年代与年轻代，这个算法只是提出了一个分代理念，具体的收集还是需要以上三个或者是其他的算法

 

3.垃圾收集器：如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现

    其中sun公司的Hotspot主要又一下几种垃圾收集器

    年轻代：Serial   ParNew    ParallelScavenge 

    老年代：CMS(1,2,5)   Serial Old(MSC)(1,2,3,4)  ParallelOld(3)

    还有一个G1收集器，这个是最新的垃圾收集器

    这是各个收集器搭配示意图

    

 

 

    一下是各个收集器详细的介绍：

        Serial收集器是一个古老的单线程收集器，他在收集垃圾的时候会发生STW(Stop The World)现象，而且Serial/SerialOld使用的收集算法不同，前者使用的是复制算法，后者是标记整理算法，如下图所示

 

                    

 

他的优势就在于简单高效，没有线程交互的开销，只专注于垃圾回收，Serial收集器对于运行在Client模式下的虚拟机是一个很好的选择，其中如果在SerialOld在server模式下使用还有两个用途与ParallelScanvage配合使用，还可以做cms的预备方案，在Concurrent mode failure失败的时候使用。

        

        ParNew收集器是Serial收集器的多线程版本，除了使用多线程进行垃圾收集之外，其余行为包括Serial收集器可用的所以控制参数、收集算法、STW、对象分配规则，回收策略与Serial收集器都完全一样，示意图如下：

 

 

他是许多server模式下的首选的新生代收集器，除了Serial收集器他是一个能与CMS搭配的收集器(Parallel不能与CMS搭配使用)，他在单cpu的情况下并不比serial收集器的性能好,甚至双核的情况下页不比serial性能要好，但是随着cpu增加的情况下还是有优势的

 

        ParallelScanvage是一个新生代收集器，也是使用并行的多线程收集器，看上去都和ParNew都一样，但是他还有他的特别之处，

他与其他的关注点不一样，cms关注的是最少停顿时间，而他关注的是最大吞吐量(运行代码时间(系统运行时间)/垃圾收集时间+运行代码时间)，停顿时间短是使用哪种交互场景，有良好的相应速度能够提高用户的使用体验，最大吞吐量是可以高效的利用cpu，最短的完成任务，尽快的完成任务，主要是应用到后台应用，而不需要太多的交互任务。他可以是用参数精确的控制吞吐量，他也被称为吞吐量优先收集器，他有一个参数UserAdativeSizePolicy，他可以控制GC自适应调整，不需要指定新生代大小，已经eden与survivor的比例，这种策略称为GC自适应调整策略，这也是与ParNew的区别之一

 

        ParallelOld收集器的产生主要是为了与ParallelScanvage配合使用，后者原来只能与Serialold使用，而前者出现后才是后者成为名副其实的吞吐量优先的收集器，在注重吞吐量与cpu敏感的场合，可优先使用ParallelOld与ParallelScanvage组合

 

        CMS收集器是已获取停顿时间最短的为目标收集器，他特别适合那种重视相应速度，希望停顿时间最短，给用户带来良好的体验，如互联网应用。全拼是 Concurrent Mark Sweep，该收集器使用的是标记-清除算法，他的工作过程主要有以下几步：

        初始标记(STW)

        并发标记

        重新标记(STW)

        并发清除

        初始标记与重新标记仍然会STW，初始标记只是标记GC ROOTS能标记到的对象，速度很快，重新标记为了修正并发标记的时间，因用户用户程序继续运作，而导致标记发生变化的那一部分进行标记(不是太理解)，这个阶段比初始标记要长一些，但是远比并发标记要短。如下图所示

 

CMS并发收集，低停顿。但是他还有一些缺点：

    对CPU比较敏感，当CPU少于4个的时候，性能会下降很多，这是根据他的计算公式来决定的。

    无法收集浮动的垃圾，因为在并发清除的工程中，用户的程序仍然在进行，而收集器没有对这时候产生的垃圾进行标记，所以就产生了浮动的垃圾，因此CMS无法像其他收集器一样等老年代满了之后再运行，当内存达到一定比例的时候就会运行，默认的情况下达到68%的时候就会启动CMS，当应用的老年代的垃圾增长速度较慢，可以适当的挑高这个参数。当在运行的过程中，剩余的内存大小无法满足用户运行，就会发生Concurrent mode failure，这时候虚拟机就会启动预备方案Serial old来进行收集，这样停顿时间就会增大，当那个比例设置的较大的时候就会出现这种情况。

    由于CMS使用的是标记-清除算法，这种算法会产生大量的碎片，因此当内存无法为一个大的对象分配合理的内存，就会触发FULLGC，因此可以使用一个参数，当FULLGC过后，就会进行碎片整理，也可以设置另一个参数在经过多少次FullGC后进行碎片整理。

 

        G1收集器使用了标记-整理的算法，他不会产生碎片，而且可以精确的控制停顿时间，他能让使用者指定在M毫秒内，消耗垃圾时间不会大于N秒，这机会是实时Java(RTSJ)收集器的特征。G1收集器基本上是在不牺牲吞吐量的情况下完成低停顿的内存回收。这是由于G1极力避免全代的垃圾回收，只是回收部分区域。他将老年代与年轻代分为各种不同的区域，而且大小是独立固定的，并且跟踪区域中的垃圾堆积度，后台维护一个优先列表，每次根据运行的垃圾收集时间，来优先收集垃圾最多的区域，这就是G1的由来(Garbage First)，这种区域划分以及划分优先级，可以保证G1在有限的时间内获得最高的收集效率。