老大難的Java GC原理和調優,看這篇就夠了

概述

本文介紹GC基礎原理和理論,GC調優方法思路和方法,基于Hotspot jdk1.8,學習之后將了解如何對生產系統出現的GC問題進行排查解決

閱讀時長約30分鐘,內容主要如下:

  • GC基礎原理,涉及調優目標,GC事件分類、JVM內存分配策略、GC日志分析等
  • CMS原理及調優
  • G1原理及調優
  • GC問題排查和解決思路

GC基礎原理

1 GC調優目標

大多數情況下對 Java 程序進行GC調優, 主要關注兩個目標:響應速度、吞吐量

  • 響應速度(Responsiveness)
    響應速度指程序或系統對一個請求的響應有多迅速。比如,用戶訂單查詢響應時間,對響應速度要求很高的系統,較大的停頓時間是不可接受的。調優的重點是在短的時間內快速響應

  • 吞吐量(Throughput)
    吞吐量關注在一個特定時間段內應用系統的最大工作量,例如每小時批處理系統能完成的任務數量,在吞吐量方面優化的系統,較長的GC停頓時間也是可以接受的,因為高吞吐量應用更關心的是如何盡可能快地完成整個任務,不考慮快速響應用戶請求

GC調優中,GC導致的應用暫停時間影響系統響應速度,GC處理線程的CPU使用率影響系統吞吐量

2 GC分代收集算法

現代的垃圾收集器基本都是采用分代收集算法,其主要思想:
將Java的堆內存邏輯上分成兩塊:新生代、老年代,針對不同存活周期、不同大小的對象采取不同的垃圾回收策略

分代收集算法

  • 新生代(Young Generation)

新生代又叫年輕代,大多數對象在新生代中被創建,很多對象的生命周期很短。每次新生代的垃圾回收(又稱Young GC、Minor GC、YGC)后只有少量對象存活,所以使用復制算法,只需少量的復制操作成本就可以完成回收

新生代內又分三個區:一個Eden區,兩個Survivor區(S0、S1,又稱From Survivor、To Survivor),大部分對象在Eden區中生成。當Eden區滿時,還存活的對象將被復制到兩個Survivor區(中的一個)。當這個Survivor區滿時,此區的存活且不滿足晉升到老年代條件的對象將被復制到另外一個Survivor區。對象每經歷一次復制,年齡加1,達到晉升年齡閾值后,轉移到老年代

  • 老年代(Old Generation)

在新生代中經歷了N次垃圾回收后仍然存活的對象,就會被放到老年代,該區域中對象存活率高。老年代的垃圾回收通常使用“標記-整理”算法

3 GC事件分類

根據垃圾收集回收的區域不同,垃圾收集主要通常分為Young GC、Old GC、Full GC、Mixed GC

(1) Young GC

新生代內存的垃圾收集事件稱為Young GC(又稱Minor GC),當JVM無法為新對象分配在新生代內存空間時總會觸發 Young GC,比如 Eden 區占滿時。新對象分配頻率越高, Young GC 的頻率就越高

Young GC 每次都會引起全線停頓(Stop-The-World),暫停所有的應用線程,停頓時間相對老年代GC的造成的停頓,幾乎可以忽略不計

(2) Old GC 、Full GC、Mixed GC

Old GC,只清理老年代空間的GC事件,只有CMS的并發收集是這個模式
Full GC,清理整個堆的GC事件,包括新生代、老年代、元空間等

  • Mixed GC,清理整個新生代以及部分老年代的GC,只有G1有這個模式

4 GC日志分析

GC日志是一個很重要的工具,它準確記錄了每一次的GC的執行時間和執行結果,通過分析GC日志可以調優堆設置和GC設置,或者改進應用程序的對象分配模式,開啟的JVM啟動參數如下:

-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps  -XX:+PrintGCTimeStamps

常見的Young GC、Full GC日志含義如下:

Young GC

Full GC

