JVM垃圾收集器

对大家啰嗦几句，很多时候我不会去深入了解一样东西，很多知识在脑海中有一个印象。等用到的时候才会认真仔细的来了解此内容。

      因为这个原因，自己没有得到很好的提升。

最新，线上的hbase挂掉了：

找下日志的原因是CMS回收时间长达60s引起的。(运行了不少时间，不知道CMS每次的回收时长都是这么大，还是CMS使用标记-整理算法引起的时长过大,也可能是CPU资源的影响)。

       错误原因，说明书url：http://hbase.apache.org/book.html#trouble.rs.runtime.zkexpired。解决方法：

• Make sure you give plenty of RAM (in hbase-env.sh), the default of 1GB won’t be able to sustain long running imports.

• Make sure you don’t swap, the JVM never behaves well under swapping.

• Make sure you are not CPU starving the RegionServer thread. For example, if you are running a MapReduce job using 6 CPU-intensive tasks on a machine with 4 cores, you are probably starving the RegionServer enough to create longer garbage collection pauses.

• Increase the ZooKeeper session timeout

记下上述事件，给自己一个思考的过程。

 

先说下自己有限的认知，现在大部分使用的方式为：

          1-jdk1.7 默认垃圾收集器Parallel Scavenge（新生代）+Parallel Old（老年代）

　　　2- jdk1.8 默认垃圾收集器Parallel Scavenge（新生代）+Parallel Old（老年代）

　　　3- jdk1.9 默认垃圾收集器G1

　　　4-ParNew（新生代）+CMS(老年代)，组合回收器，hbase经常使用。

 

1- Serial收集器

一个单线程的收集器，现在主要应用在Client模式下的虚拟机。

2- ParNew收集器

Serial收集器的多线程版，实现了让垃圾收集线程与用户线程同时工作。

3- Parallel Scavenge收集器

使用的复制算法，支持多线程，CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，而parallel Scavenge目的则是达到一个可控制的吞吐量。

停顿时间越短越适合需要与用户交互的程序，，而吞吐量则是尽可能高效利用CPU。加入需要回收500M的垃圾，CMS则可能是每次回收100，每次2ms，总用时10ms。parallel Scavenge是一次性回收500M，用时5s。

4- Serial Old收集器

serial回收老年代版本，使用“标记-整理算法”。和serial一样主要用在Client模式下的虚拟机。

5- Parallel Old收集器

Parallel Scavenge收集器 的老年代版本，使用“标记-整理”算法。

6- CMS收集器

重视响应时间，使用的是“标记-清理算法”，为了提高程序的交互，希望停顿时间最短。

分为四个阶段：初始标记---并发标记---重新标记---并发清除。 

第一和第三个阶段需要stop-the-world。

缺点有三：1- CMS对CPU资源非常敏感，CPU资源不足时，会挤占用户线程资源；

                  2- CMS收集器无法处理浮动垃圾，由于并发的原因，会出现一些持续的垃圾（称浮动垃圾），可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。

　　          3- 空间碎片，解决方法，是利用“标记-整理算法”进行清理。

7- G1收集器

基于“标记-整理算法”，相对于CMS收集器，更有利于程序长时间的运行。因为没有内存碎片。

可预测的停顿。

可参考：http://www.importnew.com/27793.html