JVM垃圾回收--年輕代、年老點和持久代

 

 

 

關鍵字約定html

 

  • Young generation –>新生代
  • Tenured / Old Generation –>老年代
  • Perm Area –>永久代

 

年輕代:java

  全部新生成的對象首先都是放在年輕代的。年輕代的目標就是儘量快速的收集掉那些生命週期短的對象。年輕代分三個區。一個Eden區,兩個 Survivor區(通常而言)。大部分對象在Eden區中生成。當Eden區滿時,還存活的對象將被複制到Survivor區(兩個中的一個),當這個 Survivor區滿時,此區的存活對象將被複制到另一個Survivor區,當這個Survivor去也滿了的時候,從第一個Survivor區複製過來的而且此時還存活的對象,將被複制「年老區(Tenured)」。須要注意,Survivor的兩個區是對稱的,沒前後關係,因此同一個區中可能同時存在從Eden複製過來對象,和從前一個Survivor複製過來的對象,而複製到年老區的只有從第一個Survivor去過來的對象。並且,Survivor區總有一個是空的。同時,根據程序須要,Survivor區是能夠配置爲多個的(多於兩個),這樣能夠增長對象在年輕代中的存在時間,減小被放到年老代的可能。mysql

  年老代:程序員

  在年輕代中經歷了N次垃圾回收後仍然存活的對象,就會被放到年老代中。所以,能夠認爲年老代中存放的都是一些生命週期較長的對象。算法

  持久代:sql

  用於存放靜態文件,現在Java類、方法等。持久代對垃圾回收沒有顯著影響,可是有些應用可能動態生成或者調用一些class,例如Hibernate 等,在這種時候須要設置一個比較大的持久代空間來存放這些運行過程當中新增的類。持久代大小經過-XX:MaxPermSize=<N>進行設置。數組


重要的東東

  • 在Java中,對象實例都是在堆上建立。一些類信息,常量,靜態變量等存儲在方法區。堆和方法區都是線程共享的。
  • GC機制是由JVM提供,用來清理須要清除的對象,回收堆內存。
  • GC機制將Java程序員從內存管理中解放了出來,能夠更關注於業務邏輯。
  • 在Java中,GC是由一個被稱爲垃圾回收器的守護線程執行的。
  • 在從內存回收一個對象以前會調用對象的finalize()方法。
  • 做爲一個Java開發者不能強制JVM執行GC;GC的觸發由JVM依據堆內存的大小來決定。
  • System.gc()和Runtime.gc()會向JVM發送執行GC的請求,可是JVM不保證必定會執行GC。
  • 若是堆沒有內存建立新的對象了,會拋出OutOfMemoryError

GC針對什麼對象?

 

瞭解GC機制的第一步就是理解什麼樣的對象會被回收。當一個對象經過一系列根對象(好比:靜態屬性引用的常量)都不可達時就會被回收。簡而言之,當一個對象的全部引用都爲null。循環依賴不算作引用,若是對象A有一個指向對象B的引用,對象B也有一個指向對象A的引用,除此以外,它們沒有其餘引用,那麼對象A和對象B都、須要被回收(以下圖,ObjA和ObjB須要被回收)。
GC回收對象GC回收對象多線程

堆內存是如何劃分的?

Java中對象都在堆上建立。爲了GC,堆內存分爲三個部分,也能夠說三代,分別稱爲新生代,老年代和永久代。其中新生代又進一步分爲Eden區,Survivor 1區和Survivor 2區(以下圖)。新建立的對象會分配在Eden區,在經歷一次Minor GC後會被移到Survivor 1區,再經歷一次Minor GC後會被移到Survivor 2區,直到升至老年代,須要注意的是,一些大對象(長字符串或數組)可能會直接存放到老年代。
堆內存堆內存
永久代有一些特殊,它用來存儲類的元信息。對於GC是否發生在永久代有許多不一樣的見解,在我看來這取決於採用的JVM。你們能夠經過建立大量的字符串來觀察是發生了GC仍是拋出了OutOfMemoryError。
併發