免費的GC日志圖形分析工具推薦下面2個:

  • GCViewer,下載jar包直接運行
  • gceasy,web工具,上傳GC日志在線使用

5 內存分配策略

Java提供的自動內存管理,可以歸結為解決了對象的內存分配和回收的問題,前面已經介紹了內存回收,下面介紹幾條最普遍的內存分配策略

  • 對象優先在Eden區分配
    大多數情況下,對象在先新生代Eden區中分配。當Eden區沒有足夠空間進行分配時,虛擬機將發起一次Young GC

  • 大對象之間進入老年代
    JVM提供了一個對象大小閾值參數(-XX:PretenureSizeThreshold,默認值為0,代表不管多大都是先在Eden中分配內存),大于參數設置的閾值值的對象直接在老年代分配,這樣可以避免對象在Eden及兩個Survivor直接發生大內存復制

  • 長期存活的對象將進入老年代
    對象每經歷一次垃圾回收,且沒被回收掉,它的年齡就增加1,大于年齡閾值參數(-XX:MaxTenuringThreshold,默認15)的對象,將晉升到老年代中

  • 空間分配擔保
    當進行Young GC之前,JVM需要預估:老年代是否能夠容納Young GC后新生代晉升到老年代的存活對象,以確定是否需要提前觸發GC回收老年代空間,基于空間分配擔保策略來計算:

continueSize:老年代最大可用連續空間

空間分配擔保

Young GC之后如果成功(Young GC后晉升對象能放入老年代),則代表擔保成功,不用再進行Full GC,提高性能;如果失敗,則會出現“promotion failed”錯誤,代表擔保失敗,需要進行Full GC

  • 動態年齡判定
    新生代對象的年齡可能沒達到閾值(MaxTenuringThreshold參數指定)就晉升老年代,如果Young GC之后,新生代存活對象達到相同年齡所有對象大小的總和大于任一Survivor空間(S0 或 S1總空間)的一半,此時S0或者S1區即將容納不了存活的新生代對象,年齡大于或等于該年齡的對象就可以直接進入老年代,無須等到MaxTenuringThreshold中要求的年齡

另外,如果Young GC后S0或S1區不足以容納:未達到晉升老年代條件的新生代存活對象,會導致這些存活對象直接進入老年代,需要盡量避免

CMS原理及調優

1 名詞解釋

可達性分析算法:用于判斷對象是否存活,基本思想是通過一系列稱為“GC Root”的對象作為起點(常見的GC Root有系統類加載器、棧中的對象、處于激活狀態的線程等),基于對象引用關系,從GC Roots開始向下搜索,所走過的路徑稱為引用鏈,當一個對象到GC Root沒有任何引用鏈相連,證明對象不再存活

Stop The World:GC過程中分析對象引用關系,為了保證分析結果的準確性,需要通過停頓所有Java執行線程,保證引用關系不再動態變化,該停頓事件稱為Stop The World(STW)

Safepoint:代碼執行過程中的一些特殊位置,當線程執行到這些位置的時候,說明虛擬機當前的狀態是安全的,如果有需要GC,線程可以在這個位置暫停。HotSpot采用主動中斷的方式,讓執行線程在運行期輪詢是否需要暫停的標志,若需要則中斷掛起

2 CMS簡介

CMS(Concurrent Mark and Swee 并發-標記-清除),是一款基于并發、使用標記清除算法的垃圾回收算法,只針對老年代進行垃圾回收。CMS收集器工作時,盡可能讓GC線程和用戶線程并發執行,以達到降低STW時間的目的

通過以下命令行參數,啟用CMS垃圾收集器:

-XX:+UseConcMarkSweepGC

值得補充的是,下面介紹到的CMS GC是指老年代的GC,而Full GC指的是整個堆的GC事件,包括新生代、老年代、元空間等,兩者有所區分

3 新生代垃圾回收

能與CMS搭配使用的新生代垃圾收集器有Serial收集器和ParNew收集器。這2個收集器都采用標記復制算法,都會觸發STW事件,停止所有的應用線程。不同之處在于,Serial是單線程執行,ParNew是多線程執行

