這期內(nèi)容當(dāng)中小編將會給大家?guī)碛嘘P(guān)Java 中GC的原理是什么，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

江永ssl適用于網(wǎng)站、小程序/APP、API接口等需要進(jìn)行數(shù)據(jù)傳輸應(yīng)用場景，ssl證書未來市場廣闊！成為創(chuàng)新互聯(lián)的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：028-86922220（備注：SSL證書合作）期待與您的合作！

1 GC調(diào)優(yōu)目標(biāo)

大多數(shù)情況下對 Java 程序進(jìn)行GC調(diào)優(yōu), 主要關(guān)注兩個目標(biāo)：響應(yīng)速度、吞吐量

• 響應(yīng)速度(Responsiveness)響應(yīng)速度指程序或系統(tǒng)對一個請求的響應(yīng)有多迅速。比如，用戶訂單查詢響應(yīng)時間，對響應(yīng)速度要求很高的系統(tǒng)，較大的停頓時間是不可接受的。調(diào)優(yōu)的重點是在短的時間內(nèi)快速響應(yīng)

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

GC調(diào)優(yōu)中，GC導(dǎo)致的應(yīng)用暫停時間影響系統(tǒng)響應(yīng)速度，GC處理線程的CPU使用率影響系統(tǒng)吞吐量

2 GC分代收集算法

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

• 新生代（Young Generation）

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

新生代內(nèi)又分三個區(qū)：一個Eden區(qū)，兩個Survivor區(qū)(S0、S1，又稱From Survivor、To Survivor)，大部分對象在Eden區(qū)中生成。當(dāng)Eden區(qū)滿時，還存活的對象將被復(fù)制到兩個Survivor區(qū)（中的一個）。當(dāng)這個Survivor區(qū)滿時，此區(qū)的存活且不滿足晉升到老年代條件的對象將被復(fù)制到另外一個Survivor區(qū)。對象每經(jīng)歷一次復(fù)制，年齡加1，達(dá)到晉升年齡閾值后，轉(zhuǎn)移到老年代

• 老年代（Old Generation）

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

3 GC事件分類

根據(jù)垃圾收集回收的區(qū)域不同，垃圾收集主要通常分為Young GC、Old GC、Full GC、Mixed GC

(1) Young GC

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

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

(2) Old GC 、Full GC、Mixed GC

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

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

4 GC日志分析

GC日志是一個很重要的工具，它準(zhǔn)確記錄了每一次的GC的執(zhí)行時間和執(zhí)行結(jié)果，通過分析GC日志可以調(diào)優(yōu)堆設(shè)置和GC設(shè)置，或者改進(jìn)應(yīng)用程序的對象分配模式，開啟的JVM啟動參數(shù)如下：

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

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

免費(fèi)的GC日志圖形分析工具推薦下面2個：

• GCViewer，下載jar包直接運(yùn)行

• gceasy，web工具，上傳GC日志在線使用

5 內(nèi)存分配策略

Java提供的自動內(nèi)存管理，可以歸結(jié)為解決了對象的內(nèi)存分配和回收的問題，前面已經(jīng)介紹了內(nèi)存回收，下面介紹幾條最普遍的內(nèi)存分配策略

• 對象優(yōu)先在Eden區(qū)分配大多數(shù)情況下，對象在先新生代Eden區(qū)中分配。當(dāng)Eden區(qū)沒有足夠空間進(jìn)行分配時，虛擬機(jī)將發(fā)起一次Young GC

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

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

• 空間分配擔(dān)保當(dāng)進(jìn)行Young GC之前，JVM需要預(yù)估：老年代是否能夠容納Young GC后新生代晉升到老年代的存活對象，以確定是否需要提前觸發(fā)GC回收老年代空間，基于空間分配擔(dān)保策略來計算：

continueSize：老年代最大可用連續(xù)空間

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

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

另外，如果Young GC后S0或S1區(qū)不足以容納：未達(dá)到晉升老年代條件的新生代存活對象，會導(dǎo)致這些存活對象直接進(jìn)入老年代，需要盡量避免

CMS原理及調(diào)優(yōu)

1 名詞解釋

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

Stop The World：GC過程中分析對象引用關(guān)系，為了保證分析結(jié)果的準(zhǔn)確性，需要通過停頓所有Java執(zhí)行線程，保證引用關(guān)系不再動態(tài)變化，該停頓事件稱為Stop The World(STW)

Safepoint：代碼執(zhí)行過程中的一些特殊位置，當(dāng)線程執(zhí)行到這些位置的時候，說明虛擬機(jī)當(dāng)前的狀態(tài)是安全的，如果有需要GC，線程可以在這個位置暫停。HotSpot采用主動中斷的方式，讓執(zhí)行線程在運(yùn)行期輪詢是否需要暫停的標(biāo)志，若需要則中斷掛起

