cms垃圾收集器和par

1、cms垃圾回收演算法在gc過程中哪幾個階段會暫停應用縣城

中間調整過幾次，先搞了幾台機器做了驗證，後來逐步推廣的。
1、調大heap區，由原來的4g，調整到5g，young區的大小不變，還是2g，這時候old區就由2g變為3g了（這樣保證old區有足夠的空間）；
2、設置-XX：UseCMSInitiatingOccupancyOnly，其實這個不關這個問題，只是發現半夜CMS進行的有點頻繁，就禁止掉了悲觀策略；
3、設置CMS區回收的比例，從80%調整到75%，讓old區盡早的進行，有足夠的空間剩餘；

為什麼要有GC（垃圾回收）？

JVM通過GC來回收堆和方法區中的內存，GC的基本原理就是找到程序中不再被使用的對象，然後回收掉這些對象佔用的內存。

主要的收集器有哪些？
引用計數器和跟蹤計數器兩種。
引用計數器記錄對象是否被引用，當計數器為零時，說明對象已經不再被使用，可以進行回收。java中的對象有復雜的引用關系，不是很適合引用計數器，所以sun jdk中並沒有實現這種GC方式。
跟蹤收集器，全局記錄數據的引用狀態，基於一定的條件觸發。執行的時候，從根集合開始掃描對象的引用關系，主要有復制（copying）、標記-清除（Mark-Sweep）、標記-壓縮(Mark-Compact)那種演算法。

2、elasticsearch java 怎麼設置 ignore