新生代

4 老年代垃圾回收

CMS GC以獲取最小停頓時間為目的,盡可能減少STW時間,可以分為7個階段

CMS 7個階段

  • 階段 1: 初始標記(Initial Mark)

此階段的目標是標記老年代中所有存活的對象, 包括 GC Root 的直接引用, 以及由新生代中存活對象所引用的對象,觸發第一次STW事件

這個過程是支持多線程的(JDK7之前單線程,JDK8之后并行,可通過參數CMSParallelInitialMarkEnabled調整)

初始標記

  • 階段 2: 并發標記(Concurrent Mark)

此階段GC線程和應用線程并發執行,遍歷階段1初始標記出來的存活對象,然后繼續遞歸標記這些對象可達的對象

并發標記

  • 階段 3: 并發預清理(Concurrent Preclean)

此階段GC線程和應用線程也是并發執行,因為階段2是與應用線程并發執行,可能有些引用關系已經發生改變。
通過卡片標記(Card Marking),提前把老年代空間邏輯劃分為相等大小的區域(Card),如果引用關系發生改變,JVM會將發生改變的區域標記位“臟區”(Dirty Card),然后在本階段,這些臟區會被找出來,刷新引用關系,清除“臟區”標記

并發預清理

  • 階段 4: 并發可取消的預清理(Concurrent Abortable Preclean)

此階段也不停止應用線程. 本階段嘗試在 STW 的 最終標記階段(Final Remark)之前盡可能地多做一些工作,以減少應用暫停時間
在該階段不斷循環處理:標記老年代的可達對象、掃描處理Dirty Card區域中的對象,循環的終止條件有:
1 達到循環次數
2 達到循環執行時間閾值
3 新生代內存使用率達到閾值

  • 階段 5: 最終標記(Final Remark)

這是GC事件中第二次(也是最后一次)STW階段,目標是完成老年代中所有存活對象的標記。在此階段執行:
1 遍歷新生代對象,重新標記
2 根據GC Roots,重新標記
3 遍歷老年代的Dirty Card,重新標記

  • 階段 6: 并發清除(Concurrent Sweep)

此階段與應用程序并發執行,不需要STW停頓,根據標記結果清除垃圾對象

并發清除

  • 階段 7: 并發重置(Concurrent Reset)

此階段與應用程序并發執行,重置CMS算法相關的內部數據, 為下一次GC循環做準備

5 CMS常見問題

最終標記階段停頓時間過長問題

CMS的GC停頓時間約80%都在最終標記階段(Final Remark),若該階段停頓時間過長,常見原因是新生代對老年代的無效引用,在上一階段的并發可取消預清理階段中,執行閾值時間內未完成循環,來不及觸發Young GC,清理這些無效引用

通過添加參數:-XX:+CMSScavengeBeforeRemark。在執行最終操作之前先觸發Young GC,從而減少新生代對老年代的無效引用,降低最終標記階段的停頓,但如果在上個階段(并發可取消的預清理)已觸發Young GC,也會重復觸發Young GC

并發模式失敗(concurrent mode failure) & 晉升失敗(promotion failed)問題

并發模式失敗

并發模式失敗:當CMS在執行回收時,新生代發生垃圾回收,同時老年代又沒有足夠的空間容納晉升的對象時,CMS 垃圾回收就會退化成單線程的Full GC。所有的應用線程都會被暫停,老年代中所有的無效對象都被回收

晉升失敗

晉升失敗:當新生代發生垃圾回收,老年代有足夠的空間可以容納晉升的對象,但是由于空閑空間的碎片化,導致晉升失敗,此時會觸發單線程且帶壓縮動作的Full GC

并發模式失敗和晉升失敗都會導致長時間的停頓,常見解決思路如下:

  • 降低觸發CMS GC的閾值,即參數-XX:CMSInitiatingOccupancyFraction的值,讓CMS GC盡早執行,以保證有足夠的空間
  • 增加CMS線程數,即參數-XX:ConcGCThreads,
  • 增大老年代空間
  • 讓對象盡量在新生代回收,避免進入老年代

