首先應(yīng)該明確的是JVM調(diào)優(yōu)不是常規(guī)手段，JVM的存在本身就是為了減輕開發(fā)對于內(nèi)存管理的負(fù)擔(dān)，當(dāng)出現(xiàn)性能問題的時候第一時間考慮的是代碼邏輯與設(shè)計方案，以及是否達(dá)到依賴中間件的瓶頸，最后才是針對JVM進(jìn)行優(yōu)化。

1.JVM內(nèi)存模型

針對JAVA8的模型進(jìn)行討論，JVM的內(nèi)存模型主要分為幾個關(guān)鍵區(qū)域：堆、方法區(qū)、程序計數(shù)器、虛擬機(jī)棧和本地方法棧。堆內(nèi)存進(jìn)一步細(xì)分為年輕代、老年代，年輕代按其特性又分為E區(qū)，S1和S2區(qū)。關(guān)于內(nèi)存模型的一些細(xì)節(jié)就不在這里討論了，如下是從網(wǎng)上找的內(nèi)存模型圖：

接下來從內(nèi)存模型簡單流轉(zhuǎn)來看一個對象的生命周期，對JVM的回收有一個概念，其中弱化堆棧和程序計數(shù)器

1.首先我們寫的.java文件通過java編譯器javac編譯成.class文件

2.類被編譯成.class文件后，通過類加載器（雙親委派模型）加載到JVM的元空間中