今天，事情終於發生了。Java6（Mustang），是2006年早些時候出來的，至今仍然應用在眾多生產環境中，現在終於走到了盡頭。已經沒有什麼理由阻止遷移到Java7(Dolphin)上了。
這也促使我想寫一篇關於在ElasticSearch上配置Java6和7的細微差異的博文。
Elasticsearch對Java虛擬機進行了預先的配置。通常情況下，因為這些配置的選擇還是很謹慎的，所以你不需要太關心，並且你能立刻使用ElasticSearch。
但是，當你監視ElasticSearch節點內存時，你可能嘗試修改一些配置。這些修改是否會改善你的處境？
這篇博文嘗試揭開Elasticsearch配置的神秘面紗，並且討論最常見的調整。最終，會給出一些推薦的配置調整。
Elasticsearch JVM 配置概覽：
這些是Elasticsearch 0.19.11版本的默認配置。
JVM參數 Elasticsearch默認值 Environment變數
-Xms 256m ES_MIN_MEM
-Xmx 1g ES_MAX_MEM
-Xms and -Xmx ES_HEAP_SIZE
-Xmn ES_HEAP_NEWSIZE
-XX:MaxDirectMemorySize ES_DIRECT_SIZE
-Xss 256k
-XX:UseParNewGC +
-XX:UseConcMarkSweepGC +
-XX: 75
-XX:UseCMSInitiatingOccupancyOnly +
-XX:UseCondCardMark (commented out)
首先你注意到的是，Elasticsearch預留了256M到1GB的堆內存。
這個設置適用於開發和演示環境。開發人員只需要簡單的解壓發行包，再執行./bin/elasticsearch -f就完成了Elasticsearch的安裝。當然這點對於開發來說非常棒，並且在很多場景下都能工作，但是當你需要更多內存來降低Elasticsearch負載的時候就不行了，你需要比2GB RAM更多的可用內存。
ES_MIN_MEM/ES_MAX_MEM是控制堆大小的配置。新的ES_HEAP_SIZE變數是一個更為便利的選擇，因為將堆的初始大小和最大值設為相同。也推薦在分配堆內存時盡可能不要用內存的碎片。內存碎片對於性能優化來說非常不利。
ES_HEAP_NEWSIZE是可選參數，它控制堆的子集大小，也就是新生代的大小。
ES_DIRECT_SIZE控制本機直接內存大小，即JVM管理NIO框架中使用的數據區域大小。本機直接內存可以被映射到虛擬地址空間上，這樣在64位的機器上更高效，因為可以規避文件系統緩沖。Elasticsearch對本機直接內存沒有限制(可能導致OOM)。
由於歷史原因Java虛擬機有多個垃圾收集器。可以通過以下的JVM參數組合啟用：
JVM parameter Garbage collector
-XX:+UseSerialGC serial collector
-XX:+UseParallelGC parallel collector
-XX:+UseParallelOldGC Parallel compacting collector
-XX:+UseConcMarkSweepGC Concurrent-Mark-Sweep (CMS) collector
-XX:+UseG1GC Garbage-First collector (G1)
UseParNewGC和UseConcMarkSweepGC組合啟用垃圾收集器的並發多線程模式。UseConcMarkSweepGC自動選擇UseParNewGC模式並禁用串列收集器（Serial collector）。在Java6中這是默認行為。
提煉了一種CMS（Concurrent-Mark-Sweep）垃圾收集設置；它將舊生代觸發垃圾收集的閥值設為75.舊生代的大小是堆大小減去新生代大小。這告訴JVM當堆內容達到75%時啟用垃圾收集。這是個估計的值，因為越小的堆可能需要越早啟動GC。
UseCondCardMark將在垃圾收集器的card table使用時，在marking之前進行額外的判斷，避免冗餘的store操作。UseCondCardMark不影響Garbage-First收集器。強烈推薦在高並發場景下配置這個參數（規避card table marking技術在高並發場景下的降低吞吐量的負面作用）。在ElasticSearch中，這個參數是被注釋掉的。
有些配置可以參考諸如Apache Cassandra項目，他們在JVM上有類似的需求。
總而言之，ElastciSearch配置上推薦：
1. 不採用自動的堆內存配置，將堆大小默認最大值設為1GB
2.調整觸發垃圾收集的閥值，比如將gc設為75%堆大小的時候觸發，這樣不會影響性能。
3.禁用Java7默認的G1收集器，前提是你的ElasticSearch跑在Java7u4以上的版本上。
JVM進程的內存結果
JVM內存由幾部分組成：
Java代碼本身：包括內部代碼、數據、介面，調試和監控代理或者位元組碼指令
非堆內存：用於載入類
棧內存：用於為每個線程存儲本地變數和操作數
堆內存：用於存放對象引用和對象本身
直接緩沖區：用於緩沖I/O數據
堆內存的大小設置非常重要，因為Java的運行依賴於合理的堆大小，並且JVM需要從操作系統那獲取有限的堆內存，用於支撐整個JVM生命周期。
如果堆太小，垃圾回收就會頻繁發生，發生OOM的幾率會很大。
如果堆太大，垃圾回收會延遲，但是一旦回收，就需要處理大量的存活堆數據。並且，操作系統的壓力也會變大，因為JVM進程需要更大的堆，產生換頁的可能性就會提高。
注意，使用CMS垃圾收集器，Java不會把內存還給操作系統，因此配置合理的堆初始值和最大值就非常重要。
非堆內存由Java應用自動分配。沒有什麼參數控制這里的大小，這是由Java應用程序代碼自己決定的。
棧內存在每個線程中分配，在Elasticsearch中，每個線程大小必須由128K增加到256K，因為Java7比Java6需要更大的棧內存 ，這是由於Java7支持新的編程語言特徵來利用棧空間。比如，引入了continuations模型，編程語言的一個著名概念。Continuations模型對於
協同程序、綠色線程（green thread）、纖程（fiber）非常有用 。當實現非阻塞I/O時，一個大的優勢是，代碼可以根據線程實際使用情況編寫，但是運行時仍然在後台採用非阻塞I/O。Elasticsearch使用了多個線程池，因為Netty I/O框架和Guava是Elasticsearch的基礎組件，因此在用Java7時，可以考慮進一步挖掘優化線程的特性。
發揮增加棧空間大小的優勢還是有挑戰的，因為不同的操作系統、不同的CPU架構，甚至在不同的JVM版本之間，棧空間的消耗不是容易比較的。取決於CPU架構和操作系統，JVM的棧空間大小是內建的。他們是否在所有場景下都適合？例如Sloaris Sparc 64位的JVM Xss默認為512K，因為有更大地址指針，Sloaris X86為320K。Linux降為256K。Windows 32位Java6默認320K，Windows 64位則為1024K。
大堆的挑戰
今天，幾GB的內存是很常見的。但是在不久以前，系統管理員還在為多幾G的內存需求淚流滿面。
Java垃圾收集器是隨著2006年的Java6的出現而顯著改進的。從那以後，可以並發執行多任務，並且減少了GC停頓幾率： stop - the - world階段。CMS演算法是革命性的，多任務，並發， 不需要移動的GC。但是不幸的是，對於堆的存活數據量來說，它是不可擴展的。Prateek Khanna 和 Aaron Morton給出了CMS垃圾收集器能夠處理的堆規模的數字。
避免Stop-the-world階段
我們已經學習了Elasticsearch如何配置CMS垃圾收集器。但這並不能組織長時間的GC停頓，它只是降低了發生的幾率。CMS是一個低停頓幾率的收集器，但是仍然有一些邊界情況。當堆上有MB級別的大數組，或者其他一些特殊的場景，CMS可能比預期要花費更多的時間。
MB級別數組的創建在Lucene segment-based索引合並時是很常見的。如果你希望降低CMS的額外負載，就需要調整Lucene合並階段的段數量，使用參數index.merge.policy.segments_per_tier
減少換頁
大堆的風險在於內存壓力上。注意，如果Java JVM在處理大堆時，這部分內存對於系統其它部分來說是不可用的。如果內存吃緊，操作系統會進行換頁，並且，在緊急情況下，當所有其他方式回收內存都失敗時，會強制殺掉進程。如果換頁發生，整個系統的性能會下降，自然GC的性能也跟著下降。所以，不要給堆分配太多的內存。
垃圾收集器的選擇
從Java JDK 7u4開始，Garbage-First（G1）收集器是Java7默認的垃圾收集器。它適用於多核的機器以及大內存。它一方面降低了停頓時間，另一方面增加了停頓的次數。整個堆的操作，例如全局標記，是在應用線程中並發執行的。這會防止隨著堆或存活數據大小的變化，中斷時間也成比例的變化。
G1收集器目標是獲取更高的吞吐量，而不是速度。在以下情況下，它能運行的很好：
1. 存活數據佔用了超過50%的Java堆
2. 對象分配比例或者promotion會有明顯的變化
3. 不希望gc或者compaction停頓時間長（超過0.5至1s）
注意，如果使用G1垃圾收集器，堆不再使用的內存可能會被歸還給操作系統
G1垃圾收集器的不足是CPU使用率越高，應用性能越差。因此，如果在內存足夠和CPU能力一般的情況下，CMS可能更勝一籌。
對於Elasticsearch來說，G1意味著沒有長時間的stop-the-world階段，以及更靈活的內存管理，因為buffer memory和系統I/O緩存能更充分的利用機器內存資源。代價就是小成本的最大化性能，因為G1利用了更多CPU資源。
性能調優策略
你讀這篇博文因為你希望在性能調優上得到一些啟示：
1. 清楚了解你的性能目標。你希望最大化速度，還是最大化吞吐量？
2. 記錄任何事情（log everything），收集統計數據，閱讀日誌、分析事件來診斷配置
3. 選擇你調整的目標（最大化性能還是最大化吞吐量）
4. 計劃你的調整
5. 應用你的新配置
6. 監控新配置後的系統
7. 如果新配置沒有改善你的處境，重復上面的一系列動作，反復嘗試
Elasticsearch垃圾收集日誌格式
Elasticsearch長時間GC下warns級別的日誌如下所示：
[2012-11-26 18:13:53,166][WARN ][monitor.jvm ] [Ectokid] [gc][ParNew][1135087][11248] ration [2.6m], collections [1]/[2.7m], total [2.6m]/[6.8m], memory [2.4gb]->[2.3gb]/[3.8gb], all_pools {[Code Cache] [13.7mb]->[13.7mb]/[48mb]}{[Par Eden Space] [109.6mb]->[15.4mb]/[1gb]}{[Par Survivor Space] [136.5mb]->[0b]/[136.5mb]}{[CMS Old Gen] [2.1gb]->[2.3gb]/[2.6gb]}{[CMS Perm Gen] [35.1mb]->[34.9mb]/[82mb]}
JvmMonitorService類中有相關的使用方式：
Logfile Explanation
gc 運行中的gc
ParNew new parallel garbage collector
ration 2.6m gc時間為2.6分鍾
collections [1]/[2.7m] 在跑一個收集，共花2.7分鍾
memory [2.4gb]->[2.3gb]/[3.8gb] 內存消耗, 開始是2.4gb, 現在是2.3gb, 共有3.8gb內存
Code Cache [13.7mb]->[13.7mb]/[48mb] code cache佔用內存
Par Eden Space [109.6mb]->[15.4mb]/[1gb] Par Eden Space佔用內存
Par Survivor Space [136.5mb]->[0b]/[136.5mb] Par Survivor Space佔用內存
CMS Old Gen [2.1gb]->[2.3gb]/[2.6gb] CMS Old Gen佔用內存
CMS Perm Gen [35.1mb]->[34.9mb]/[82mb] CMS Perm Gen佔用內存
JvmMonitorSer
一些建議
1. 不要在Java 6u22之前的發布版本中跑Elasticsearch。有內存方面的bug。那些超過兩三年的bug和缺陷會妨礙Elasticsearch的正常運行。與舊的OpenJDK 6相比，更推薦Sun/Oracle的版本，因為後者修復了很多bug。
2. 放棄Java6，轉到Java7。Oracle宣稱Java6更新到2013年2月結束。考慮到Elasticsearch還是一個相對新的軟體，應該使用更新的技術來提升性能。盡量從JVM中擠壓性能。檢查操作系統的版本。在最新版本的操作系統中運行，有助於你的Java運行環境達到最佳性能。
3. 定期更新Java運行環境。平均一個季度一次。告訴sa你需要及時更新Java版本，以獲取Java性能的提升。
4. 從小到大。先在Elasticsearch單節點上進行開發。但是不要忘了Elasticsearch分布式的強大功能。單節點不能模擬生產環境的特徵，至少需要3個節點進行開發測試。
5. 在調整JVM之前先做一下性能測試。對你的系統建立性能基線。調整測試時候的節點數量。如果索引時候負載很高，你可能需要降低Elasticsearch索引時候佔用的堆大小，通過index.merge.policy.segments_per_tierparameter參數調整段的合並。
6. 調整前清楚你的性能目標，然後決定是調整速度還是吞吐量。
7. 啟用日誌以便更好的進行診斷。在優化系統前進行小心的評估。
8. 如果使用CMS垃圾收集器，你可能需要加上合理的 -XX:CMSWaitDuration 參數。
9. 如果你的堆超過6-8GB，超過了CMS垃圾收集器設計容量，你會遇到長時間的stop-the-world階段，你有幾個方案：調整參數降低長時間GC的幾率減少最大堆的大小；啟用G1垃圾收集器。
10. 學習垃圾收集調優藝術。如果你想精通的話，列出可用的JVM選項，在java命令中加入java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -version，然後調優。

