对大家啰嗦几句，很多时候我不会去深入了解一样东西，很多知识在脑海中有一个印象。等用到的时候才会认真仔细的来了解此内容。
因为这个原因，自己没有得到很好的提升。
最新，线上的hbase挂掉了：
找下日志的原因是CMS回收时间长达60s引起的。(运行了不少时间，不知道CMS每次的回收时长都是这么大，还是CMS使用标记-整理算法引起的时长过大,也可能是CPU资源的影响)。
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
原文：https://www.cnblogs.com/parent-absent-son/p/10697961.html