2 CMS簡介

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

通過以下命令行參數(shù)，啟用CMS垃圾收集器:

-XX:+UseConcMarkSweepGC

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

3 新生代垃圾回收

能與CMS搭配使用的新生代垃圾收集器有Serial收集器和ParNew收集器。這2個收集器都采用標(biāo)記復(fù)制算法，都會觸發(fā)STW事件，停止所有的應(yīng)用線程。不同之處在于，Serial是單線程執(zhí)行，ParNew是多線程執(zhí)行

4 老年代垃圾回收

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

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

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

這個過程是支持多線程的（JDK7之前單線程，JDK8之后并行，可通過參數(shù)CMSParallelInitialMarkEnabled調(diào)整）

• 階段 2: 并發(fā)標(biāo)記(Concurrent Mark)

此階段GC線程和應(yīng)用線程并發(fā)執(zhí)行，遍歷階段1初始標(biāo)記出來的存活對象，然后繼續(xù)遞歸標(biāo)記這些對象可達(dá)的對象

• 階段 3: 并發(fā)預(yù)清理(Concurrent Preclean)

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

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

此階段也不停止應(yīng)用線程. 本階段嘗試在 STW 的 最終標(biāo)記階段(Final Remark)之前盡可能地多做一些工作，以減少應(yīng)用暫停時間 在該階段不斷循環(huán)處理：標(biāo)記老年代的可達(dá)對象、掃描處理Dirty Card區(qū)域中的對象，循環(huán)的終止條件有： 1 達(dá)到循環(huán)次數(shù) 2 達(dá)到循環(huán)執(zhí)行時間閾值 3 新生代內(nèi)存使用率達(dá)到閾值

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

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

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

此階段與應(yīng)用程序并發(fā)執(zhí)行，不需要STW停頓，根據(jù)標(biāo)記結(jié)果清除垃圾對象

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

此階段與應(yīng)用程序并發(fā)執(zhí)行，重置CMS算法相關(guān)的內(nèi)部數(shù)據(jù), 為下一次GC循環(huán)做準(zhǔn)備

5 CMS常見問題

最終標(biāo)記階段停頓時間過長問題

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

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

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

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

晉升失敗：當(dāng)新生代發(fā)生垃圾回收，老年代有足夠的空間可以容納晉升的對象，但是由于空閑空間的碎片化，導(dǎo)致晉升失敗，此時會觸發(fā)單線程且?guī)嚎s動作的Full GC

并發(fā)模式失敗和晉升失敗都會導(dǎo)致長時間的停頓，常見解決思路如下：

• 降低觸發(fā)CMS GC的閾值，即參數(shù)-XX:CMSInitiatingOccupancyFraction的值，讓CMS GC盡早執(zhí)行，以保證有足夠的空間

• 增加CMS線程數(shù)，即參數(shù)-XX:ConcGCThreads，

• 增大老年代空間

• 讓對象盡量在新生代回收，避免進(jìn)入老年代

內(nèi)存碎片問題

通常CMS的GC過程基于標(biāo)記清除算法，不帶壓縮動作，導(dǎo)致越來越多的內(nèi)存碎片需要壓縮，常見以下場景會觸發(fā)內(nèi)存碎片壓縮：

• 新生代Young GC出現(xiàn)新生代晉升擔(dān)保失敗(promotion failed)

• 程序主動執(zhí)行System.gc()

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

G1原理及調(diào)優(yōu)

1 G1簡介