3、如何指定定java cms垃圾回收

如果你的JAVA應用程序有以下幾個特點，那麼可以使用Concurrent Mark Sweep (CMS) 垃圾收集器。
希望JAVA垃圾回收器回收垃圾的時間盡可能短；
應用運行在多CPU的機器上，有足夠的CPU資源；
有比較多生命周期長的對象；
希望應用的響應時間短。

4、cms垃圾回收演算法在gc過程哪幾個階段會暫停應用線程

?

5、java虛擬機常見的幾種垃圾收集演算法

1、垃圾收集器概述
垃圾收集器是垃圾回收演算法（標記-清除演算法、復制演算法、標記-整理演算法、火車演算法）的具體實現，不同商家、不同版本的JVM所提供的垃圾收集器可能會有很在差別，本文主要介紹HotSpot虛擬機中的垃圾收集器。
1-1、垃圾收集器組合
JDK7/8後，HotSpot虛擬機所有收集器及組合（連線），如下圖：
（A）、圖中展示了7種不同分代的收集器：
Serial、ParNew、Parallel Scavenge、Serial Old、Parallel Old、CMS、G1；
（B）、而它們所處區域，則表明其是屬於新生代收集器還是老年代收集器：
新生代收集器：Serial、ParNew、Parallel Scavenge；
老年代收集器：Serial Old、Parallel Old、CMS；
整堆收集器：G1；
（C）、兩個收集器間有連線，表明它們可以搭配使用：
Serial/Serial Old、Serial/CMS、ParNew/Serial Old、ParNew/CMS、Parallel Scavenge/Serial Old、Parallel Scavenge/Parallel Old、G1；
（D）、其中Serial Old作為CMS出現"Concurrent Mode Failure"失敗的後備預案（後面介紹）；
1-2、並發垃圾收集和並行垃圾收集的區別
（A）、並行（Parallel）
指多條垃圾收集線程並行工作，但此時用戶線程仍然處於等待狀態；
如ParNew、Parallel Scavenge、Parallel Old；
（B）、並發（Concurrent）
指用戶線程與垃圾收集線程同時執行（但不一定是並行的，可能會交替執行）；
用戶程序在繼續運行，而垃圾收集程序線程運行於另一個CPU上；
如CMS、G1（也有並行）；
1-3、Minor GC和Full GC的區別
（A）、Minor GC
又稱新生代GC，指發生在新生代的垃圾收集動作；
因為Java對象大多是朝生夕滅，所以Minor GC非常頻繁，一般回收速度也比較快；
（B）、Full GC
又稱Major GC或老年代GC，指發生在老年代的GC；
出現Full GC經常會伴隨至少一次的Minor GC（不是絕對，Parallel Sacvenge收集器就可以選擇設置Major GC策略）；
Major GC速度一般比Minor GC慢10倍以上；