GC算法

  1. 標記清除算法
    分爲標記和清除兩個階段:首先標記出全部須要回收的對象,在標記完成後統一回收全部被標記的對象。該算法的缺點是效率不高而且會產生不連續的內存碎片。
    imageimage
  2. 複製算法
    把內存空間劃爲兩個區域,每次只使用其中一個區域。垃圾回收時,遍歷當前使用區域,把正在使用中的對象複製到另一個區域中。次算法每次只處理正在使用中的對象,所以複製成本比較小,同時複製過去之後還能進行相應的內存整理,不會出現「碎片」問題。優勢:實現簡單,運行高效。缺點:會浪費必定的內存。通常新生代採用這種算法。
    imageimage
  3. 標記整理算法
    標記階段與標記清除算法同樣。但後續並非直接對可回收的對象進行清理,而是讓全部存活對象都想一端移動,而後清理。優勢是不會形成內存碎片。
    imageimage

Java中垃圾回收器的類型

Java提供多種類型的垃圾回收器。JVM中的垃圾收集通常都採用「分代收集」,不一樣的堆內存區域採用不一樣的收集算法,主要目的就是爲了增長吞吐量或下降停頓時間。oracle

  • Serial收集器:新生代收集器,使用複製算法,使用一個線程進行GC,串行,其它工做線程暫停。
  • ParNew收集器:新生代收集器,使用複製算法,Serial收集器的多線程版,用多個線程進行GC,並行,其它工做線程暫停。使用-XX:+UseParNewGC開關來控制使用ParNew+Serial Old收集器組合收集內存;使用-XX:ParallelGCThreads來設置執行內存回收的線程數。
  • Parallel Scavenge 收集器:吞吐量優先的垃圾回收器,做用在新生代,使用複製算法,關注CPU吞吐量,即運行用戶代碼的時間/總時間。使用-XX:+UseParallelGC開關控制使用Parallel Scavenge+Serial Old收集器組合回收垃圾。
  • Serial Old收集器:老年代收集器,單線程收集器,串行,使用標記整理算法,使用單線程進行GC,其它工做線程暫停。
  • Parallel Old收集器:吞吐量優先的垃圾回收器,做用在老年代,多線程,並行,多線程機制與Parallel Scavenge差不錯,使用標記整理算法,在Parallel Old執行時,仍然須要暫停其它線程。
  • CMS(Concurrent Mark Sweep)收集器:老年代收集器,致力於獲取最短回收停頓時間(即縮短垃圾回收的時間),使用標記清除算法,多線程,優勢是併發收集(用戶線程能夠和GC線程同時工做),停頓小。使用-XX:+UseConcMarkSweepGC進行ParNew+CMS+Serial Old進行內存回收,優先使用ParNew+CMS(緣由見Full GC和併發垃圾回收一節),當用戶線程內存不足時,採用備用方案Serial Old收集。

能夠看Java Performance一書來獲取更多關於GC調優的信息。

與GC有關的JVM參數

作GC調優須要大量的實踐,耐心和對項目的分析。我曾經參與太高容量,低延遲的電商系統,在開發中咱們須要經過分析形成Full GC的緣由來提升系統性能,在這個過程當中我發現作GC的調優很大程度上依賴於對系統的分析,系統擁有怎樣的對象以及他們的平均生命週期。
舉個例子,若是一個應用大可能是短生命週期的對象,那麼應該確保Eden區足夠大,這樣能夠減小Minor GC的次數。能夠經過-XX:NewRatio來控制新生代和老年代的比例,好比-XX:NewRatio=3表明新生代和老年代的比例爲1:3。須要注意的是,擴大新生代的大小會減小老年代的大小,這會致使Major GC執行的更頻繁,而Major GC可能會形成用戶線程的停頓從而下降系統吞吐量。JVM中能夠用NewSize和MaxNewSize參數來指定新生代內存最小和最大值,若是兩個參數值同樣,那麼就至關於固定了新生代的大小。
我的建議,在作GC調優以前最好深刻理解Java中GC機制,推薦閱讀Sun Microsystems提供的有關GC的文檔。這個連接可能會對理解GC機制提供一些幫助。下面的圖列出了各個區可用的一些JVM參數。
jvm參數jvm參數

Full GC和併發垃圾回收