內存碎片問題

通常CMS的GC過程基于標記清除算法,不帶壓縮動作,導致越來越多的內存碎片需要壓縮,常見以下場景會觸發內存碎片壓縮:

  • 新生代Young GC出現新生代晉升擔保失敗(promotion failed)
  • 程序主動執行System.gc()

可通過參數CMSFullGCsBeforeCompaction的值,設置多少次Full GC觸發一次壓縮,默認值為0,代表每次進入Full GC都會觸發壓縮,帶壓縮動作的算法為上面提到的單線程Serial Old算法,暫停時間(STW)時間非常長,需要盡可能減少壓縮時間

G1原理及調優

1 G1簡介

G1(Garbage-First)是一款面向服務器的垃圾收集器,支持新生代和老年代空間的垃圾收集,主要針對配備多核處理器及大容量內存的機器,G1最主要的設計目標是: 實現可預期及可配置的STW停頓時間

2 G1堆空間劃分

G1收集器堆空間

  • Region

為實現大內存空間的低停頓時間的回收,將劃分為多個大小相等的Region。每個小堆區都可能是 Eden區,Survivor區或者Old區,但是在同一時刻只能屬于某個代

在邏輯上, 所有的Eden區和Survivor區合起來就是新生代,所有的Old區合起來就是老年代,且新生代和老年代各自的內存Region區域由G1自動控制,不斷變動

  • 巨型對象

當對象大小超過Region的一半,則認為是巨型對象(Humongous Object),直接被分配到老年代的巨型對象區(Humongous regions),這些巨型區域是一個連續的區域集,每一個Region中最多有一個巨型對象,巨型對象可以占多個Region

G1把堆內存劃分成一個個Region的意義在于:

  • 每次GC不必都去處理整個堆空間,而是每次只處理一部分Region,實現大容量內存的GC
  • 通過計算每個Region的回收價值,包括回收所需時間、可回收空間,在有限時間內盡可能回收更多的垃圾對象,把垃圾回收造成的停頓時間控制在預期配置的時間范圍內,這也是G1名稱的由來: garbage-first

3 G1工作模式

針對新生代和老年代,G1提供2種GC模式,Young GC和Mixed GC,兩種會導致Stop The World

  • Young GC
    當新生代的空間不足時,G1觸發Young GC回收新生代空間
    Young GC主要是對Eden區進行GC,它在Eden空間耗盡時觸發,基于分代回收思想和復制算法,每次Young GC都會選定所有新生代的Region,同時計算下次Young GC所需的Eden區和Survivor區的空間,動態調整新生代所占Region個數來控制Young GC開銷

  • Mixed GC
    當老年代空間達到閾值會觸發Mixed GC,選定所有新生代里的Region,根據全局并發標記階段(下面介紹到)統計得出收集收益高的若干老年代 Region。在用戶指定的開銷目標范圍內,盡可能選擇收益高的老年代Region進行GC,通過選擇哪些老年代Region和選擇多少Region來控制Mixed GC開銷

4 全局并發標記

全局并發標記主要是為Mixed GC計算找出回收收益較高的Region區域,具體分為5個階段

