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收集器，更有利于程序长时间的运行。因为没有内存碎片。
可预测的停顿。
