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