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

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

針對(duì)JAVA8的模型進(jìn)行討論，JVM的內(nèi)存模型主要分為幾個(gè)關(guān)鍵區(qū)域：堆、方法區(qū)、程序計(jì)數(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)來看一個(gè)對(duì)象的生命周期，對(duì)JVM的回收有一個(gè)概念，其中弱化堆棧和程序計(jì)數(shù)器

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

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

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

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

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

1.1 年輕代回收原理

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

1.2 、那么對(duì)象什么時(shí)候去老年代呢？

1.2.1、對(duì)象的年齡

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

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

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

1.2.2、動(dòng)態(tài)對(duì)象年齡判斷

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

?年齡1的對(duì)象總共占用了10MB。

?年齡2的對(duì)象總共占用了20MB。

?年齡3的對(duì)象總共占用了30MB。

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

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

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

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

1.2.4.臨時(shí)晉升

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

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

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

?Serial Old/Parallel Old

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

?CMS

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

?G1

G1收集器將堆內(nèi)存劃分為多個(gè)區(qū)域（Region），包括年輕代和老年代區(qū)域。當(dāng)老年代區(qū)域中的空間使用率達(dá)到一定比例（基于啟發(fā)式方法或者顯式配置的閾值）默認(rèn)45%時(shí)，G1會(huì)計(jì)劃并執(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停頓時(shí)間短。

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

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

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

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

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

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

2.2如何權(quán)衡

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

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

場景描述：對(duì)于用戶交互密集的Web應(yīng)用和微服務(wù)，快速響應(yīng)是提供良好用戶體驗(yàn)的關(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è)計(jì)為低延遲收集器，能夠在大內(nèi)存堆上提供幾乎無停頓的垃圾回收，從而保證應(yīng)用的響應(yīng)速度，但是支持這兩個(gè)回收器的JDK版本較高，在JDK8版本還是CMS和G1的天下。

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

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

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

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

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

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

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

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

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

?YGC與FGC頻率和耗時(shí)

?YGC過后多少對(duì)象存活

? 老年代的對(duì)象增長速率

通過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

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

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

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

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

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

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

（2）元空間溢出 Metaspace

元空間的溢出通常是因?yàn)榧虞d的 class 數(shù)目太多或體積太大

例如：動(dòng)態(tài)生成大量Class對(duì)象，比如某些框架（如OSGi、ASM）動(dòng)態(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）會(huì)占用一定的地址空間，可能會(huì)導(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 等。

?通過啟動(dòng)參數(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ī)！

正常情況：可能是因?yàn)榱髁客皆鰧?dǎo)致年輕代處理不過來，臨時(shí)移入老年代，執(zhí)行FGC后內(nèi)存明顯下降！

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

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

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 停頓時(shí)間長

YGC停頓

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

FGC停頓

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

總結(jié)：

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

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

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

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

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

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

審核編輯 黃宇