全局并發標記

  • 階段 1: 初始標記(Initial Mark)
    暫停所有應用線程(STW),并發地進行標記從 GC Root 開始直接可達的對象(原生棧對象、全局對象、JNI 對象),當達到觸發條件時,G1 并不會立即發起并發標記周期,而是等待下一次新生代收集,利用新生代收集的 STW 時間段,完成初始標記,這種方式稱為借道(Piggybacking)

  • 階段 2: 根區域掃描(Root Region Scan)
    在初始標記暫停結束后,新生代收集也完成的對象復制到 Survivor 的工作,應用線程開始活躍起來;
    此時為了保證標記算法的正確性,所有新復制到 Survivor 分區的對象,需要找出哪些對象存在對老年代對象的引用,把這些對象標記成根(Root);
    這個過程稱為根分區掃描(Root Region Scanning),同時掃描的 Suvivor 分區也被稱為根分區(Root Region);
    根分區掃描必須在下一次新生代垃圾收集啟動前完成(接下來并發標記的過程中,可能會被若干次新生代垃圾收集打斷),因為每次 GC 會產生新的存活對象集合

  • 階段 3: 并發標記(Concurrent Marking)
    標記線程與應用程序線程并行執行,標記各個堆中Region的存活對象信息,這個步驟可能被新的 Young GC 打斷
    所有的標記任務必須在堆滿前就完成掃描,如果并發標記耗時很長,那么有可能在并發標記過程中,又經歷了幾次新生代收集

  • 階段 4: 再次標記(Remark)
    和CMS類似暫停所有應用線程(STW),以完成標記過程短暫地停止應用線程, 標記在并發標記階段發生變化的對象,和所有未被標記的存活對象,同時完成存活數據計算

  • 階段 5: 清理(Cleanup)
    為即將到來的轉移階段做準備, 此階段也為下一次標記執行所有必需的整理計算工作:
    • 整理更新每個Region各自的RSet(remember set,HashMap結構,記錄有哪些老年代對象指向本Region,key為指向本Region的對象的引用,value為指向本Region的具體Card區域,通過RSet可以確定Region中對象存活信息,避免全堆掃描)
    • 回收不包含存活對象的Region
    • 統計計算回收收益高(基于釋放空間和暫停目標)的老年代分區集合

5 G1調優注意點

Full GC問題

G1的正常處理流程中沒有Full GC,只有在垃圾回收處理不過來(或者主動觸發)時才會出現, G1的Full GC就是單線程執行的Serial old gc,會導致非常長的STW,是調優的重點,需要盡量避免Full GC,常見原因如下:

  • 程序主動執行System.gc()
  • 全局并發標記期間老年代空間被填滿(并發模式失敗)
  • Mixed GC期間老年代空間被填滿(晉升失敗)
  • Young GC時Survivor空間和老年代沒有足夠空間容納存活對象

類似CMS,常見的解決是:

  • 增大-XX:ConcGCThreads=n 選項增加并發標記線程的數量,或者STW期間并行線程的數量:-XX:ParallelGCThreads=n
  • 減小-XX:InitiatingHeapOccupancyPercent 提前啟動標記周期
  • 增大預留內存 -XX:G1ReservePercent=n ,默認值是10,代表使用10%的堆內存為預留內存,當Survivor區域沒有足夠空間容納新晉升對象時會嘗試使用預留內存

巨型對象分配

巨型對象區中的每個Region中包含一個巨型對象,剩余空間不再利用,導致空間碎片化,當G1沒有合適空間分配巨型對象時,G1會啟動串行Full GC來釋放空間。可以通過增加 -XX:G1HeapRegionSize來增大Region大小,這樣一來,相當一部分的巨型對象就不再是巨型對象了,而是采用普通的分配方式

不要設置Young區的大小

原因是為了盡量滿足目標停頓時間,邏輯上的Young區會進行動態調整。如果設置了大小,則會覆蓋掉并且會禁用掉對停頓時間的控制

平均響應時間設置

使用應用的平均響應時間作為參考來設置MaxGCPauseMillis,JVM會盡量去滿足該條件,可能是90%的請求或者更多的響應時間在這之內, 但是并不代表是所有的請求都能滿足,平均響應時間設置過小會導致頻繁GC

調優方法與思路

如何分析系統JVM GC運行狀況及合理優化?

GC優化的核心思路在于:盡可能讓對象在新生代中分配和回收,盡量避免過多對象進入老年代,導致對老年代頻繁進行垃圾回收,同時給系統足夠的內存減少新生代垃圾回收次數,進行系統分析和優化也是圍繞著這個思路展開