併發垃圾回收器的內存回收過程是與用戶線程一塊兒併發執行的。一般狀況下,併發垃圾回收器能夠在用戶線程運行的狀況下完成大部分的回收工做,因此應用停頓時間很短。
但因爲併發垃圾回收時用戶線程還在運行,因此會有新的垃圾不斷產生。做爲擔保,若是在老年代內存都被佔用以前,若是併發垃圾回收器還沒結束工做,那麼應用會暫停,在全部用戶線程中止的狀況下完成回收。這種狀況稱做Full GC,這意味着須要調整有關併發回收的參數了。
因爲Full GC很影響應用的性能,要儘可能避免或減小。特別是若是對於高容量低延遲的電商系統,要儘可能避免在交易時間段發生Full GC。

總結

  • 爲了分代垃圾回收,Java堆內存分爲3代:新生代,老年代和永久代。
  • 新的對象實例會優先分配在新生代,在經歷幾回Minor GC後(默認15次),還存活的會被移至老年代(某些大對象會直接在老年代分配)。
  • 永久代是否執行GC,取決於採用的JVM。
  • Minor GC發生在新生代,當Eden區沒有足夠空間時,會發起一次Minor GC,將Eden區中的存活對象移至Survivor區。Major GC發生在老年代,當升到老年代的對象大於老年代剩餘空間時會發生Major GC。
  • 發生Major GC時用戶線程會暫停,會下降系統性能和吞吐量。
  • JVM的參數-Xmx和-Xms用來設置Java堆內存的初始大小和最大值。依據我的經驗這個值的比例最好是1:1或者1:1.5。好比,你能夠將-Xmx和-Xms都設爲1GB,或者-Xmx和-Xms設爲1.2GB和1.8GB。
  • Java中不能手動觸發GC,但能夠用不一樣的引用類來輔助垃圾回收器工做(好比:弱引用或軟引用)。

以上就是關於Java中GC的一些內容。經過這篇博客,咱們能夠知道堆內存是如何劃分的;一個對象在沒有任何強引用指向他或該對象經過根節點不可達時須要被垃圾回收器回收;當垃圾收集器意識到須要進行GC時會觸發Minor GC或Major GC,是自動的,沒法強制執行。

 

經常使用的收集器組合

  新生代GC策略 老年老代GC策略 說明
組合1 Serial Serial Old Serial和Serial Old都是單線程進行GC,特色就是GC時暫停全部應用線程。
組合2 Serial CMS+Serial Old CMS(Concurrent Mark Sweep)是併發GC,實現GC線程和應用線程併發工做,不須要暫停全部應用線程。另外,當CMS進行GC失敗時,會自動使用Serial Old策略進行GC。
組合3 ParNew CMS 使用 -XX:+UseParNewGC選項來開啓。ParNew是Serial的並行版本,能夠指定GC線程數,默認GC線程數爲CPU的數量。可使用-XX:ParallelGCThreads選項指定GC的線程數。若是指定了選項 -XX:+UseConcMarkSweepGC選項,則新生代默認使用ParNew GC策略。
組合4 ParNew Serial Old 使用 -XX:+UseParNewGC選項來開啓。新生代使用ParNew GC策略,年老代默認使用Serial Old GC策略。
組合5 Parallel Scavenge Serial Old Parallel Scavenge策略主要是關注一個可控的吞吐量:應用程序運行時間 / (應用程序運行時間 + GC時間),可見這會使得CPU的利用率儘量的高,適用於後臺持久運行的應用程序,而不適用於交互較多的應用程序。
組合6 Parallel Scavenge Parallel Old Parallel Old是Serial Old的並行版本
組合7 G1GC G1GC -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC #開啓; -XX:MaxGCPauseMillis=50 #暫停時間目標; -XX:GCPauseIntervalMillis=200 #暫停間隔目標; -XX:+G1YoungGenSize=512m #年輕代大小; -XX:SurvivorRatio=6 #倖存區比例

 

 

垃圾收集算法

標記 -清除算法

「標記-清除」(Mark-Sweep)算法,如它的名字同樣,算法分爲「標記」和「清除」兩個階段:首先標記出全部須要回收的對象,在標記完成後統一回收掉全部被標記的對象。之因此說它是最基礎的收集算法,是由於後續的收集算法都是基於這種思路並對其缺點進行改進而獲得的。