G1(Garbage-First）是一款面向服務(wù)器的垃圾收集器，支持新生代和老年代空間的垃圾收集，主要針對配備多核處理器及大容量內(nèi)存的機(jī)器，G1最主要的設(shè)計目標(biāo)是: 實現(xiàn)可預(yù)期及可配置的STW停頓時間

2 G1堆空間劃分

• Region

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

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

• 巨型對象

當(dāng)對象大小超過Region的一半，則認(rèn)為是巨型對象(Humongous Object)，直接被分配到老年代的巨型對象區(qū)(Humongous regions)，這些巨型區(qū)域是一個連續(xù)的區(qū)域集，每一個Region中最多有一個巨型對象，巨型對象可以占多個Region

G1把堆內(nèi)存劃分成一個個Region的意義在于：

• 每次GC不必都去處理整個堆空間，而是每次只處理一部分Region，實現(xiàn)大容量內(nèi)存的GC

• 通過計算每個Region的回收價值，包括回收所需時間、可回收空間，在有限時間內(nèi)盡可能回收更多的垃圾對象，把垃圾回收造成的停頓時間控制在預(yù)期配置的時間范圍內(nèi)，這也是G1名稱的由來: garbage-first

3 G1工作模式

針對新生代和老年代，G1提供2種GC模式，Young GC和Mixed GC，兩種會導(dǎo)致Stop The World

• Young GC 當(dāng)新生代的空間不足時，G1觸發(fā)Young GC回收新生代空間 Young GC主要是對Eden區(qū)進(jìn)行GC，它在Eden空間耗盡時觸發(fā)，基于分代回收思想和復(fù)制算法，每次Young GC都會選定所有新生代的Region，同時計算下次Young GC所需的Eden區(qū)和Survivor區(qū)的空間，動態(tài)調(diào)整新生代所占Region個數(shù)來控制Young GC開銷

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

4 全局并發(fā)標(biāo)記

全局并發(fā)標(biāo)記主要是為Mixed GC計算找出回收收益較高的Region區(qū)域，具體分為5個階段

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

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

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

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

• 階段 5: 清理(Cleanup)為即將到來的轉(zhuǎn)移階段做準(zhǔn)備, 此階段也為下一次標(biāo)記執(zhí)行所有必需的整理計算工作：

• 整理更新每個Region各自的RSet(remember set，HashMap結(jié)構(gòu)，記錄有哪些老年代對象指向本Region，key為指向本Region的對象的引用，value為指向本Region的具體Card區(qū)域，通過RSet可以確定Region中對象存活信息，避免全堆掃描)

• 回收不包含存活對象的Region

• 統(tǒng)計計算回收收益高（基于釋放空間和暫停目標(biāo)）的老年代分區(qū)集合

5 G1調(diào)優(yōu)注意點

Full GC問題

G1的正常處理流程中沒有Full GC，只有在垃圾回收處理不過來(或者主動觸發(fā))時才會出現(xiàn)， G1的Full GC就是單線程執(zhí)行的Serial old gc，會導(dǎo)致非常長的STW，是調(diào)優(yōu)的重點，需要盡量避免Full GC，常見原因如下：

• 程序主動執(zhí)行System.gc()

• 全局并發(fā)標(biāo)記期間老年代空間被填滿（并發(fā)模式失?。?/p>

• Mixed GC期間老年代空間被填滿（晉升失?。?/p>

• Young GC時Survivor空間和老年代沒有足夠空間容納存活對象

類似CMS，常見的解決是：

• 增大-XX:ConcGCThreads=n 選項增加并發(fā)標(biāo)記線程的數(shù)量，或者STW期間并行線程的數(shù)量：-XX:ParallelGCThreads=n

• 減小-XX:InitiatingHeapOccupancyPercent 提前啟動標(biāo)記周期

• 增大預(yù)留內(nèi)存 -XX:G1ReservePercent=n ，默認(rèn)值是10，代表使用10%的堆內(nèi)存為預(yù)留內(nèi)存，當(dāng)Survivor區(qū)域沒有足夠空間容納新晉升對象時會嘗試使用預(yù)留內(nèi)存

巨型對象分配

巨型對象區(qū)中的每個Region中包含一個巨型對象，剩余空間不再利用，導(dǎo)致空間碎片化，當(dāng)G1沒有合適空間分配巨型對象時，G1會啟動串行Full GC來釋放空間?？梢酝ㄟ^增加 -XX:G1HeapRegionSize來增大Region大小，這樣一來，相當(dāng)一部分的巨型對象就不再是巨型對象了，而是采用普通的分配方式

不要設(shè)置Young區(qū)的大小

原因是為了盡量滿足目標(biāo)停頓時間，邏輯上的Young區(qū)會進(jìn)行動態(tài)調(diào)整。如果設(shè)置了大小，則會覆蓋掉并且會禁用掉對停頓時間的控制

平均響應(yīng)時間設(shè)置

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

調(diào)優(yōu)方法與思路

如何分析系統(tǒng)JVM GC運(yùn)行狀況及合理優(yōu)化？

GC優(yōu)化的核心思路在于：盡可能讓對象在新生代中分配和回收，盡量避免過多對象進(jìn)入老年代，導(dǎo)致對老年代頻繁進(jìn)行垃圾回收，同時給系統(tǒng)足夠的內(nèi)存減少新生代垃圾回收次數(shù)，進(jìn)行系統(tǒng)分析和優(yōu)化也是圍繞著這個思路展開

1 分析系統(tǒng)的運(yùn)行狀況

• 系統(tǒng)每秒請求數(shù)、每個請求創(chuàng)建多少對象，占用多少內(nèi)存

• Young GC觸發(fā)頻率、對象進(jìn)入老年代的速率

• 老年代占用內(nèi)存、Full GC觸發(fā)頻率、Full GC觸發(fā)的原因、長時間Full GC的原因

常用工具如下：

• jstatjvm自帶命令行工具，可用于統(tǒng)計內(nèi)存分配速率、GC次數(shù)，GC耗時，常用命令格式

jstat -gc <pid> <統(tǒng)計間隔時間>  <統(tǒng)計次數(shù)>

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

例如： jstat -gc 32683 1000 10 ，統(tǒng)計pid=32683的進(jìn)程，每秒統(tǒng)計1次，統(tǒng)計10次

• jmapjvm自帶命令行工具，可用于了解系統(tǒng)運(yùn)行時的對象分布，常用命令格式如下

// 命令行輸出類名、類數(shù)量數(shù)量，類占用內(nèi)存大小，
// 按照類占用內(nèi)存大小降序排列
jmap -histo <pid>

// 生成堆內(nèi)存轉(zhuǎn)儲快照，在當(dāng)前目錄下導(dǎo)出dump.hrpof的二進(jìn)制文件，
// 可以用eclipse的MAT圖形化工具分析
jmap -dump:live,format=b,file=dump.hprof <pid>

• jinfo命令格式

jinfo <pid>

用來查看正在運(yùn)行的 Java 應(yīng)用程序的擴(kuò)展參數(shù)，包括Java System屬性和JVM命令行參數(shù)

其他GC工具

• 監(jiān)控告警系統(tǒng)：Zabbix、Prometheus、Open-Falcon

• jdk自動實時內(nèi)存監(jiān)控工具：VisualVM

• 堆外內(nèi)存監(jiān)控： Java VisualVM安裝Buffer Pools 插件、google perf工具、Java NMT(Native Memory Tracking)工具

• GC日志分析：GCViewer、gceasy

• GC參數(shù)檢查和優(yōu)化：http://xxfox.perfma.com/

2 GC優(yōu)化案例

• 數(shù)據(jù)分析平臺系統(tǒng)頻繁Full GC

平臺主要對用戶在APP中行為進(jìn)行定時分析統(tǒng)計，并支持報表導(dǎo)出，使用CMS GC算法。數(shù)據(jù)分析師在使用中發(fā)現(xiàn)系統(tǒng)頁面打開經(jīng)?？D，通過jstat命令發(fā)現(xiàn)系統(tǒng)每次Young GC后大約有10%的存活對象進(jìn)入老年代。

原來是因為Survivor區(qū)空間設(shè)置過小，每次Young GC后存活對象在Survivor區(qū)域放不下，提前進(jìn)入老年代，通過調(diào)大Survivor區(qū)，使得Survivor區(qū)可以容納Young GC后存活對象，對象在Survivor區(qū)經(jīng)歷多次Young GC達(dá)到年齡閾值才進(jìn)入老年代，調(diào)整之后每次Young GC后進(jìn)入老年代的存活對象穩(wěn)定運(yùn)行時僅幾百Kb，F(xiàn)ull GC頻率大大降低

• 業(yè)務(wù)對接網(wǎng)關(guān)OOM

網(wǎng)關(guān)主要消費(fèi)Kafka數(shù)據(jù)，進(jìn)行數(shù)據(jù)處理計算然后轉(zhuǎn)發(fā)到另外的Kafka隊列，系統(tǒng)運(yùn)行幾個小時候出現(xiàn)OOM，重啟系統(tǒng)幾個小時之后又OOM，通過jmap導(dǎo)出堆內(nèi)存，在eclipse MAT工具分析才找出原因：代碼中將某個業(yè)務(wù)Kafka的topic數(shù)據(jù)進(jìn)行日志異步打印，該業(yè)務(wù)數(shù)據(jù)量較大，大量對象堆積在內(nèi)存中等待被打印，導(dǎo)致OOM

• 賬號權(quán)限管理系統(tǒng)頻繁長時間Full GC

系統(tǒng)對外提供各種賬號鑒權(quán)服務(wù)，使用時發(fā)現(xiàn)系統(tǒng)經(jīng)常服務(wù)不可用，通過Zabbix的監(jiān)控平臺監(jiān)控發(fā)現(xiàn)系統(tǒng)頻繁發(fā)生長時間Full GC，且觸發(fā)時老年代的堆內(nèi)存通常并沒有占滿，發(fā)現(xiàn)原來是業(yè)務(wù)代碼中調(diào)用了System.gc()

上述就是小編為大家分享的Java 中GC的原理是什么了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

名稱欄目：Java中GC的原理是什么
轉(zhuǎn)載源于：http://chinadenli.net/article42/ppchec.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供定制開發(fā)、企業(yè)建站、虛擬主機(jī)、ChatGPT、網(wǎng)站維護(hù)、網(wǎng)站導(dǎo)航

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)