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

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

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

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

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

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

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

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

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

1.1 年輕代回收原理

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

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

1.2.1、對象的年齡

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

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

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

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

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

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

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

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

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

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

1.2.3.大對象直接進入老年代

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

1.2.4.臨時晉升

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

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

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

?Serial Old/Parallel Old

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

?CMS

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

?G1

G1收集器將堆內(nèi)存劃分為多個區(qū)域（Region），包括年輕代和老年代區(qū)域。當老年代區(qū)域中的空間使用率達到一定比例（基于啟發(fā)式方法或者顯式配置的閾值）默認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)目標：

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

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

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

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

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

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

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

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

2.2如何權(quán)衡

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

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

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

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

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

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

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

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

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

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

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

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

壓測需要觀察那些重要的指標呢

?YGC與FGC頻率和耗時

?YGC過后多少對象存活

? 老年代的對象增長速率

通過jstat觀察出來上述JVM運行指標！

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

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

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

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

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

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

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

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

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

（2）元空間溢出 Metaspace

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

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

（3）虛擬機棧和本地方法棧溢出

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

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

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

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

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

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

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

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

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

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

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

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

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

3.2.3 FGC 次數(shù)頻繁

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

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

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停頓指標需要結(jié)合FGC執(zhí)行頻率，以及歷史執(zhí)行時間來看如果是因為內(nèi)存空間大導致回收慢可以選擇G1針對大內(nèi)存進行處理

總結(jié)：

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

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

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

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

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

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

審核編輯 黃宇