它的主要缺點有兩個:一個是效率問題,標記和清除過程的效率都不高;另一個是空間問題,標記清除以後會產生大量不連續的內存碎片,空間碎片太多可能會致使,當程序在之後的運行過程當中須要分配較大對象時沒法找到足夠的連續內存而不得不提早觸發另外一次垃圾收集動做。

複製算法

「複製」(Copying)的收集算法,它將可用內存按容量劃分爲大小相等的兩塊,每次只使用其中的一塊。當這一塊的內存用完了,就將還存活着的對象複製到另一塊上面,而後再把已使用過的內存空間一次清理掉。

這樣使得每次都是對其中的一塊進行內存回收,內存分配時也就不用考慮內存碎片等複雜狀況,只要移動堆頂指針,按順序分配內存便可,實現簡單,運行高效。只是這種算法的代價是將內存縮小爲原來的一半,持續複製長生存期的對象則致使效率下降。

標記-壓縮算法

複製收集算法在對象存活率較高時就要執行較多的複製操做,效率將會變低。更關鍵的是,若是不想浪費50%的空間,就須要有額外的空間進行分配擔保,以應對被使用的內存中全部對象都100%存活的極端狀況,因此在老年代通常不能直接選用這種算法。

根據老年代的特色,有人提出了另一種「標記-整理」(Mark-Compact)算法,標記過程仍然與「標記-清除」算法同樣,但後續步驟不是直接對可回收對象進行清理,而是讓全部存活的對象都向一端移動,而後直接清理掉端邊界之外的內存

分代收集算法

GC分代的基本假設:絕大部分對象的生命週期都很是短暫,存活時間短。

「分代收集」(Generational Collection)算法,把Java堆分爲新生代和老年代,這樣就能夠根據各個年代的特色採用最適當的收集算法。在新生代中,每次垃圾收集時都發現有大批對象死去,只有少許存活,那就選用複製算法,只須要付出少許存活對象的複製成本就能夠完成收集。而老年代中由於對象存活率高、沒有額外空間對它進行分配擔保,就必須使用「標記-清理」或「標記-整理」算法來進行回收。

垃圾收集器

若是說收集算法是內存回收的方法論,垃圾收集器就是內存回收的具體實現

Serial收集器

串行收集器是最古老,最穩定以及效率高的收集器,可能會產生較長的停頓,只使用一個線程去回收。新生代、老年代使用串行回收;新生代複製算法、老年代標記-壓縮;垃圾收集的過程當中會Stop The World(服務暫停)

參數控制: -XX:+UseSerialGC 串行收集器

ParNew收集器 ParNew收集器其實就是Serial收集器的多線程版本。新生代並行,老年代串行;新生代複製算法、老年代標記-壓縮

參數控制:

-XX:+UseParNewGC ParNew收集器
-XX:ParallelGCThreads 限制線程數量

Parallel收集器

Parallel Scavenge收集器相似ParNew收集器,Parallel收集器更關注系統的吞吐量。能夠經過參數來打開自適應調節策略,虛擬機會根據當前系統的運行狀況收集性能監控信息,動態調整這些參數以提供最合適的停頓時間或最大的吞吐量;也能夠經過參數控制GC的時間不大於多少毫秒或者比例;新生代複製算法、老年代標記-壓縮

參數控制: -XX:+UseParallelGC 使用Parallel收集器+ 老年代串行

Parallel Old 收集器

Parallel Old是Parallel Scavenge收集器的老年代版本,使用多線程和「標記-整理」算法。這個收集器是在JDK 1.6中才開始提供

參數控制: -XX:+UseParallelOldGC 使用Parallel收集器+ 老年代並行

CMS收集器

CMS(Concurrent Mark Sweep)收集器是一種以獲取最短回收停頓時間爲目標的收集器。目前很大一部分的Java應用都集中在互聯網站或B/S系統的服務端上,這類應用尤爲重視服務的響應速度,但願系統停頓時間最短,以給用戶帶來較好的體驗。

