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