1 分析系統的運行狀況

  • 系統每秒請求數、每個請求創建多少對象,占用多少內存
  • Young GC觸發頻率、對象進入老年代的速率
  • 老年代占用內存、Full GC觸發頻率、Full GC觸發的原因、長時間Full GC的原因

常用工具如下:

  • jstat
    jvm自帶命令行工具,可用于統計內存分配速率、GC次數,GC耗時,常用命令格式
jstat -gc <pid> <統計間隔時間>  <統計次數>

輸出返回值代表含義如下:

jstat

例如: jstat -gc 32683 1000 10 ,統計pid=32683的進程,每秒統計1次,統計10次

  • jmap
    jvm自帶命令行工具,可用于了解系統運行時的對象分布,常用命令格式如下
// 命令行輸出類名、類數量數量,類占用內存大小,
// 按照類占用內存大小降序排列
jmap -histo <pid>

// 生成堆內存轉儲快照,在當前目錄下導出dump.hrpof的二進制文件,
// 可以用eclipse的MAT圖形化工具分析
jmap -dump:live,format=b,file=dump.hprof <pid>
  • jinfo
    命令格式
jinfo <pid> 

用來查看正在運行的 Java 應用程序的擴展參數,包括Java System屬性和JVM命令行參數

其他GC工具

  • 監控告警系統:Zabbix、Prometheus、Open-Falcon
  • jdk自動實時內存監控工具:VisualVM
  • 堆外內存監控: Java VisualVM安裝Buffer Pools 插件、google perf工具、Java NMT(Native Memory Tracking)工具
  • GC日志分析:GCViewer、gceasy
  • GC參數檢查和優化:http://xxfox.perfma.com/

2 GC優化案例

  • 數據分析平臺系統頻繁Full GC

平臺主要對用戶在APP中行為進行定時分析統計,并支持報表導出,使用CMS GC算法。數據分析師在使用中發現系統頁面打開經常卡頓,通過jstat命令發現系統每次Young GC后大約有10%的存活對象進入老年代。

原來是因為Survivor區空間設置過小,每次Young GC后存活對象在Survivor區域放不下,提前進入老年代,通過調大Survivor區,使得Survivor區可以容納Young GC后存活對象,對象在Survivor區經歷多次Young GC達到年齡閾值才進入老年代,調整之后每次Young GC后進入老年代的存活對象穩定運行時僅幾百Kb,Full GC頻率大大降低

  • 業務對接網關OOM

網關主要消費Kafka數據,進行數據處理計算然后轉發到另外的Kafka隊列,系統運行幾個小時候出現OOM,重啟系統幾個小時之后又OOM,通過jmap導出堆內存,在eclipse MAT工具分析才找出原因:代碼中將某個業務Kafka的topic數據進行日志異步打印,該業務數據量較大,大量對象堆積在內存中等待被打印,導致OOM

  • 賬號權限管理系統頻繁長時間Full GC

系統對外提供各種賬號鑒權服務,使用時發現系統經常服務不可用,通過Zabbix的監控平臺監控發現系統頻繁發生長時間Full GC,且觸發時老年代的堆內存通常并沒有占滿,發現原來是業務代碼中調用了System.gc()

總結

GC問題可以說沒有捷徑,排查線上的性能問題本身就并不簡單,除了將本文介紹到的原理和工具融會貫通,還需要我們不斷去積累經驗,真正做到性能最優

篇幅所限,不再展開介紹常見GC參數的使用,我發布在github:https://github.com/caison/caison-blog-demo

參考

《Java Performance: The Definitive Guide》 Scott Oaks

《深入理解 Java 虛擬機:JVM 高級特性與最佳實踐(第二版》 周志華

Java性能調優實戰

Getting Started with the G1 Garbage Collector

GC參考手冊-Java版

請教G1算法的原理——RednaxelaFX的回答

Java Hotspot G1 GC的一些關鍵技術——美團技術團隊

posted @ 2019-10-09 14:51  分布式系統架構  閱讀(...)  評論(... 編輯 收藏
七乐彩2011年走势图南方双彩