從名字(包含「Mark Sweep」)上就能夠看出CMS收集器是基於「標記-清除」算法實現的,它的運做過程相對於前面幾種收集器來講要更復雜一些,整個過程分爲4個步驟,包括:

  • 初始標記(CMS initial mark)

  • 併發標記(CMS concurrent mark)

  • 從新標記(CMS remark)

  • 併發清除(CMS concurrent sweep)

其中初始標記、從新標記這兩個步驟仍然須要「Stop The World」。初始標記僅僅只是標記一下GC Roots能直接關聯到的對象,速度很快,併發標記階段就是進行GC Roots Tracing的過程,而從新標記階段則是爲了修正併發標記期間,因用戶程序繼續運做而致使標記產生變更的那一部分對象的標記記錄,這個階段的停頓時間通常會比初始標記階段稍長一些,但遠比並發標記的時間短。

因爲整個過程當中耗時最長的併發標記和併發清除過程當中,收集器線程均可以與用戶線程一塊兒工做,因此整體上來講,CMS收集器的內存回收過程是與用戶線程一塊兒併發地執行。老年代收集器(新生代使用ParNew)

優勢: 併發收集、低停頓
缺點: 產生大量空間碎片、併發階段會下降吞吐量

參數控制:

-XX:+UseConcMarkSweepGC 使用CMS收集器
-XX:+ UseCMSCompactAtFullCollection Full GC後,進行一次碎片整理;整理過程是獨佔的,會引發停頓時間變長
-XX:+CMSFullGCsBeforeCompaction 設置進行幾回Full GC後,進行一次碎片整理
-XX:ParallelCMSThreads 設定CMS的線程數量(通常狀況約等於可用CPU數量)

G1收集器

G1是目前技術發展的最前沿成果之一,HotSpot開發團隊賦予它的使命是將來能夠替換掉JDK1.5中發佈的CMS收集器。與CMS收集器相比G1收集器有如下特色:

  1. 空間整合,G1收集器採用標記整理算法,不會產生內存空間碎片。分配大對象時不會由於沒法找到連續空間而提早觸發下一次GC。

  2. 可預測停頓,這是G1的另外一大優點,下降停頓時間是G1和CMS的共同關注點,但G1除了追求低停頓外,還能創建可預測的停頓時間模型,能讓使用者明確指定在一個長度爲N毫秒的時間片斷內,消耗在垃圾收集上的時間不得超過N毫秒,這幾乎已是實時Java(RTSJ)的垃圾收集器的特徵了。

上面提到的垃圾收集器,收集的範圍都是整個新生代或者老年代,而G1再也不是這樣。使用G1收集器時,Java堆的內存佈局與其餘收集器有很大差異,它將整個Java堆劃分爲多個大小相等的獨立區域(Region),雖然還保留有新生代和老年代的概念,但新生代和老年代再也不是物理隔閡了,它們都是一部分(能夠不連續)Region的集合。

G1的新生代收集跟ParNew相似,當新生代佔用達到必定比例的時候,開始出發收集。和CMS相似,G1收集器收集老年代對象會有短暫停頓。

收集步驟:

一、標記階段,首先初始標記(Initial-Mark),這個階段是停頓的(Stop the World Event),而且會觸發一次普通Mintor GC。對應GC log:GC pause (young) (inital-mark)

二、Root Region Scanning,程序運行過程當中會回收survivor區(存活到老年代),這一過程必須在young GC以前完成。

三、Concurrent Marking,在整個堆中進行併發標記(和應用程序併發執行),此過程可能被young GC中斷。在併發標記階段,若發現區域對象中的全部對象都是垃圾,那個這個區域會被當即回收(圖中打X)。同時,併發標記過程當中,會計算每一個區域的對象活性(區域中存活對象的比例)。

四、Remark, 再標記,會有短暫停頓(STW)。再標記階段是用來收集 併發標記階段 產生新的垃圾(併發階段和應用程序一同運行);G1中採用了比CMS更快的初始快照算法:snapshot-at-the-beginning (SATB)。

五、Copy/Clean up,多線程清除失活對象,會有STW。G1將回收區域的存活對象拷貝到新區域,清除Remember Sets,併發清空回收區域並把它返回到空閒區域鏈表中。

六、複製/清除過程後。回收區域的活性對象已經被集中回收到深藍色和深綠色區域。

相關文章
相關標籤/搜索