6、JVM的垃圾演算法有哪幾種

一、垃圾收集器概述

如上圖所示，垃圾回收演算法一共有7個，3個屬於年輕代、三個屬於年老代，G1屬於橫跨年輕代和年老代的演算法。

JVM會從年輕代和年老代各選出一個演算法進行組合，連線表示哪些演算法可以組合使用

二、各個垃圾收集器說明

1、Serial(年輕代）

年輕代收集器，可以和Serial Old、CMS組合使用

採用復制演算法

使用單線程進行垃圾回收，回收時會導致Stop The World，用戶進程停止

client模式年輕代默認演算法

GC日誌關鍵字：DefNew(Default New Generation)

圖示（Serial+Serial Old)

2、ParNew(年輕代）

新生代收集器，可以和Serial Old、CMS組合使用

採用復制演算法

使用多線程進行垃圾回收，回收時會導致Stop The World，其它策略和Serial一樣

server模式年輕代默認演算法

使用-XX:ParallelGCthreads參數來限制垃圾回收的線程數

GC日誌關鍵字：ParNew(Parallel New Generation)

圖示（ParNew + Serail Old）

3、Paralle Scavenge(年輕代）

新生代收集器，可以和Serial Old、Parallel組合使用，不能和CMS組合使用

採用復制演算法

使用多線程進行垃圾回收，回收時會導致Stop The World

關注系統吞吐量

-XX:MaxGCPauseMillis：設置大於0的毫秒數，收集器盡可能在該時間內完成垃圾回收

-XX:GCTimeRatio：大於0小於100的整數，即垃圾回收時間占總時間的比率，設置越小則希望垃圾回收所佔時間越小，CPU能花更多的時間進行系統操作，提高吞吐量

-XX:UseAdaptiveSizePolicy：參數開關，啟動後系統動態自適應調節各參數，如-Xmn、-XX：SurvivorRatio等參數，這是和ParNew收集器重要的區別

GC日誌關鍵字：PSYoungGen

4、Serial Old(年老代）

年老代收集器，可以和所有的年輕代收集器組合使用(Serial收集器的年老代版本）

採用 」標記-整理「演算法，會對垃圾回收導致的內存碎片進行整理

使用單線程進行垃圾回收，回收時會導致Stop The World，用戶進程停止

GC日誌關鍵字：Tenured

圖示（Serial+Serial Old)

5、Parallel Old(年老代）

年老代收集器，只能和Parallel Scavenge組合使用(Parallel Scavenge收集器的年老代版本）

採用 」標記-整理「演算法，會對垃圾回收導致的內存碎片進行整理

關注吞吐量的系統可以將Parallel Scavenge+Parallel Old組合使用

GC日誌關鍵字：ParOldGen

圖示(Parallel Scavenge+Parallel Old)

6、CMS(Concurrent Mark Sweep年老代）

年老代收集器，可以和Serial、ParNew組合使用

採用 」標記-清除「演算法，可以通過設置參數在垃圾回收時進行內存碎片的整理
1、：默認開啟，FullGC時進行內存碎片整理，整理時用戶進程需停止，即發生Stop The World
2、CMSFullGCsBeforeCompaction：設置執行多少次不壓縮的Full GC後，執行一個帶壓縮的（默認為0，表示每次進入Full GC時都進行碎片整理）

CMS是並發演算法，表示垃圾回收和用戶進行同時進行，但是不是所有階段都同時進行，在初始標記、重新標記階段還是需要Stop the World。CMS垃圾回收分這四個階段
1、初始標記（CMS Initial mark）  Stop the World 僅僅標記一下GC Roots能直接關聯到的對象，速度快
2、並發標記（CMS concurrent mark） 進行GC Roots Tracing，時間長，不發生用戶進程停頓
3、重新標記（CMS remark）  Stop the World 修正並發標記期間因用戶程序繼續運行導致標記變動的那一部分對象的標記記錄，停頓時間較長，但遠比並發標記時間短
4、並發清除（CMS concurrent sweep） 清除的同時用戶進程會導致新的垃圾，時間長，不發生用戶進程停頓

適合於對響應時間要求高的系統

GC日誌關鍵字：CMS-initial-mark、CMS-concurrent-mark-start、CMS-concurrent-mark、CMS-concurrent-preclean-start、CMS-concurrent-preclean、CMS-concurrent-sweep、CMS-concurrent-reset等等

缺點
1、對CPU資源非常敏感
2、CMS收集器無法處理浮動垃圾，即清除時用戶進程同時產生的垃圾，只能等到下次GC時回收
3、因為是使用「標記-清除」演算法，所以會產生大量碎片

圖示

7、G1

G1收集器由於沒有使用過，所以從網上找了一些教程供大家了解

並行與並發

分代收集

空間整合

可預測的停頓

7、jvm的理解

JVM主要就是為java程序提供一個運行環境，包括類的載入，內存的分配，垃圾的回收，JVM將內存劃分為堆，虛擬機棧，線程計數器，本地方法棧，方法區五個內存區域。

為了滿足java程序運行時的垃圾回收，jvm提供了一些垃圾回收器用於堆內存的回收，常用的垃圾收集器包括ParNew新生代垃圾收集器，cms老年代垃圾收集器，G1垃圾收集器，這些垃圾收集器根據年齡代對象的特點使用不同的垃圾回收演算法，為了解決垃圾收集時GC停頓對於Java程序的影響，使用一些參數的配置盡量減少垃圾回收時的停頓。

比如ParNew新生代垃圾收集器採用復制收集演算法，使用多線程收集，提高垃圾回收的效率，CMS採用分段收集，對於比較耗時的階段允許用戶線程並行，但隨之而來的也會導致一些缺陷，比如浮動垃圾，cpu資源緊張，內存碎片的問題，對於這些問題，可以通過JVM調優去盡量避免，比如浮動垃圾則可以減小CMS垃圾回收的老年代內存閾值。

G1垃圾收集器則採用可控的GC停頓時間來進行垃圾回收，將內存劃分為一個個小的region，邏輯上劃分出年輕代和老年代，所以G1垃圾收集器的調優主要就是對於GC停頓時間的調優，太大可能會導致每次GC停頓時間太長，太小可能導致GC發生的太頻繁。

對於JVM調優這個話題，我們主要要保證減少YGC的次數，和盡量避免Full GC，因為對老年代的回收由於存活的對象比較多，回收是比較耗時的，那麼對於這目標的實現，我們主要圍繞一個思想來做，就是盡量保證每次回收後存活的對象可以存放在s區，這些都需要對程序有一個預測和平時的JVM觀測

8、如何提高java虛擬機的垃圾收集器

Serial(串列GC)收集器
Serial收集器是一個新生代收集器，單線程執行，使用復制演算法。它在進行垃圾收集時，必須暫停其他所有的工作線程(用戶線程)。是Jvm client模式下默認的新生代收集器。對於限定單個CPU的環境來說，Serial收集器由於沒有線程交互的開銷，專心做垃圾收集自然可以獲得最高的單線程收集效率。
ParNew(並行GC)收集器
ParNew收集器其實就是serial收集器的多線程版本，除了使用多條線程進行垃圾收集之外，其餘行為與Serial收集器一樣。
Parallel Scavenge(並行回收GC)收集器
Parallel Scavenge收集器也是一個新生代收集器，它也是使用復制演算法的收集器，又是並行多線程收集器。parallel Scavenge收集器的特點是它的關注點與其他收集器不同，CMS等收集器的關注點是盡可能地縮短垃圾收集時用戶線程的停頓時間，而parallel Scavenge收集器的目標則是達到一個可控制的吞吐量。吞吐量= 程序運行時間/(程序運行時間 + 垃圾收集時間)，虛擬機總共運行了100分鍾。其中垃圾收集花掉1分鍾，那吞吐量就是99%。
Serial Old(串列GC)收集器
Serial Old是Serial收集器的老年代版本，它同樣使用一個單線程執行收集，使用「標記-整理」演算法。主要使用在Client模式下的虛擬機。
Parallel Old(並行GC)收集器
Parallel Old是Parallel Scavenge收集器的老年代版本，使用多線程和「標記-整理」演算法。