3.當(dāng)創(chuàng)建對象時，JVM在堆內(nèi)存中為對象分配空間，通常首先在年輕代的E區(qū)(這里只討論在堆上分配的情況）

4.對象經(jīng)歷YGC后，如果存活移動到S區(qū)，多次存活后晉升到老年代

5.當(dāng)對象不再被引用下一次GC，垃圾收集器會回收對象并釋放其占用的內(nèi)存。

1.1 年輕代回收原理

對象創(chuàng)建會在年輕代的E區(qū)分配內(nèi)存，當(dāng)失去引用后，變成垃圾存在E區(qū)中，隨著程序運(yùn)行E區(qū)不斷創(chuàng)建對象，就會逐步塞滿，這時候E區(qū)中絕大部分都是失去引用的垃圾對象，和一小部分正在運(yùn)行中的線程產(chǎn)生的存活對象。這時候會觸發(fā)YGC(Young Gc)回收年輕代。然后把存活對象都放入第一個S區(qū)域中，也就是S0區(qū)域，接著垃圾回收器就會直接回收掉E區(qū)里全部垃圾對象，在整個這個垃圾回收的過程中全程會進(jìn)入Stop the Wold狀態(tài)，系統(tǒng)代碼全部停止運(yùn)行，不允許創(chuàng)建新的對象。YGC結(jié)束后，系統(tǒng)繼續(xù)運(yùn)行，下一次如果E區(qū)滿了，就會再次觸發(fā)YGC，把E區(qū)和S0區(qū)里的存活對象轉(zhuǎn)移到S1區(qū)里去，然后直接清空掉E區(qū)和S0區(qū)中的垃圾對象

1.2 、那么對象什么時候去老年代呢？

1.2.1、對象的年齡

躲過15次YGC之后的對象晉升到老年代，默認(rèn)是15，這個值可以通過-XX:MaxTenuringThreshold設(shè)置

這個值設(shè)置的隨意調(diào)整會有什么問題？

現(xiàn)在java項目普遍采用Spring框架管理對象的生命周期。Spring默認(rèn)管理的對象都是單例的，這些對象是長期存活的應(yīng)該直接放到老年代中，應(yīng)該避免它們在年輕代中來回復(fù)制。調(diào)大晉升閥值會導(dǎo)致本該晉升的對象停留在年輕代中，造成頻繁YGC。但是如果設(shè)置的過小會導(dǎo)致程序中稍微存在耗時的任務(wù)，就會導(dǎo)致大量對象晉升到老年代，導(dǎo)致老年代內(nèi)存持續(xù)增長,不要盲目的調(diào)整晉升的閥值。

1.2.2、動態(tài)對象年齡判斷

JVM都會檢查S區(qū)中的對象，并記錄下每個年齡段的對象總大小。如果某個年齡段及其之前所有年齡段的對象總大小超過了S區(qū)的一半，則從該年齡段開始的所有對象在下一次GC時都會被晉升到老年代。假設(shè)S區(qū)可以容納100MB的數(shù)據(jù)。在進(jìn)行一次YGC后，JVM統(tǒng)計出如下數(shù)據(jù)：

?年齡1的對象總共占用了10MB。

?年齡2的對象總共占用了20MB。

?年齡3的對象總共占用了30MB。

此時，年齡1至3的對象總共占用了60MB，超過了S區(qū)一半的容量（50MB）。根據(jù)動態(tài)對象年齡判斷規(guī)則，所有年齡為3及以上的對象在下一次GC時都將被晉升到老年代，而不需要等到它們的年齡達(dá)到15。（注意：這里S區(qū)指的是S0或者S1的空間，而不是總的S，總的在這里是200MB）

這個機(jī)制使得JVM能夠根據(jù)實(shí)際情況動態(tài)調(diào)整對象的晉升策略，從而優(yōu)化垃圾收集的性能。通過這種方式，JVM盡量保持S區(qū)空間的有效利用，同時減少因年輕代對象過多而導(dǎo)致的頻繁GC。

1.2.3.大對象直接進(jìn)入老年代

如果對象的大小超過了預(yù)設(shè)的閾值（可以通過-XX:PretenureSizeThreshold參數(shù)設(shè)置），這個對象會直接在老年代分配，因為大對象在年輕代中經(jīng)常會導(dǎo)致空間分配不連續(xù)，從而提早觸發(fā)GC，避免在E區(qū)及兩個S區(qū)之間來回復(fù)制，減少垃圾收集時的開銷。

1.2.4.臨時晉升

在某些情況下，如果S區(qū)不足以容納一次YGC后的存活對象，這些對象也會被直接晉升到老年代，即使它們的年齡沒有達(dá)到晉升的年齡閾值。這是一種應(yīng)對空間不足的臨時措施。

1.3老年代的GC觸發(fā)時機(jī)

一旦老年代對象過多，就可能會觸發(fā)FGC（Full GC），F(xiàn)GC必然會帶著Old GC，也就是針對老年代的GC 而且一般會跟著一次YGC，也會觸發(fā)永久代的GC，但具體觸發(fā)條件和行為還取決于使用的垃圾收集器，文章的最后會簡單的介紹下垃圾收集器。

?Serial Old/Parallel Old

當(dāng)老年代空間不足以分配新的對象時，會觸發(fā)FGC，這包括清理整個堆空間，即年輕代和老年代。

?CMS

當(dāng)老年代的使用達(dá)到某個閾值（默認(rèn)情況下是68%）時，開始執(zhí)行CMS收集過程，嘗試清理老年代空間。如果在CMS運(yùn)行期間老年代空間不足以分配新的對象，可能會觸發(fā)一次Full GC。 啟動CMS的閾值參數(shù)：-XX:CMSInitiatingOccupancyFraction=75,-XX:+UseCMSInitiatingOccupancyOnly

?G1

G1收集器將堆內(nèi)存劃分為多個區(qū)域（Region），包括年輕代和老年代區(qū)域。當(dāng)老年代區(qū)域中的空間使用率達(dá)到一定比例（基于啟發(fā)式方法或者顯式配置的閾值）默認(rèn)45%時，G1會計劃并執(zhí)行Mixed GC，這種GC包括選定的一些老年代區(qū)域和所有年輕代區(qū)域的垃圾收集。

Mixed GC的閾值參數(shù)-XX:InitiatingHeapOccupancyPercent=40,-XX:MaxGCPauseMillis=200

2.JVM優(yōu)化調(diào)優(yōu)目標(biāo)：

2.1JVM調(diào)優(yōu)指標(biāo)

?低延遲（Low Latency）：GC停頓時間短。

?高吞吐量（High Throughput）：單位時間內(nèi)能處理更多的工作量。更多的是CPU資源來執(zhí)行應(yīng)用代碼，而非垃圾回收或其他系統(tǒng)任務(wù)。

?大內(nèi)存（Large Heap）：支持更大的內(nèi)存分配，可以存儲更多的數(shù)據(jù)和對象。在處理大數(shù)據(jù)集或復(fù)雜應(yīng)用時尤為重要，但大內(nèi)存堆帶來的挑戰(zhàn)是GC會更加復(fù)雜和耗時。

但是不同目標(biāo)在實(shí)現(xiàn)是本身時有沖突的，為什么難以同時滿足？

?低延遲 vs. 高吞吐量：要想減少GC的停頓時間，就需要頻繁地進(jìn)行垃圾回收，或者采用更復(fù)雜的并發(fā)GC算法，這將消耗更多的CPU資源，從而降低應(yīng)用的吞吐量。

?低延遲 vs. 大內(nèi)存：大內(nèi)存堆意味著GC需要管理和回收的對象更多，這使得實(shí)現(xiàn)低延遲的GC變得更加困難，因為GC算法需要更多時間來標(biāo)記和清理不再使用的對象。

?高吞吐量 vs. 大內(nèi)存：雖然大內(nèi)存可以讓應(yīng)用存儲更多數(shù)據(jù)，減少內(nèi)存管理的開銷，但是當(dāng)進(jìn)行全堆GC時，大內(nèi)存堆的回收過程會占用大量CPU資源，從而降低了應(yīng)用的吞吐量。

2.2如何權(quán)衡

在實(shí)際應(yīng)用中，根據(jù)應(yīng)用的需求和特性，開發(fā)者和運(yùn)維工程師需要在這三個目標(biāo)之間做出權(quán)衡：

2.2.1Web應(yīng)用和微服務(wù) - 低延遲優(yōu)先

場景描述：對于用戶交互密集的Web應(yīng)用和微服務(wù)，快速響應(yīng)是提供良好用戶體驗的關(guān)鍵。在這些場景中，低延遲比高吞吐量更為重要。

推薦收集器：大內(nèi)存應(yīng)用推薦G1，內(nèi)存偏小可以使用CMS，CMS曾經(jīng)是低延遲應(yīng)用的首選，因其并發(fā)回收特性而被廣泛使用。不過由于CMS在JDK 9中被標(biāo)記為廢棄，并在后續(xù)版本中被移除可以使用極低延遲ZGC或Shenandoah。這兩種收集器都設(shè)計為低延遲收集器，能夠在大內(nèi)存堆上提供幾乎無停頓的垃圾回收，從而保證應(yīng)用的響應(yīng)速度，但是支持這兩個回收器的JDK版本較高，在JDK8版本還是CMS和G1的天下。

2.2.2 大數(shù)據(jù)處理和科學(xué)計算 - 高吞吐量優(yōu)先

場景描述：大數(shù)據(jù)處理和科學(xué)計算應(yīng)用通常需要處理大量數(shù)據(jù)，對CPU資源的利用率要求極高。這類應(yīng)用更注重于高吞吐量，以完成更多的數(shù)據(jù)處理任務(wù)，而不是每個任務(wù)的響應(yīng)時間。

推薦收集器：Parallel GC。這是一種以高吞吐量為目標(biāo)設(shè)計的收集器，通過多線程并行回收垃圾，以最大化應(yīng)用吞吐量，非常適合CPU資源充足的環(huán)境。

2.2.3. 大型內(nèi)存應(yīng)用 - 大內(nèi)存管理優(yōu)先

場景描述：對于需要管理大量內(nèi)存的應(yīng)用，例如內(nèi)存數(shù)據(jù)庫和某些緩存系統(tǒng)，有效地管理大內(nèi)存成為首要考慮的因素。這類應(yīng)用需要垃圾回收器能夠高效地處理大量的堆內(nèi)存，同時保持合理的響應(yīng)時間和吞吐量。

推薦收集器：G1 GC或ZGC。G1 GC通過將堆內(nèi)存分割成多個區(qū)域來提高回收效率，適合大內(nèi)存應(yīng)用且提供了平衡的延遲和吞吐量。ZGC也適合大內(nèi)存應(yīng)用，提供極低的延遲，但可能需要對應(yīng)用進(jìn)行調(diào)優(yōu)以實(shí)現(xiàn)最佳性能。

3.JVM優(yōu)化一般是針對于兩種場景

3.1新應(yīng)用上線，通過預(yù)估核心接口流量進(jìn)行壓測，觀察JVM的GC情況并調(diào)優(yōu)

壓測需要觀察那些重要的指標(biāo)呢

?YGC與FGC頻率和耗時

?YGC過后多少對象存活

? 老年代的對象增長速率

通過jstat觀察出來上述JVM運(yùn)行指標(biāo)！

3.2老應(yīng)用通過監(jiān)控收到JVM異常反饋，或者程序出現(xiàn)下列問題進(jìn)行優(yōu)化

3.2.1應(yīng)用出現(xiàn)OutOfMemory等內(nèi)存異常

（1）堆內(nèi)存溢出 Java heap space

對象持續(xù)創(chuàng)建而不被回收或者來不及回收，導(dǎo)致堆內(nèi)存耗盡。

?超預(yù)期請求：面臨突發(fā)的高并發(fā)請求或處理大量數(shù)據(jù)時，創(chuàng)建了大量線程和對象，GC回收后的空間，不足以放下存活的對象就會造成OOM。需要我們做好流量控制和預(yù)估，然后針對這種情況提前擴(kuò)容或者限流。

?內(nèi)存泄漏：大量對象引用沒有釋放，JVM 無法對其自動回收，常見于使用了 File 等資源沒有回收，是否使用JDK線程池工具等，都是編碼異常需要導(dǎo)出dump文件針對代碼進(jìn)行分析。

?濫用緩存：本地緩存工具占用大量內(nèi)存，導(dǎo)致堆使用空間變小，需要合理設(shè)置緩存大小以及超時時間

?大量對象：再循環(huán)中創(chuàng)建大量對象導(dǎo)致堆內(nèi)存被占滿，避免在循環(huán)中創(chuàng)建對象。重復(fù)對象使用池化技術(shù)

?大對象或大數(shù)組：創(chuàng)建超大數(shù)組，上傳或者導(dǎo)出大文件，查詢不帶條件拖庫，編碼做好邊界限制，有一個良好的編碼習(xí)慣。

（2）元空間溢出 Metaspace

元空間的溢出通常是因為加載的 class 數(shù)目太多或體積太大

例如：動態(tài)生成大量Class對象，比如某些框架（如OSGi、ASM）動態(tài)生成大量的類，這些類占用的空間可能超過了元空間的限制，或者加載了大量的第三方庫，這些庫中包含的類和常量占用了大量的方法區(qū)空間。如果是正常類加載需要調(diào)大元空間-XX:MaxMetaspaceSize，否則需要導(dǎo)出DUMP文件，分析是否存在重復(fù)類

（3）虛擬機(jī)棧和本地方法棧溢出

線程請求的棧深度超過了虛擬機(jī)棧和本地方法棧允許的最大深度。這種情況通常發(fā)生在深度遞歸調(diào)用的情況下（-Xss參數(shù)設(shè)置棧的大?。?。

應(yīng)用創(chuàng)建了過多線程，超出了系統(tǒng)承載能力，尤其是在32位系統(tǒng)上，每個線程的?？臻g（默認(rèn)1MB）會占用一定的地址空間，可能會導(dǎo)致系統(tǒng)無法分配足夠的地址空間給新的線程。

（4）直接內(nèi)存溢出 Direct buffer memory

Java 允許應(yīng)用程序通過 Direct ByteBuffer 直接訪問堆外內(nèi)存，許多高性能程序通過 Direct ByteBuffer 結(jié)合內(nèi)存映射文件（Memory Mapped File）實(shí)現(xiàn)高速 IO。Direct ByteBuffer 的默認(rèn)大小為 64 MB

?檢查堆外內(nèi)存使用代碼,排查是否正確使用ByteBuffer.allocateDirect

?檢查是否直接或間接使用了 NIO，如 netty，jetty 等。

?通過啟動參數(shù) -XX:MaxDirectMemorySize 調(diào)整 Direct ByteBuffer 的上限值。

3.2.2 Heap內(nèi)存（老年代）持續(xù)上漲達(dá)到設(shè)置的最大內(nèi)存值；

老年代持續(xù)上漲是JVM優(yōu)化的重要指標(biāo)，但是老年代持續(xù)上漲有多種原因

內(nèi)存泄漏：最開始的表現(xiàn)也是老年代的持續(xù)上漲，觸發(fā)FGC無法回收拋出OOM，系統(tǒng)宕機(jī)！

正常情況：可能是因為流量徒增導(dǎo)致年輕代處理不過來，臨時移入老年代，執(zhí)行FGC后內(nèi)存明顯下降！

大對象：大對象直接分配在老年代，觸發(fā)FGC后內(nèi)存明顯下降！

年輕代的S區(qū)設(shè)置過小：E區(qū)正?；厥蘸蟠婊畹膶ο螅赟區(qū)放不下直接晉升到老年代，有一個大坑就是JAVA8默認(rèn)收集器Parallel Scavenge為了處理更大的吞吐量會動態(tài)調(diào)整S區(qū)，在線上運(yùn)行一段時間后S區(qū)會變得很小，導(dǎo)致大量對象進(jìn)入到老年代，我在優(yōu)化實(shí)戰(zhàn)中排查過這個問題

3.2.3 FGC 次數(shù)頻繁

頻繁進(jìn)行FGC如果出現(xiàn)OOM按照3.2.1進(jìn)行排查

頻繁FGC但是內(nèi)存能被回收按照3.2.2進(jìn)行排查

3.2.4 GC 停頓時間長

YGC停頓

可以看看這篇文章總結(jié)的挺好的：JVM性能調(diào)優(yōu)--YGC

FGC停頓

FGC的觸發(fā)一般是老年代或者元空間內(nèi)存不足，F(xiàn)GC執(zhí)行本身是比較耗時的操作，會回收整個堆內(nèi)存以及元空間，我們在優(yōu)化JVM盡量避免FGC，或者盡量少的FGC。FGC停頓指標(biāo)需要結(jié)合FGC執(zhí)行頻率，以及歷史執(zhí)行時間來看如果是因為內(nèi)存空間大導(dǎo)致回收慢可以選擇G1針對大內(nèi)存進(jìn)行處理

總結(jié)：

JVM優(yōu)化沒有拿過來直接用的方案，所有好的JVM優(yōu)化方案都是在當(dāng)前應(yīng)用背景下的，還是開頭那句話 JVM調(diào)優(yōu)不是常規(guī)手段，如果沒有發(fā)現(xiàn)問題盡量不主動優(yōu)化JVM，但是一定要了解應(yīng)用的JVM運(yùn)行情況，這時候好的監(jiān)控就顯得格外重要。

那么好的JVM應(yīng)該是什么樣的呢？簡單的說就是盡量讓每次YGC后的存活對象小于S區(qū)域的50%，都留存在年輕代里。盡量別讓對象進(jìn)入老年代。盡量減少FGC的頻率，避免頻繁FGC對JVM性能的影響。

了解了JVM優(yōu)化的基本原理之后，實(shí)戰(zhàn)就需要在日常中積累了，墨菲定律我覺得在這個場景很適用，不要相信線上的機(jī)器是穩(wěn)定的，如果觀察到監(jiān)控有異常，過一會可能恢復(fù)了就不了了之，要敢于去排查問題，未知的總是令人恐懼的，在排查的過程中會加深自己對JVM的理解的同時，也會對應(yīng)用更有信心。

4.線上優(yōu)化實(shí)戰(zhàn)：

元空間OOM導(dǎo)致持續(xù)fullgc線上分析

線上機(jī)器JVM內(nèi)存持續(xù)走高的排查

審核編輯 黃宇