垃圾收集器Serial 、Parallel、CMS、G1
http://blog.sina.com.cn/s/blog_3f12afd00101r8w9.html
http://www.zicheng.net/article/55.htm
http://simpleframework.net/news/view?newsId=2b3d694f2a224215b5e8306aaf3ef4bd
http://simpleframework.net/news/view?newsId=1c9777c4d8e24d87ac66f0ee598e7f7a
?
? ?這里介紹4個垃圾收集器，如果進行了錯誤的選擇將會大大的影響程序的性能。
? ? 時至今日，仍然有兩個事情困擾著開發人員：垃圾收集（GC）和了解異性（程序猿的悲鳴），后者我確實不太了解，因為我被前者搞的無暇顧及怎么了解異性，特別是當知道在JAVA8中對這一區域有了很大的改進和提升還有移除了PermGen和以一些新的令人興奮的調優。
? ? 當我們談到垃圾回收時，我們絕大多數都知道利用它的概念在我們日常的編程中。但是，當問題出現時，會發現很多是我們不知道的。JVM?最大誤區之一就是它只有一個垃圾回收器，實際上是它提供了四個不同的收集器，每個都有其自身獨特的優勢和劣勢。垃圾收集器不是自動選擇的，這取決個人以及吞吐量和應用程序的差異。
這些垃圾收集的普遍存在的共同點是他們都把堆分隔成不同的片段來管理，比如在age-old區中的大多數對象應該被快速的回收。這些都是老生常談的事，我們直接進入主題來看一下各個收集器的不同以及他們的優缺點。
1.?Serial收集器
? ? Serial收集器是JAVA虛擬機中最基本、歷史最悠久的收集器，在JDK 1.3.1之前是JAVA虛擬機新生代收集的唯一選擇。Serial收集器是一個單線程的收集器，但它的“單線程”的意義并不僅僅是說明它只會使用一個CPU或一條收集線程去完成垃圾收集工作，更重要的是在它進行垃圾收集時，必須暫停其他所有的工作線程，直到它收集結束。
? ? ?Serial收集器到JDK1.7為止，它依然是JAVA虛擬機運行在Client模式下的默認新生代收集器。它也有著優于其他收集器的地方：簡單而高效（與其他收集器的單線程比），對于限定單個CPU的環境來說，Serial收集器由于沒有線程交互的開銷，專心做垃圾收集自然可以獲得最高的單線程收集效率。在用戶的桌面應用場景中，分配給虛擬機管理的內存一般來說不會很大，收集幾十兆甚至一兩百兆的新生代（僅僅是新生代使用的內存，桌面應用基本上不會再大了），停頓時間完全可以控制在幾十毫秒最多一百多毫秒以內，只要不是頻繁發生，這點停頓是可以接受的。所以，Serial收集器對于運行在Client模式下的虛擬機來說是一個很好的選擇。
PS：開啟Serial收集器的方式?-XX:+UseSerialGC
如：Xms30m -Xmx30m -Xmn10m -XX:+UseSerialGC -XX:+PrintGCDetails
-XX:+UseSerialGC的是Serial收集器，Xms30m -Xmx30m 指定了JAVA虛擬機的固定大小為30M，-Xmn10m 指JAVA新生代的空間為10M。
2. Parallel（并行）收集器
? ? 這是?JVM 的缺省收集器。就像它的名字，其最大的優點是使用多個線程來通過掃描并壓縮堆。串行收集器在GC時會停止其他所有工作線程（stop-the-world），CPU利用率是最高的，所以適用于要求高吞吐量（throughput）的應用，但停頓時間（pause time）會比較長，所以對web應用來說就不適合，因為這意味著用戶等待時間會加長。而并行收集器可以理解是多線程串行收集，在串行收集基礎上采用多線程方式進行GC，很好的彌補了串行收集的不足，可以大幅縮短停頓時間（如下圖表示的停頓時長高度，并發比并行要短），因此對于空間不大的區域（如young generation），采用并行收集器停頓時間很短，回收效率高，適合高頻率執行。
圖1.Serial收集器與Parallel/ Throughput（并行）收集器的比較
3.CMS收集器
? ? CMS（Concurrent Mark Sweep）收集器是基于“標記-清除”算法實現的，它使用多線程的算法去掃描堆（標記）并對發現的未使用的對象進行回收（清除）。整個過程分為6個步驟，包括：
初始標記（CMS initial mark）
并發標記（CMS concurrent mark）
并發預清理（CMS-concurrent-preclean）
重新標記（CMS remark）
并發清除（CMS concurrent sweep）
并發重置（CMS-concurrent-reset）
? ? 其中初始標記、重新標記這兩個步驟仍然需要“Stop The World”。初始標記僅僅只是標記一下GC Roots能直接關聯到的對象，速度很快，并發標記階段就是進行GC Roots Tracing的過程，而重新標記階段則是為了修正并發標記期間，因用戶程序繼續運作而導致標記產生變動的那一部分對象的標記記錄，這個階段的停頓時間一般會比初始標記階段稍長一些，但遠比并發標記的時間短。其他動作都是并發的。
? ? 需要注意的是，CMS收集器無法處理浮動垃圾（Floating Garbage），可能出現“Concurrent Mode Failure”失敗而導致另一次Full GC的產生。由于CMS并發清理階段用戶線程還在運行著，伴隨程序的運行自然還會有新的垃圾不斷產生，這一部分垃圾出現在標記過程之后，CMS無法在本次收集中處理掉它們，只好留待下一次GC時再將其清理掉。這一部分垃圾就稱為“浮動垃圾”。也是由于在垃圾收集階段用戶線程還需要運行，即還需要預留足夠的內存空間給用戶線程使用，因此CMS收集器不能像其他收集器那樣等到老年代幾乎完全被填滿了再進行收集，需要預留一部分空間提供并發收集時的程序運作使用。在默認設置下，CMS收集器在老年代使用了68%的空間后就會被激活，這是一個偏保守的設置，如果在應用中老年代增長不是太快，可以適當調高參數-XX:CMSInitiatingOccupancyFraction的值來提高觸發百分比，以便降低內存回收次數以獲取更好的性能。要是CMS運行期間預留的內存無法滿足程序需要，就會出現一次“Concurrent Mode Failure”失敗，這時候虛擬機將啟動后備預案：臨時啟用Serial Old收集器來重新進行老年代的垃圾收集，這樣停頓時間就很長了。所以說參數-XX:CMSInitiatingOccupancyFraction設置得太高將會很容易導致大量“Concurrent Mode Failure”失敗，性能反而降低。
? ? 還有一個缺點，CMS是一款基于“標記-清除”算法實現的收集器，這意味著收集結束時會產生大量空間碎片?？臻g碎片過多時，將會給大對象分配帶來很大的麻煩，往往會出現老年代還有很大的空間剩余，但是無法找到足夠大的連續空間來分配當前對象，不得不提前觸發一次Full GC。為了解決這個問題，CMS收集器提供了一個-XX:+UseCMSCompactAtFullCollection開關參數，用于在“享受”完Full GC服務之后額外免費附送一個碎片整理過程，內存整理的過程是無法并發的。空間碎片問題沒有了，但停頓時間不得不變長了。虛擬機設計者們還提供了另外一個參數-XX: CMSFullGCsBeforeCompaction，這個參數用于設置在執行多少次不壓縮的Full GC后，跟著來一次帶壓縮的。
? ? 該算法與并行收集器的另一個缺點是吞吐量的它使用更多的?CPU，為了使應用程序提供更好的體驗，通過使用多個線程來執行掃描和收集。這種情況長時間的運行會使應用程序停頓下來，可以使用提高空間來換取高效的運行。但是，這種算法的使用不是默認的。您必須指定?XX： + USeParNewGC來使用它。如果你可以提供更多的CPU資源的話以避免應用程序暫停，那么你可以使用CMS收集器。假設你的堆的大小小于?4 Gb你必須分配大于?4 GB的資源。
4.G1收集器
? ? G1垃圾收集器在JDK7 update 4之后對大于4G的堆有了更好的支持，G1是一個針對多處理器大容量內存的服務器端的垃圾收集器，其目標是在實現高吞吐量的同時，盡可能的滿足垃圾收集暫停時間的要求。G1在執行一些Java堆空間中的全區域操作（如：全局標記）時是和應用程序線程并發進行的，因此減少了Java堆空間的中斷比例。（譯者注：可簡單理解為減少了Stop-the-World的時間比例）。
? ? 它與前面的CMS收集器相比有兩個顯著的改進：一是G1收集器是基于“標記-整理”算法實現的收集器，也就是說它不會產生空間碎片，這對于長時間運行的應用系統來說非常重要。二是它可以非常精確地控制停頓，既能讓使用者明確指定在一個長度為M毫秒的時間片段內，消耗在垃圾收集上的時間不得超過N毫秒，具備了一些實時Java（RTSJ）的垃圾收集器的特征。
首先將Java堆空間劃分為一些大小相等的區域（region），每個區域都是虛擬機中的一段連續內存空間。G1通過執行并發的全局標記來確定整個Java堆空間中存活的對象。標記階段完成后，G1就知道哪些區域基本上是空閑的。在回收內存時優先回收這些區域，這樣通常都會回收相當數量的內存。這就是為什么它叫做Garbage-First的原因。顧名思義G1關注某些區域的回收和整理，這些區域中的對象很有可能被完全回收。而且G1使用了一個暫停時間預測模型使得暫停時間控制在用戶指定的暫停時間內，并根據用戶指定的暫停時間來選擇合適的區域回收內存。
? ? G1確定了可回收的區域后就是篩選回收（evacuation）階段了。在此階段將對象從一個或多個區域復制到單一區域，同時整理和釋放內存。該階段是在多個處理器上多個線程并行進行的，因此減少了暫停時間并提高了吞吐量。G1在每一次的垃圾收集過程中都不斷地減少碎片，并能夠將暫停時間控制在一定范圍內。這些已經是以前的垃圾收集器無法完成的了。比如：CMS收集器并不做內存整理。ParallelOld收集器只是對整個Java堆空間做整理，這樣導致相當長的暫停時間。
Java8對G1收集器的優化
? ? 在java8 udpate 20中對G1收集器采用了字符串重復消除技術（String deduplication），之前字符串以及內部的char[]數組大量消耗了內存空間，在新的G1垃圾收集器中，將會對內存中重復的字符串進行優化，使他們指向同一個字符數組，以避免相同的字符串出現而使堆處理效率低下，你可以使用?-XX:+UseStringDeduplicationJVM參數來開啟。
Java8和PermGen
? ? 在?Java?8?最大的變化之一刪除了在堆中為類的元數據、內部字符串和靜態變量分配?permgen空間的部分。過去如果加載大量的類到內存中經常會出現內存溢出異常，并且開發人員需要在這個方面做大量的工作，所以如果這段通過JVM來管理了將是一個不錯誤的優化。
?
? ? 每個垃圾收集器都有不同的配置參數，可以通過不同的參數來提升性能和降低吞吐量。這些都取決于你的應用需求，不同的對收集方式、可忍受的停頓時間、內存的大小都不一樣，所以要根據自身的需求來定制不同的配置參數。
?
此文翻譯整理于國外的文章，如果有什么建議和疑問也可以留言進行交流。
英文原文
因為G1 GC還不是默認的jvm gc策略（目前為止），需要使用的話可以加入以下參數開啟：
-XX:+UnlockExperimentalVMOptions?-XX:+UseG1GC????????#開啟
-XX:MaxGCPauseMillis?=50??????????????????#暫停時間（毫秒）
-XX:GCPauseIntervalMillis =200??????????#暫停間隔（毫秒）
-XX:+G1YoungGenSize=512m????????????#年輕代大小
-XX:SurvivorRatio=6????????????????????????????#幸存區比例
#據稱下面兩個參數可能會引發race condition，慎用。
-XX:+G1ParallelRSetUpdatingEnabled
-XX:+G1ParallelRSetScanningEnabled
JVM（一）基本概念
數據類型
Java虛擬機中，數據類型可以分為兩類：基本類型和引用類型?；绢愋偷淖兞勘４嬖贾?#xff0c;即：他代表的值就是數值本身；而引用類型的變量保存引用值。“引用值”代表了某個對象的引用，而不是對象本身，對象本身存放在這個引用值所表示的地址的位置。
基本類型包括：byte,short,int,long,char,float,double,Boolean,returnAddress
引用類型包括：類類型，接口類型和數組。
堆與棧
堆和棧是程序運行的關鍵，很有必要把他們的關系說清楚。
? ?
棧是運行時的單位，而堆是存儲的單位。
棧解決程序的運行問題，即程序如何執行，或者說如何處理數據；堆解決的是數據存儲的問題，即數據怎么放、放在哪兒。
在Java中一個線程就會相應有一個線程棧與之對應，這點很容易理解，因為不同的線程執行邏輯有所不同，因此需要一個獨立的線程棧。而堆則是所有線程共享 的。棧因為是運行單位，因此里面存儲的信息都是跟當前線程（或程序）相關信息的。包括局部變量、程序運行狀態、方法返回值等等；而堆只負責存儲對象信息。
為什么要把堆和棧區分出來呢？棧中不是也可以存儲數據嗎？
第一，從軟件設計的角度看，棧代表了處理邏輯，而堆代表了數據。這樣分開，使得處理邏輯更為清晰。分而治之的思想。這種隔離、模塊化的思想在軟件設計的方方面面都有體現。
第二，堆與棧的分離，使得堆中的內容可以被多個棧共享（也可以理解為多個線程訪問同一個對象）。這種共享的收益是很多的。一方面這種共享提供了一種有效的數據交互方式(如：共享內存)，另一方面，堆中的共享常量和緩存可以被所有棧訪問，節省了空間。
第三，棧因為運行時的需要，比如保存系統運行的上下文，需要進行地址段的劃分。由于棧只能向上增長，因此就會限制住棧存儲內容的能力。而堆不同，堆中的對象是可以根據需要動態增長的，因此棧和堆的拆分，使得動態增長成為可能，相應棧中只需記錄堆中的一個地址即可。
第四，面向對象就是堆和棧的完美結合。其實，面向對象方式的程 序與以前結構化的程序在執行上沒有任何區別。但是，面向對象的引入，使得對待問題的思考方式發生了改變，而更接近于自然方式的思考。當我們把對象拆開，你 會發現，對象的屬性其實就是數據，存放在堆中；而對象的行為（方法），就是運行邏輯，放在棧中。我們在編寫對象的時候，其實即編寫了數據結構，也編寫的處 理數據的邏輯。不得不承認，面向對象的設計，確實很美。
在Java中，Main函數就是棧的起始點，也是程序的起始點。
程序要運行總是有一個起點的。同C語言一樣，java中的Main就是那個起點。無論什么java程序，找到main就找到了程序執行的入口：）
堆中存什么？棧中存什么？
堆中存的是對象。棧中存的是基本數據類型和堆中對象的引用。一個對象的大小是不可估計的，或者說是可以動態變化的，但是在棧中，一個對象只對應了一個4btye的引用（堆棧分離的好處：））。
為什么不把基本類型放堆中呢？因為其占用的空間一般是1~8個字節——需要空間比較少，而且因為是基本類型，所以不會出現動態增長的情況——長度固定，因 此棧中存儲就夠了，如果把他存在堆中是沒有什么意義的（還會浪費空間，后面說明）。可以這么說，基本類型和對象的引用都是存放在棧中，而且都是幾個字節的 一個數，因此在程序運行時，他們的處理方式是統一的。但是基本類型、對象引用和對象本身就有所區別了，因為一個是棧中的數據一個是堆中的數據。最常見的一 個問題就是，Java中參數傳遞時的問題。
Java中的參數傳遞時傳值呢？還是傳引用？
要說明這個問題，先要明確兩點：
明確以上兩點后。Java在方法調用傳遞參數時，因為沒有指針，所以它都是進行傳值調用（這點可以參考C的傳值調用）。因此，很多書里面都說Java是進行傳值調用，這點沒有問題，而且也簡化的C中復雜性。
但是傳引用的錯覺是如何造成的呢？在運行棧中，基本類型和引用的處理是一樣的，都是傳值， 所以，如果是傳引用的方法調用，也同時可以理解為“傳引用值”的傳值調用，即引用的處理跟基本類型是完全一樣的。但是當進入被調用方法時，被傳遞的這個引 用的值，被程序解釋（或者查找）到堆中的對象，這個時候才對應到真正的對象。如果此時進行修改，修改的是引用對應的對象，而不是引用本身，即：修改的是堆 中的數據。所以這個修改是可以保持的了。
對象，從某種意義上說，是由基本類型組成的。可以把一個對象看作為一棵樹，對象的屬性如果還是對象，則還是一顆樹（即非葉子節點），基本類型則為樹的葉子節點。程序參數傳遞時，被傳遞的值本身都是不能進行修改的，但是，如果這個值是一個非葉子節點（即一個對象引用），則可以修改這個節點下面的所有內容。
堆和棧中，棧是程序運行最根本的東西。程序運行可以沒有堆，但是不能沒有棧。而堆是為棧進行數據存儲服務，說白了堆就是一塊共享的內存。不過，正是因為堆和棧的分離的思想，才使得Java的垃圾回收成為可能。
Java中，棧的大小通過-Xss來設置，當棧中存儲數據比較多時，需要適當調大這個值，否則會出現java.lang.StackOverflowError異常。常見的出現這個異常的是無法返回的遞歸，因為此時棧中保存的信息都是方法返回的記錄點。
Java對象的大小
基本數據的類型的大小是固定的，這里就不多說了。對于非基本類型的Java對象，其大小就值得商榷。
在Java中，一個空Object對象的大小是8byte，這個大小只是保存堆中一個沒有任何屬性的對象的大小。看下面語句：
| 1 | Object ob =?newObject(); |
這樣在程序中完成了一個Java對象的生命，但是它所占的空間為：4byte+8byte。4byte是上面部分所說的Java棧中保存引用的所需要的空間。而那8byte則是Java堆中對象的信息。因為所有的Java非基本類型的對象都需要默認繼承Object對象，因此不論什么樣的Java對象，其大小都必須是大于8byte。
有了Object對象的大小，我們就可以計算其他對象的大小了。
| 1234567 | Class NewObject {????intcount;????booleanflag;????Object ob;} |
其大小為：空對象大小(8byte)+int大小(4byte)+Boolean大小(1byte)+空Object引用的大小 (4byte)=17byte。但是因為Java在對對象內存分配時都是以8的整數倍來分，因此大于17byte的最接近8的整數倍的是24，因此此對象 的大小為24byte。
這里需要注意一下基本類型的包裝類型的大小。因為這種包裝類型已經成為對象了，因此需要把他們作為對象來看待。包裝類型的大小至少是12byte（聲明一個空Object至少需要的空間），而且12byte沒有包含任何有效信息，同時，因為Java對象大小是8的整數倍，因此一個基本類型包裝類的大小至少是16byte。這個內存占用是很恐怖的，它是使用基本類型的N倍（N>2），有些類型的內存占用更是夸張（隨便想下就知道了）。因此，可能的話應盡量少使用包裝類。在JDK5.0以后，因為加入了自動類型裝換，因此，Java虛擬機會在存儲方面進行相應的優化。
引用類型
對象引用類型分為強引用、軟引用、弱引用和虛引用。
強引用:就是我們一般聲明對象是時虛擬機生成的引用，強引用環境下，垃圾回收時需要嚴格判斷當前對象是否被強引用，如果被強引用，則不會被垃圾回收
軟引用:軟引用一般被做為緩存來使 用。與強引用的區別是，軟引用在垃圾回收時，虛擬機會根據當前系統的剩余內存來決定是否對軟引用進行回收。如果剩余內存比較緊張，則虛擬機會回收軟引用所 引用的空間；如果剩余內存相對富裕，則不會進行回收。換句話說，虛擬機在發生OutOfMemory時，肯定是沒有軟引用存在的。
弱引用:弱引用與軟引用類似，都是作為緩存來使用。但與軟引用不同，弱引用在進行垃圾回收時，是一定會被回收掉的，因此其生命周期只存在于一個垃圾回收周期內。
強引用不用說，我們系統一般在使用時都是用的強引用。而“軟引用”和“弱引用”比較少見。他們一般被作為緩存使用，而且一般是在內存大小比較受限的情況下 做為緩存。因為如果內存足夠大的話，可以直接使用強引用作為緩存即可，同時可控性更高。因而，他們常見的是被使用在桌面應用系統的緩存。
JVM（二）基本垃圾回收算法
可以從不同的的角度去劃分垃圾回收算法：
按照基本回收策略分
引用計數（Reference Counting）:
比較古老的回收算法。原理是此對象有一個引用，即增加一個計數，刪除一個引用則減少一個計數。垃圾回收時，只用收集計數為0的對象。此算法最致命的是無法處理循環引用的問題。
標記-清除（Mark-Sweep）:
?
此算法執行分兩階段。第一階段從引用根節點開始標記所有被引用的對象，第二階段遍歷整個堆，把未標記的對象清除。此算法需要暫停整個應用，同時，會產生內存碎片。
復制（Copying）:
此算法把內存空間劃為兩個相等的區域，每次只使用其中一個區域。垃圾回收時，遍歷當前使用區域，把正在使用中的對象復制到另外一個區域中。次算法每 次只處理正在使用中的對象，因此復制成本比較小，同時復制過去以后還能進行相應的內存整理，不會出現“碎片”問題。當然，此算法的缺點也是很明顯的，就是 需要兩倍內存空間。
標記-整理（Mark-Compact）:
此算法結合了“標記-清除”和“復制”兩個算法的優點。也是分兩階段，第一階段從根節點開始標記所有被引用對象，第二階段遍歷整個堆，把清除未標記 對象并且把存活對象“壓縮”到堆的其中一塊，按順序排放。此算法避免了“標記-清除”的碎片問題，同時也避免了“復制”算法的空間問題。
按分區對待的方式分
增量收集（Incremental Collecting）:實時垃圾回收算法，即：在應用進行的同時進行垃圾回收。不知道什么原因JDK5.0中的收集器沒有使用這種算法的。
分代收集（Generational Collecting）:基于對對象生命周期分析后得出的垃圾回收算法。把對象分為年青代、年老代、持久代，對不同生命周期的對象使用不同的算法（上述方式中的一個）進行回收?，F在的垃圾回收器（從J2SE1.2開始）都是使用此算法的。
按系統線程分
串行收集:串行收集使用單線程處理所有垃圾回收工作，因為無需多線程交互，實現容易，而且效率比較高。但是，其局限性也比較明顯，即無法使用多處理器的優勢，所以此收集適合單處理器機器。當然，此收集器也可以用在小數據量（100M左右）情況下的多處理器機器上。
并行收集:并行收集使用多線程處理垃圾回收工作，因而速度快，效率高。而且理論上CPU數目越多，越能體現出并行收集器的優勢。
并發收集:相對于串行收集和并行收集而言，前面兩個在進行垃圾回收工作時，需要暫停整個運行環境，而只有垃圾回收程序在運行，因此，系統在垃圾回收時會有明顯的暫停，而且暫停時間會因為堆越大而越長。
JVM（三）分代垃圾回收詳述
為什么要分代
分代的垃圾回收策略，是基于這樣一個事實：不同的對象的生命周期是不一樣的。因此，不同生命周期的對象可以采取不同的收集方式，以便提高回收效率。
在Java程序運行的過程中，會產生大量的對象，其中有些對象是與業務信息相關，比如Http請求中的Session對象、線程、Socket連接，這類 對象跟業務直接掛鉤，因此生命周期比較長。但是還有一些對象，主要是程序運行過程中生成的臨時變量，這些對象生命周期會比較短，比如：String對象， 由于其不變類的特性，系統會產生大量的這些對象，有些對象甚至只用一次即可回收。
試想，在不進行對象存活時間區分的情況下，每次垃圾回收都是對整個堆空間進行回收，花費時間相對會長，同時，因為每次回收都需要遍歷所有存活對象，但實際 上，對于生命周期長的對象而言，這種遍歷是沒有效果的，因為可能進行了很多次遍歷，但是他們依舊存在。因此，分代垃圾回收采用分治的思想，進行代的劃分， 把不同生命周期的對象放在不同代上，不同代上采用最適合它的垃圾回收方式進行回收。
如何分代
如圖所示：
虛擬機中的共劃分為三個代：年輕代（Young Generation）、年老點（Old Generation）和持久代（Permanent Generation）。其中持久代主要存放的是Java類的類信息，與垃圾收集要收集的Java對象關系不大。年輕代和年老代的劃分是對垃圾收集影響比較大的。
年輕代:
所有新生成的對象首先都是放在年輕代的。年輕代的目標就是盡可能快速的收集掉那些生命周期短的對象。年輕代分三個區。一個Eden區，兩個 Survivor區(一般而言)。大部分對象在Eden區中生成。當Eden區滿時，還存活的對象將被復制到Survivor區（兩個中的一個），當這個 Survivor區滿時，此區的存活對象將被復制到另外一個Survivor區，當這個Survivor去也滿了的時候，從第一個Survivor區復制 過來的并且此時還存活的對象，將被復制“年老區(Tenured)”。需要注意，Survivor的兩個區是對稱的，沒先后關系，所以同一個區中可能同時 存在從Eden復制過來 對象，和從前一個Survivor復制過來的對象，而復制到年老區的只有從第一個Survivor去過來的對象。而且，Survivor區總有一個是空 的。同時，根據程序需要，Survivor區是可以配置為多個的（多于兩個），這樣可以增加對象在年輕代中的存在時間，減少被放到年老代的可能。
年老代:
在年輕代中經歷了N次垃圾回收后仍然存活的對象，就會被放到年老代中。因此，可以認為年老代中存放的都是一些生命周期較長的對象。
持久代:
用于存放靜態文件，如今Java類、方法等。持久代對垃圾回收沒有顯著影響，但是有些應用可能動態生成或者調用一些class，例如Hibernate 等，在這種時候需要設置一個比較大的持久代空間來存放這些運行過程中新增的類。持久代大小通過-XX:MaxPermSize=<N>進行設 置。
什么情況下觸發垃圾回收
由于對象進行了分代處理，因此垃圾回收區域、時間也不一樣。GC有兩種類型：Scavenge GC和Full GC。
Scavenge GC
一般情況下，當新對象生成，并且在Eden申請空間失敗時，就會觸發Scavenge GC，對Eden區域進行GC，清除非存活對象，并且把尚且存活的對象移動到Survivor區。然后整理Survivor的兩個區。這種方式的GC是對 年輕代的Eden區進行，不會影響到年老代。因為大部分對象都是從Eden區開始的，同時Eden區不會分配的很大，所以Eden區的GC會頻繁進行。因 而，一般在這里需要使用速度快、效率高的算法，使Eden去能盡快空閑出來。
Full GC
對整個堆進行整理，包括Young、Tenured和Perm。Full GC因為需要對整個對進行回收，所以比Scavenge GC要慢，因此應該盡可能減少Full GC的次數。在對JVM調優的過程中，很大一部分工作就是對于FullGC的調節。有如下原因可能導致Full GC：
- 年老代（Tenured）被寫滿
- 持久代（Perm）被寫滿?
- System.gc()被顯示調用?
- 上一次GC之后Heap的各域分配策略動態變化
分代垃圾回收流程示意
?
?
?
選擇合適的垃圾收集算法
串行收集器
用單線程處理所有垃圾回收工作，因為無需多線程交互，所以效率比較高。但是，也無法使用多處理器的優勢，所以此收集器適合單處理器機器。當然，此收集器也可以用在小數據量（100M左右）情況下的多處理器機器上?？梢允褂?XX:+UseSerialGC打開。
并行收集器
對年輕代進行并行垃圾回收，因此可以減少垃圾回收時間。一般在多線程多處理器機器上使用。使用-XX:+UseParallelGC.打開。并行收 集器在J2SE5.0第六6更新上引入，在Java SE6.0中進行了增強–可以對年老代進行并行收集。如果年老代不使用并發收集的話，默認是使用單線程進行垃圾回收，因此會制約擴展能力。使用 -XX:+UseParallelOldGC打開。
使用-XX:ParallelGCThreads=<N>設置并行垃圾回收的線程數。此值可以設置與機器處理器數量相等。
此收集器可以進行如下配置：
最大垃圾回收暫停:指定垃圾回收時的最長暫停時間，通過-XX:MaxGCPauseMillis=<N>指定。<N>為毫秒.如果指定了此值的話，堆大小和垃圾回收相關參數會進行調整以達到指定值。設定此值可能會減少應用的吞吐量。
吞吐量:吞吐量為垃圾回收時間與非垃圾回收時間的比值，通過-XX:GCTimeRatio=<N>來設定，公式為1/（1+N）。例如，-XX:GCTimeRatio=19時，表示5%的時間用于垃圾回收。默認情況為99，即1%的時間用于垃圾回收。
并發收集器
可以保證大部分工作都并發進行（應用不停止），垃圾回收只暫停很少的時間，此收集器適合對響應時間要求比較高的中、大規模應用。使用-XX:+UseConcMarkSweepGC打開。
并發收集器主要減少年老代的暫停時間，他在應用不停止的情況下使用獨立的垃圾回收線程，跟蹤可達對象。在每個年老代垃圾回收周期中，在收集初期并發收集器 會對整個應用進行簡短的暫停，在收集中還會再暫停一次。第二次暫停會比第一次稍長，在此過程中多個線程同時進行垃圾回收工作。
并發收集器使用處理器換來短暫的停頓時間。在一個N個處理器的系統上，并發收集部分使用K/N個可用處理器進行回收，一般情況下1<=K<=N/4。
在只有一個處理器的主機上使用并發收集器，設置為incremental mode模式也可獲得較短的停頓時間。
浮動垃圾：由于在應用運行的同時進行垃圾回收，所以有些垃圾可能在垃圾回收進行完成時產生，這樣就造成了“Floating Garbage”，這些垃圾需要在下次垃圾回收周期時才能回收掉。所以，并發收集器一般需要20%的預留空間用于這些浮動垃圾。
Concurrent Mode Failure：并發收集器在應用運行時進行收集，所以需要保證堆在垃圾回收的這段時間有足夠的空間供程序使用，否則，垃圾回收還未完成，堆空間先滿了。這種情況下將會發生“并發模式失敗”，此時整個應用將會暫停，進行垃圾回收。
啟動并發收集器：因為并發收集在應用運行時進行收集，所以必須保證收集完成之前有足夠的內存空間供程序 使用，否則會出現“Concurrent Mode Failure”。通過設置-XX:CMSInitiatingOccupancyFraction=<N>指定還有多少剩余堆時開始執行并 發收集
小結
串行處理器：
–適用情況：數據量比較小（100M左右）；單處理器下并且對響應時間無要求的應用。
–缺點：只能用于小型應用
并行處理器：
–適用情況：“對吞吐量有高要求”，多CPU、對應用響應時間無要求的中、大型應用。舉例：后臺處理、科學計算。
–缺點：垃圾收集過程中應用響應時間可能加長
并發處理器：
–適用情況：“對響應時間有高要求”，多CPU、對應用響應時間有較高要求的中、大型應用。舉例：Web服務器/應用服務器、電信交換、集成開發環境。
JVM（四）新一代的垃圾回收算法G1
垃圾回收的瓶頸
傳統分代垃圾回收方式，已經在一定程度上把垃圾回收給應用帶來的負擔降到了最小，把應用的吞吐量推到了一個極限。但是他無法解決的一個問題，就是Full GC所帶來的應用暫停。在一些對實時性要求很高的應用場景下，GC暫停所帶來的請求堆積和請求失敗是無法接受的。這類應用可能要求請求的返回時間在幾百甚 至幾十毫秒以內，如果分代垃圾回收方式要達到這個指標，只能把最大堆的設置限制在一個相對較小范圍內，但是這樣有限制了應用本身的處理能力，同樣也是不可 接收的。
分代垃圾回收方式確實也考慮了實時性要求而提供了并發回收器，支持最大暫停時間的設置，但是受限于分代垃圾回收的內存劃分模型，其效果也不是很理想。
為了達到實時性的要求（其實Java語言最初的設計也是在嵌入式系統上的），一種新垃圾回收方式呼之欲出，它既支持短的暫停時間，又支持大的內存空間分配?？梢院芎玫慕鉀Q傳統分代方式帶來的問題。
增量收集的演進
增量收集的方式在理論上可以解決傳統分代方式帶來的問題。增量收集把對堆空間劃分成一系列內存塊，使用時，先使用其中一部分（不會全部用完），垃圾收集時 把之前用掉的部分中的存活對象再放到后面沒有用的空間中，這樣可以實現一直邊使用邊收集的效果，避免了傳統分代方式整個使用完了再暫停的回收的情況。
當然，傳統分代收集方式也提供了并發收集，但是他有一個很致命的地方，就是把整個堆做為一個內存塊，這樣一方面會造成碎片（無法壓縮），另一方面他的每次 收集都是對整個堆的收集，無法進行選擇，在暫停時間的控制上還是很弱。而增量方式，通過內存空間的分塊，恰恰可以解決上面問題。
Garbage First（G1）
這部分的內容主要參考這里，這篇文章算是對G1算法論文的解讀。我也沒加什么東西了。
目標
從設計目標看G1完全是為了大型應用而準備的。
支持很大的堆
高吞吐量
? –支持多CPU和垃圾回收線程
? –在主線程暫停的情況下，使用并行收集
? –在主線程運行的情況下，使用并發收集
實時目標：可配置在N毫秒內最多只占用M毫秒的時間進行垃圾回收
當然G1要達到實時性的要求，相對傳統的分代回收算法，在性能上會有一些損失。
算法詳解
G1可謂博采眾家之長，力求到達一種完美。他吸取了增量收集優點，把整個堆劃分為一個一個等大小的區域（region）。內存的回收和劃分都以 region為單位；同時，他也吸取了CMS的特點，把這個垃圾回收過程分為幾個階段，分散一個垃圾回收過程；而且，G1也認同分代垃圾回收的思想，認為 不同對象的生命周期不同，可以采取不同收集方式，因此，它也支持分代的垃圾回收。為了達到對回收時間的可預計性，G1在掃描了region以后，對其中的 活躍對象的大小進行排序，首先會收集那些活躍對象小的region，以便快速回收空間（要復制的活躍對象少了），因為活躍對象小，里面可以認為多數都是垃 圾，所以這種方式被稱為Garbage First（G1）的垃圾回收算法，即：垃圾優先的回收。
回收步驟：
初始標記（Initial Marking）
G1對于每個region都保存了兩個標識用的bitmap，一個為previous marking bitmap，一個為next marking bitmap，bitmap中包含了一個bit的地址信息來指向對象的起始點。
開始Initial Marking之前，首先并發的清空next marking bitmap，然后停止所有應用線程，并掃描標識出每個region中root可直接訪問到的對象，將region中top的值放入next top at mark start（TAMS）中，之后恢復所有應用線程。
觸發這個步驟執行的條件為：
G1定義了一個JVM Heap大小的百分比的閥值，稱為h，另外還有一個H，H的值為(1-h)*Heap Size，目前這個h的值是固定的，后續G1也許會將其改為動態的，根據jvm的運行情況來動態的調整，在分代方式下，G1還定義了一個u以及soft limit，soft limit的值為H-u*Heap Size，當Heap中使用的內存超過了soft limit值時，就會在一次clean up執行完畢后在應用允許的GC暫停時間范圍內盡快的執行此步驟；
在pure方式下，G1將marking與clean up組成一個環，以便clean up能充分的使用marking的信息，當clean up開始回收時，首先回收能夠帶來最多內存空間的regions，當經過多次的clean up，回收到沒多少空間的regions時，G1重新初始化一個新的marking與clean up構成的環。
并發標記（Concurrent Marking）
按照之前Initial Marking掃描到的對象進行遍歷，以識別這些對象的下層對象的活躍狀態，對于在此期間應用線程并發修改的對象的以來關系則記錄到remembered set logs中，新創建的對象則放入比top值更高的地址區間中，這些新創建的對象默認狀態即為活躍的，同時修改top值。
最終標記暫停（Final Marking Pause）
當應用線程的remembered set logs未滿時，是不會放入filled RS buffers中的，在這樣的情況下，這些remebered set logs中記錄的card的修改就會被更新了，因此需要這一步，這一步要做的就是把應用線程中存在的remembered set logs的內容進行處理，并相應的修改remembered sets，這一步需要暫停應用，并行的運行。
存活對象計算及清除（Live Data Counting and Cleanup）
值得注意的是，在G1中，并不是說Final Marking Pause執行完了，就肯定執行Cleanup這步的，由于這步需要暫停應用，G1為了能夠達到準實時的要求，需要根據用戶指定的最大的GC造成的暫停時 間來合理的規劃什么時候執行Cleanup，另外還有幾種情況也是會觸發這個步驟的執行的：
G1采用的是復制方法來進行收集，必須保證每次的”to space”的空間都是夠的，因此G1采取的策略是當已經使用的內存空間達到了H時，就執行Cleanup這個步驟；
對于full-young和partially-young的分代模式的G1而言，則還有情況會觸發Cleanup的執行，full-young模式 下，G1根據應用可接受的暫停時間、回收young regions需要消耗的時間來估算出一個yound regions的數量值，當JVM中分配對象的young regions的數量達到此值時，Cleanup就會執行；partially-young模式下，則會盡量頻繁的在應用可接受的暫停時間范圍內執行 Cleanup，并最大限度的去執行non-young regions的Cleanup。
JVM 中最大堆大小有三方面限制：相關操作系統的數據模型（32-bt還是64-bit）限制；系統的可用虛擬內存限制；系統的可用物理內存限制。32位系統下，一般限制在1.5G~2G；64為操作系統對內存無限制。我在Windows Server 2003 系統，3.5G物理內存，JDK5.0下測試，最大可設置為1478m。
典型設置：
- java?-Xmx3550m -Xms3550m -Xmn2g?-Xss128k
-Xmx3550m：設置JVM最大可用內存為3550M。
-Xms3550m：設置JVM促使內存為3550m。此值可以設置與-Xmx相同，以避免每次垃圾回收完成后JVM重新分配內存。
-Xmn2g：設置年輕代大小為2G。整個JVM內存大小=年輕代大小 + 年老代大小 + 持久代大小。持久代一般固定大小為64m，所以增大年輕代后，將會減小年老代大小。此值對系統性能影響較大，Sun官方推薦配置為整個堆的3/8。
-Xss128k：設置每個線程的堆棧大小。JDK5.0以后每個線程堆棧大小為1M，以前每個線程堆棧大小為256K。更具應用的線程所需內存大小進行調整。在相同物理內存下，減小這個值能生成更多的線程。但是操作系統對一個進程內的線程數還是有限制的，不能無限生成，經驗值在3000~5000左右。 - java -Xmx3550m -Xms3550m -Xss128k?-XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxPermSize=16m -XX:MaxTenuringThreshold=0
-XX:NewRatio=4:設置年輕代（包括Eden和兩個Survivor區）與年老代的比值（除去持久代）。設置為4，則年輕代與年老代所占比值為1：4，年輕代占整個堆棧的1/5
-XX:SurvivorRatio=4：設置年輕代中Eden區與Survivor區的大小比值。設置為4，則兩個Survivor區與一個Eden區的比值為2:4，一個Survivor區占整個年輕代的1/6
-XX:MaxPermSize=16m:設置持久代大小為16m。
-XX:MaxTenuringThreshold=0：設置垃圾最大年齡。如果設置為0的話，則年輕代對象不經過Survivor區，直接進入年老代。對于年老代比較多的應用，可以提高效率。如果將此值設置為一個較大值，則年輕代對象會在Survivor區進行多次復制，這樣可以增加對象再年輕代的存活時間，增加在年輕代即被回收的概論。
JVM給了三種選擇：串行收集器、并行收集器、并發收集器，但是串行收集器只適用于小數據量的情況，所以這里的選擇主要針對并行收集器和并發收集器。默認情況下，JDK5.0以前都是使用串行收集器，如果想使用其他收集器需要在啟動時加入相應參數。JDK5.0以后，JVM會根據當前系統配置進行判斷。
如上文所述，并行收集器主要以到達一定的吞吐量為目標，適用于科學技術和后臺處理等。
典型配置：
- java -Xmx3800m -Xms3800m -Xmn2g -Xss128k?-XX:+UseParallelGC -XX:ParallelGCThreads=20
-XX:+UseParallelGC：選擇垃圾收集器為并行收集器。此配置僅對年輕代有效。即上述配置下，年輕代使用并發收集，而年老代仍舊使用串行收集。
-XX:ParallelGCThreads=20：配置并行收集器的線程數，即：同時多少個線程一起進行垃圾回收。此值最好配置與處理器數目相等。 - java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20?-XX:+UseParallelOldGC
-XX:+UseParallelOldGC：配置年老代垃圾收集方式為并行收集。JDK6.0支持對年老代并行收集。 - java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC??-XX:MaxGCPauseMillis=100
-XX:MaxGCPauseMillis=100:設置每次年輕代垃圾回收的最長時間，如果無法滿足此時間，JVM會自動調整年輕代大小，以滿足此值。 - java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC? -XX:MaxGCPauseMillis=100?-XX:+UseAdaptiveSizePolicy
-XX:+UseAdaptiveSizePolicy：設置此選項后，并行收集器會自動選擇年輕代區大小和相應的Survivor區比例，以達到目標系統規定的最低相應時間或者收集頻率等，此值建議使用并行收集器時，一直打開。
如上文所述，并發收集器主要是保證系統的響應時間，減少垃圾收集時的停頓時間。適用于應用服務器、電信領域等。
典型配置：
- java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:ParallelGCThreads=20?-XX:+UseConcMarkSweepGC -XX:+UseParNewGC
-XX:+UseConcMarkSweepGC：設置年老代為并發收集。測試中配置這個以后，-XX:NewRatio=4的配置失效了，原因不明。所以，此時年輕代大小最好用-Xmn設置。
-XX:+UseParNewGC:設置年輕代為并行收集?？膳cCMS收集同時使用。JDK5.0以上，JVM會根據系統配置自行設置，所以無需再設置此值。 - java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseConcMarkSweepGC?-XX:CMSFullGCsBeforeCompaction=5?-XX:+UseCMSCompactAtFullCollection
-XX:CMSFullGCsBeforeCompaction：由于并發收集器不對內存空間進行壓縮、整理，所以運行一段時間以后會產生“碎片”，使得運行效率降低。此值設置運行多少次GC以后對內存空間進行壓縮、整理。
-XX:+UseCMSCompactAtFullCollection：打開對年老代的壓縮?？赡軙绊懶阅?#xff0c;但是可以消除碎片
JVM提供了大量命令行參數，打印信息，供調試使用。主要有以下一些：
- -XX:+PrintGC
輸出形式：[GC 118250K->113543K(130112K), 0.0094143 secs]??????????????? [Full GC 121376K->10414K(130112K), 0.0650971 secs]
- -XX:+PrintGCDetails
輸出形式：[GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs]??????????????? [GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured: 112761K->10414K(121024K), 0.0433488 secs] 121376K->10414K(130112K), 0.0436268 secs]
- -XX:+PrintGCTimeStamps?-XX:+PrintGC：PrintGCTimeStamps可與上面兩個混合使用
輸出形式：11.851: [GC 98328K->93620K(130112K), 0.0082960 secs] - -XX:+PrintGCApplicationConcurrentTime:打印每次垃圾回收前，程序未中斷的執行時間?？膳c上面混合使用
輸出形式：Application time: 0.5291524 seconds - -XX:+PrintGCApplicationStoppedTime：打印垃圾回收期間程序暫停的時間?？膳c上面混合使用
輸出形式：Total time for which application threads were stopped: 0.0468229 seconds - -XX:PrintHeapAtGC:打印GC前后的詳細堆棧信息
輸出形式：
34.702: [GC {Heap before gc invocations=7:
?def new generation?? total 55296K, used 52568K [0x1ebd0000, 0x227d0000, 0x227d0000)
eden space 49152K,? 99% used?[0x1ebd0000, 0x21bce430, 0x21bd0000)
from space 6144K,? 55% used?[0x221d0000, 0x22527e10, 0x227d0000)
? to?? space 6144K,?? 0% used [0x21bd0000, 0x21bd0000, 0x221d0000)
?tenured generation?? total 69632K, used 2696K [0x227d0000, 0x26bd0000, 0x26bd0000)
the space 69632K,?? 3% used?[0x227d0000, 0x22a720f8, 0x22a72200, 0x26bd0000)
?compacting perm gen? total 8192K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)
?? the space 8192K,? 35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)
??? ro space 8192K,? 66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)
??? rw space 12288K,? 46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)
34.735: [DefNew: 52568K->3433K(55296K), 0.0072126 secs] 55264K->6615K(124928K)Heap after gc invocations=8:
?def new generation?? total 55296K, used 3433K [0x1ebd0000, 0x227d0000, 0x227d0000)
eden space 49152K,?? 0% used?[0x1ebd0000, 0x1ebd0000, 0x21bd0000)
? from space 6144K,? 55% used [0x21bd0000, 0x21f2a5e8, 0x221d0000)
? to?? space 6144K,?? 0% used [0x221d0000, 0x221d0000, 0x227d0000)
?tenured generation?? total 69632K, used 3182K [0x227d0000, 0x26bd0000, 0x26bd0000)
the space 69632K,?? 4% used?[0x227d0000, 0x22aeb958, 0x22aeba00, 0x26bd0000)
?compacting perm gen? total 8192K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)
?? the space 8192K,? 35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)
??? ro space 8192K,? 66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)
??? rw space 12288K,? 46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)
}
, 0.0757599 secs] - -Xloggc:filename:與上面幾個配合使用，把相關日志信息記錄到文件以便分析。
- -Xms:初始堆大小
- -Xmx:最大堆大小
- -XX:NewSize=n:設置年輕代大小
- -XX:NewRatio=n:設置年輕代和年老代的比值。如:為3，表示年輕代與年老代比值為1：3，年輕代占整個年輕代年老代和的1/4
- -XX:SurvivorRatio=n:年輕代中Eden區與兩個Survivor區的比值。注意Survivor區有兩個。如：3，表示Eden：Survivor=3：2，一個Survivor區占整個年輕代的1/5
- -XX:MaxPermSize=n:設置持久代大小
- -XX:+UseSerialGC:設置串行收集器
- -XX:+UseParallelGC:設置并行收集器
- -XX:+UseParalledlOldGC:設置并行年老代收集器
- -XX:+UseConcMarkSweepGC:設置并發收集器
- -XX:+PrintGC
- -XX:+PrintGCDetails
- -XX:+PrintGCTimeStamps
- -Xloggc:filename
- -XX:ParallelGCThreads=n:設置并行收集器收集時使用的CPU數。并行收集線程數。
- -XX:MaxGCPauseMillis=n:設置并行收集最大暫停時間
- -XX:GCTimeRatio=n:設置垃圾回收時間占程序運行時間的百分比。公式為1/(1+n)
- -XX:+CMSIncrementalMode:設置為增量模式。適用于單CPU情況。
- -XX:ParallelGCThreads=n:設置并發收集器年輕代收集方式為并行收集時，使用的CPU數。并行收集線程數。
四、調優總結
- 響應時間優先的應用：盡可能設大，直到接近系統的最低響應時間限制（根據實際情況選擇）。在此種情況下，年輕代收集發生的頻率也是最小的。同時，減少到達年老代的對象。
- 吞吐量優先的應用：盡可能的設置大，可能到達Gbit的程度。因為對響應時間沒有要求，垃圾收集可以并行進行，一般適合8CPU以上的應用。
- 響應時間優先的應用：年老代使用并發收集器，所以其大小需要小心設置，一般要考慮并發會話率和會話持續時間等一些參數。如果堆設置小了，可以會造成內存碎片、高回收頻率以及應用暫停而使用傳統的標記清除方式；如果堆大了，則需要較長的收集時間。最優化的方案，一般需要參考以下數據獲得：
- 并發垃圾收集信息
- 持久代并發收集次數
- 傳統GC信息
- 花在年輕代和年老代回收上的時間比例
- 吞吐量優先的應用：一般吞吐量優先的應用都有一個很大的年輕代和一個較小的年老代。原因是，這樣可以盡可能回收掉大部分短期對象，減少中期的對象，而年老代盡存放長期存活對象。
因為年老代的并發收集器使用標記、清除算法，所以不會對堆進行壓縮。當收集器回收時，他會把相鄰的空間進行合并，這樣可以分配給較大的對象。但是，當堆空間較小時，運行一段時間以后，就會出現“碎片”，如果并發收集器找不到足夠的空間，那么并發收集器將會停止，然后使用傳統的標記、清除方式進行回收。如果出現“碎片”，可能需要進行如下配置：
- -XX:+UseCMSCompactAtFullCollection：使用并發收集器時，開啟對年老代的壓縮。
- -XX:CMSFullGCsBeforeCompaction=0：上面配置開啟的情況下，這里設置多少次Full GC后，對年老代進行壓縮
總結
以上是生活随笔為你收集整理的垃圾收集器Serial 、Parallel、CMS、G1的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Java 堆内存模型
- 下一篇： JVM实用参数（一）JVM类型以及编译器