[[340168]]

本文轉(zhuǎn)載自微信公眾號(hào)「Shooter茶杯」，作者Shooter。轉(zhuǎn)載本文請(qǐng)聯(lián)系Shooter茶杯公眾號(hào)。  

抱歉很久沒(méi)寫(xiě)新文章了 , 這段時(shí)間一直在學(xué)習(xí)擴(kuò)大自己的知識(shí)盲區(qū) , 工作上也挺忙的 , 拖更了好久

答應(yīng)了朋友要出個(gè) JVM 系列 , 應(yīng)該會(huì)有幾篇文章 , 我會(huì)努力在保證質(zhì)量的前提下進(jìn)行輸出~

So 進(jìn)入今天的主題

前言

有被 JVM 相關(guān)問(wèn)題刁難過(guò)嗎?

上個(gè)月朋友去面某東說(shuō)被 JVM 難哭了

面試官上來(lái)就是素質(zhì)三連:

有沒(méi)有 高并發(fā)項(xiàng)目經(jīng)驗(yàn)、頻繁 gc 怎么解決、有沒(méi)有搞過(guò) JVM 調(diào)優(yōu)

我那個(gè)朋友公司做的是 to b 方向 , 系統(tǒng)流量不是很大 , 加上才工作 2 年直接被問(wèn)懵逼

回來(lái)就問(wèn)我高并發(fā)系統(tǒng)怎么玩 , 為了避免重復(fù)勞動(dòng) , 遂有此文~

一、億級(jí)流量系統(tǒng)回顧

接下來(lái)做個(gè)回顧：

OTA 平臺(tái) 4億 用戶

高峰期 百萬(wàn) 訂單

高峰期 12 小時(shí) 1.8億 訪問(wèn)量

每小時(shí)的流量是：1.8億 / 12 = 1250w

每分的流量是：1250w / 60 = 20.8w

每秒的流量是：20.8w / 60 = 3472

2 個(gè)集群 32 臺(tái) 8C/16G 的機(jī)器

一次核心接口查詢平均占用 5mb 內(nèi)存

每秒鐘 JVM 會(huì)有 550mb 的新生代堆內(nèi)存空間被占用

二、系統(tǒng)的 JVM 參數(shù)

基于G1垃圾收集器

這里我截取了這個(gè)服務(wù)生產(chǎn)環(huán)境的 JVM 參數(shù)：

1. -Xmx12288m 初始堆大小.
2. -Xms12288m 最大堆大小
3. -Xss256k 每個(gè)線程的棧內(nèi)存大小
4. -XX:MetaspaceSize=256m 元空間初始大小
5. -XX:MaxMetaspaceSize=1g 元空間最大大小
6. -XX:MaxGCPauseMillis=200 每次YGC / MixedGC 的最多停頓時(shí)間 (期望最長(zhǎng)停頓時(shí)間)
7. -XX:+UseG1GC java8 指定使用G1垃圾回收器
8. -XX:-OmitStackTraceInFastThrow 對(duì)異常做的一個(gè)優(yōu)化，拋出異常非常快，但是看不到異常的堆棧信息(僅供參考)
9. -XX:MinHeapFreeRatio=30 GC后java堆中空閑量占的最小比例，小于該值，則堆內(nèi)存會(huì)增加
10. -XX:MaxHeapFreeRatio=50 GC后java堆中空閑量占的最大比例，大于該值，則堆內(nèi)存會(huì)減少
11. -XX:CICompilerCount=4 設(shè)置的相對(duì)較大可以一定程度提升JIT編譯的速度，默認(rèn)為2
12. -XX:SoftRefLRUPolicyMSPerMB=0 任何軟引用對(duì)象在下一次 GC 都盡快釋放掉，給內(nèi)存釋放空間。
13. -XX:+PrintGC 輸出GC日志
14. -XX:+PrintGCDetails 輸出GC的詳細(xì)日志
15. -XX:+PrintGCDateStamps 輸出GC的時(shí)間戳(以基準(zhǔn)時(shí)間的形式)
16. -XX:+UseGCLogFileRotation 開(kāi)或關(guān)閉GC日志滾動(dòng)記錄功能
17. -XX:NumberOfGCLogFiles=5 設(shè)置滾動(dòng)日志文件的個(gè)數(shù)
18. -XX:GCLogFileSize=32M 設(shè)置滾動(dòng)日志文件的大小，當(dāng)前寫(xiě)日志文件大小超過(guò)該參數(shù)值時(shí)，日志將寫(xiě)入下一個(gè)文件
19. -XX:+HeapDumpOnOutOfMemoryError JVM會(huì)在遇到OutOfMemoryError時(shí)拍攝一個(gè)堆轉(zhuǎn)儲(chǔ)快照，并將其保存在一個(gè)文件中

注意

-XX:SoftRefLRUPolicyMSPerMB=0 這個(gè)參數(shù)在某些情況下會(huì)造成元空間 OOM ,一般最好給個(gè) 2000 / 5000，

0 是經(jīng)過(guò)調(diào)優(yōu)確認(rèn)不會(huì)引起這個(gè)問(wèn)題才用。

為什么會(huì)造成 OOM 我會(huì)在以后的文章會(huì)中提到。

三、高并發(fā)下 JVM 是怎么玩的?

堆空間怎么分配內(nèi)存?

雖然給堆空間分配了 12G 的內(nèi)存，但新生代并不是一開(kāi)始就把這 12G 一下就占滿了，老年代還得占一部分。

也不是一開(kāi)始就將新老生代按個(gè)比例分配好空間，新生代一開(kāi)始只會(huì)分配 5% 的堆內(nèi)存空間，然后慢慢的增大，

這個(gè)是可以通過(guò) -XX:G1NewSizePercent 來(lái)設(shè)置新生代初始占比的，其實(shí)維持這個(gè)默認(rèn)值就可以了

同樣老年代也是，并不是以開(kāi)始就分配幾個(gè)G ;因?yàn)?G1 是基于 Region 的邏輯來(lái)分區(qū)的。

到底多久會(huì)觸發(fā)一次新生代的 YoungGC(ygc)?

有人說(shuō)：新生代的 Eden 區(qū)空間不夠用了就會(huì)觸發(fā) ygc 那到底 Eden區(qū)使用多少了才是內(nèi)存不夠呢?

有一個(gè)參數(shù) -XX:G1MaxNewSizePercent 默認(rèn)值：60% ，限定了新生代最多占用堆內(nèi)存 60% 的空間，

那就是是 12G * 60% = 7.2G，然后 新生代又有 Eden 和 兩個(gè) Survivor 組成 默認(rèn)比例是： 8:1:1,

7.2G * 0.8 = 5.76G ， 是 Eden 區(qū)快到 5.7G 就觸發(fā) ygc 么?

并不是，G1 有個(gè)很重要的參數(shù) -XX:MaxGCPauseMillis 這個(gè)參數(shù)的默認(rèn)值是 200

意味著每次 進(jìn)行垃圾回收，最長(zhǎng)的停頓時(shí)間不超過(guò) 200ms。這也是為什么 G1 號(hào)稱它造成的 STW 是停頓可控的。

做個(gè)大膽的假設(shè)： 200ms G1可以回收 300個(gè)Region 區(qū)域!

因?yàn)?G1 是在邏輯上區(qū)分 老年代和新生代的，整個(gè)堆被分成了 2048 個(gè) Region 區(qū)域，12G 的堆內(nèi)存平均每個(gè) Region 的大小是 6MB

但 Region 的大小必須是 2的 N次冪，所以每個(gè) Region 的大小會(huì)是 8mb

之前算出來(lái)了這個(gè)系統(tǒng)每秒鐘往新生代輸送的對(duì)象大小是 550mb ，550mb / 8mb = 68 ，平均每秒會(huì)有 68 個(gè) Region 被占滿，

回收 300 個(gè) Region 需要 200ms ， 300 / 68 = 4.5ms ，

大概 4.5ms 就會(huì)進(jìn)行一次 ygc ，一分鐘就會(huì)進(jìn)行 13 次 ygc ,每次 ygc 200ms

這樣分析就會(huì)發(fā)現(xiàn) G1 的垃圾回收其實(shí)是很動(dòng)態(tài)，很靈活的，它會(huì)根據(jù)你對(duì) GC 的預(yù)期停頓時(shí)間來(lái)進(jìn)行回收。

G1 哪些對(duì)象會(huì)進(jìn)入老年代?

1. 一個(gè)對(duì)象在年輕代里躲過(guò)15次垃圾回收，年齡太大了，壽終正寢，進(jìn)入老年代
2. 大對(duì)象直接送到老年代 參數(shù) XX:PretenureSizeThreshold 來(lái)控制多大的對(duì)象才算大。XX:PretenureSizeThreshold=100000000 單位為btye
3. 動(dòng)態(tài)年齡判定規(guī)則，如果一旦發(fā)現(xiàn)某次新生代 GC 過(guò)后，存活對(duì)象超過(guò)了 Survivor 50%
4. 一次 ygc 過(guò)后存活對(duì)象太多了，導(dǎo)致 Survivor 區(qū)域放不下了，這批對(duì)象會(huì)進(jìn)入老年代

這個(gè)接口的耗時(shí)一般在 200ms 左右，但在高并發(fā)情況下，內(nèi)存資源這么吃緊，CPU 和 線程資源都會(huì)有很高的負(fù)載，這時(shí)候就很有可能出現(xiàn)一些性能抖動(dòng)的情況

相應(yīng)的表現(xiàn)就是接口的響應(yīng)時(shí)間延長(zhǎng),甚至?xí)霈F(xiàn)超時(shí)，在頻繁的 fgc 情況下：

1. 一些對(duì)象在 Survivor區(qū) 經(jīng)過(guò) 15 次 ygc 后，就會(huì)晉升到老年代
2. 很多接口的響應(yīng)時(shí)間都延長(zhǎng)，導(dǎo)致觸發(fā)動(dòng)態(tài)年齡判斷規(guī)則，就會(huì)有一大批對(duì)象晉升到老年代，

看起來(lái)這么大的內(nèi)存，Survivor區(qū) 也足夠大，這個(gè)晉升規(guī)則也比較嚴(yán)格，但是高并發(fā)的場(chǎng)景下，上面這個(gè)流程只要反復(fù)的來(lái)幾次

老年代的對(duì)象就會(huì)越來(lái)越多

什么是 Mixed GC (混合回收)?

因?yàn)?G1 是基于 Region 的，并沒(méi)有嚴(yán)格的區(qū)分老年代新生代，

G1有一個(gè)參數(shù)，XX:InitiatingHeapOccupancyPercent ，它的默認(rèn)值是 45% ,意思就是說(shuō)，如果 老年代 占據(jù)了堆內(nèi)存的 45% 的 Region 的時(shí)候，此時(shí)就會(huì)嘗試觸發(fā)一個(gè)新生代+老年代一起回收的混合回收。

什么時(shí)候發(fā)生 Full GC(fgc) ?

異常情況

1. 大對(duì)象太多，對(duì)象都跑老年代去了，老年代內(nèi)存吃緊會(huì)觸發(fā) fgc ，如果fgc 內(nèi)存還是不夠使用，那再申請(qǐng)內(nèi)存的時(shí)候就會(huì)拋出 OOM 異常，然后再 fgc 如此往復(fù)循環(huán)，系統(tǒng)并不會(huì)直接掛掉，表現(xiàn)是系統(tǒng)假死，非?？D，用戶體驗(yàn)極差。
2. 元空間、直接內(nèi)存這些區(qū)域快滿了都會(huì)觸發(fā) fgc

后續(xù) 堆空間、元空間、直接內(nèi)存(堆外內(nèi)存) OOM 都會(huì)有真實(shí)的生產(chǎn)環(huán)境案例 敬請(qǐng)期待

正常情況

1. fgc 都知道是一個(gè)很耗時(shí)的操作 , G1 正常的工作狀態(tài)是沒(méi)有 Full GC 概念的，老年代垃圾的收集任務(wù)全靠 Mixed GC 來(lái)處理。
2. 不過(guò)在進(jìn)行 Mixed 回收的時(shí)候，無(wú)論是年輕代還是老年代都基于復(fù)制算法進(jìn)行回收，都要把各個(gè) Region 的存活對(duì)象拷貝到別的 Region 里去，
3. 此時(shí)萬(wàn)一出現(xiàn)拷貝的過(guò)程中發(fā)現(xiàn)沒(méi)有空閑 Region 可以承載自己的存活對(duì)象了，就會(huì)觸發(fā)一次失敗。一旦失敗，立馬就會(huì)切換為停止系統(tǒng)程序，切換到 G1 之外的 Serial Old GC 來(lái)收集整個(gè)堆(包括 Young、Old、Metaspace )這才是真正的 Full GC(Full GC不在G1的控制范圍內(nèi))
4. 進(jìn)入這種狀態(tài)的G1就跟使用參數(shù) -XX:+UseSerialGC 的 Full GC 一樣(背后的核心邏輯是一樣的)。然后采用單線程進(jìn)行標(biāo)記、清理和壓縮整理，空閑出來(lái)一批 Region ，使用單線程的進(jìn)行 gc 這個(gè)過(guò)程是極慢極慢的。
5. 這也是 JVM 調(diào)優(yōu)的關(guān)鍵所在，務(wù)必不要讓你的系統(tǒng)觸發(fā) Full GC !

補(bǔ)充

-XX:MaxGCPauseMillis = 200 是一個(gè)默認(rèn)值，停頓 200ms 也不算久，但一個(gè)高并發(fā)系統(tǒng)如果要求低延遲，快速響應(yīng)

這個(gè)值就要再調(diào)低一點(diǎn)了，但是仍然不建議去把這個(gè)值改小，

很多時(shí)候設(shè)置的 200ms， 實(shí)際上也只有 20 - 80ms ，這是我觀察過(guò)不下 30 個(gè)生產(chǎn)環(huán)境的 GC 得出來(lái)的結(jié)論。

跟做性能測(cè)試的大佬也討論過(guò)這個(gè)的原因：G1 是一個(gè) 動(dòng)態(tài)、靈活、自主、性能還不錯(cuò) 的垃圾收集器

如果設(shè)置太小 ，可能導(dǎo)致每次 Mixed GC or ygc 只能回收很小一部分 Region ，最終可能無(wú)法跟上程序分配內(nèi)存的速度

從而觸發(fā) Full GC 所以很多系統(tǒng)并沒(méi)有去把這個(gè)值改成 50 或是 100

如果設(shè)置太大 ，那么可能 G1 會(huì)允許你不停的在新生代理分配新的對(duì)象，然后積累了很多對(duì)象，再一次性回收幾百個(gè) Region

此時(shí)可能一次 GC 停頓時(shí)間就會(huì)達(dá)到幾百毫秒，但是 GC 的頻率很低。

比如說(shuō) 30 分鐘才觸發(fā)一次新生代 GC，但是每次停頓 500ms ,毫無(wú)疑問(wèn)， 500ms 對(duì)于一個(gè)高并發(fā)的系統(tǒng)來(lái)說(shuō)實(shí)在是太久了

四、JVM 調(diào)優(yōu)該怎么做?

主要優(yōu)化在新生代

新生代gc如何優(yōu)化?

對(duì)于G1而言，我們首先應(yīng)該給整個(gè)JVM的堆區(qū)域足夠的內(nèi)存，其次就是給新生代足夠的內(nèi)存，保證:

• 不要讓對(duì)象經(jīng)歷 15 次垃圾回收從而進(jìn)入老年代
• 不要讓 Survivor 太小，從而觸發(fā)動(dòng)態(tài)年齡判斷，也要保證每次 ygc 后 Survivor 都能夠放下存活的對(duì)象

之前我們算過(guò)，這個(gè)系統(tǒng)每分鐘會(huì)有 550mb 的對(duì)象會(huì)進(jìn)入新生代 , 4.5s 就會(huì)來(lái)一次 ygc ,

一分鐘會(huì)有 13 次左右的 gc , 每次 gc 大概在 200ms 以內(nèi)。

PS : G1 回收只有初始標(biāo)記和重新標(biāo)記的階段是 stw，其他階段都是并發(fā)的，

gc 200ms , 真正 stw 的時(shí)間可能只是 幾十 ~ 一百ms

不過(guò)!每分鐘 13次 的 ygc 頻率，每次接近 200ms 左右耗時(shí) gc 效率實(shí)在太低了

新生代優(yōu)化

因?yàn)橛?記憶集 (RSet) 的存在，在 G1 回收 Region 效率不變的情況下 , 優(yōu)化的點(diǎn)就來(lái)了

擴(kuò)大每個(gè) Region 的大小 , 也就是擴(kuò)大堆內(nèi)存的大小 , 簡(jiǎn)而言之就是升級(jí)機(jī)器的內(nèi)存 或者是 集群進(jìn)行擴(kuò)容增加服務(wù)器的數(shù)量

目前這個(gè)業(yè)務(wù)系統(tǒng)只有 32 臺(tái)機(jī)器 8C 16G的機(jī)器 , 給堆空間的大小只有 12G , 對(duì)億級(jí)的流量還是不太能抗住 ,

目前階段性的分析后 , 性能瓶頸不在 CPU , 我們只需要升級(jí)內(nèi)存即可

升級(jí)到 8C 32G 給堆 24~26G 的空間 , 元空間給 1G 則機(jī)器數(shù)量不變 升級(jí)到 16C 64G 給堆 58~60G 的空間 , 元空間給 1G 還可以下幾臺(tái)機(jī)器

為什么會(huì)發(fā)生 Mixed gc ?

對(duì)于 Mixed gc 的觸發(fā)，大家都知道是老年代在堆內(nèi)存里占比超過(guò) 45% 就會(huì)觸發(fā)

再回顧一下：年輕代的對(duì)象進(jìn)入老年代的幾個(gè)條件：

1. 新生代 gc 過(guò)后存活對(duì)象太多沒(méi)法放入 Survivor 區(qū)域
2. 對(duì)象年齡太大
3. 動(dòng)態(tài)年齡判定規(guī)則

其中尤其關(guān)鍵的是新生代 gc 過(guò)后存活對(duì)象過(guò)多無(wú)法放入 Survivor 區(qū)域 , 以及動(dòng)態(tài)年齡判定規(guī)則這兩個(gè)條件尤其可能 讓很多對(duì)象快速進(jìn)入老年代

一旦老年代頻繁達(dá)到占用堆內(nèi)存 45% 的閾值 , 那么就會(huì)頻繁觸發(fā) Mixed gc

那我們的目標(biāo)就是 :

盡量避免對(duì)象過(guò)快進(jìn)入老年代 ， 盡量避免頻繁觸發(fā) mixed gc , 就可以做到根本上優(yōu)化 mixed gc 了

Mixed gc 優(yōu)化思路

Mixed gc 優(yōu)化的核心還是 -XX:MaxGCPauseMills 這個(gè)參數(shù)

大家可以想一下 , 假設(shè) -XX:MaxGCPauseMills 參數(shù)設(shè)置的值很大 , 導(dǎo)致系統(tǒng)運(yùn)行很久

新生代可能都占用了堆內(nèi)存的 70% 了 , 此時(shí)才觸發(fā)新生代 gc

那么存活下來(lái)的對(duì)象可能就會(huì)很多 , 此時(shí)就會(huì)導(dǎo)致 Survivor 區(qū)域放不下那么多的對(duì)象 , 就會(huì)進(jìn)入老年代中

或者是新生代 gc 過(guò)后 , 存活下來(lái)的對(duì)象過(guò)多 , 導(dǎo)致進(jìn)入 Survivor 區(qū)域后觸發(fā)了動(dòng)態(tài)年齡判定規(guī)則

達(dá)到了 Survivor 區(qū)域的 50% , 也會(huì)快速導(dǎo)致一些對(duì)象進(jìn)入老年代

所以這里核心還是在于調(diào)節(jié) -XX:MaxGCPauseMills 這個(gè)參數(shù)的值 , 在保證新生代 gc 別太頻繁的同時(shí) , 還得考慮每次 gc 過(guò)后的存活對(duì)象有多少

避免存活對(duì)象太多快速進(jìn)入老年代，頻繁觸發(fā) Mixed gc

五、實(shí)際有效的調(diào)優(yōu)參數(shù)

1.-XX:MaxGCPauseMillis: 根據(jù)系統(tǒng)可以接受的響應(yīng)時(shí)長(zhǎng)和指標(biāo) 觀察 JVM 的回收時(shí)間來(lái)進(jìn)行修改 單位：ms

太小跟不上分配內(nèi)存的速度 , 太大 gc 的時(shí)間太長(zhǎng)。

2.-XX:ParallelGCThreads: 在 stw 階段工作的 GC 線程數(shù) , 可以根據(jù)當(dāng)前機(jī)器 CPU 核數(shù)來(lái)設(shè)置 , 建議核心數(shù) -1

-XX:ConcGCThreads： 在非 stw 階段工作的 GC 線程數(shù) , 會(huì)影響系統(tǒng)的吞吐量 , 畢竟是要跟用戶線程搶 CPU 資源

系統(tǒng)如果是計(jì)算密集型的建議是 CPU 核數(shù)的 1/4 ~ 1/3 , iO 密集型建議是 1/2

3.-XX:G1ReservePercent： G1為分配擔(dān)保預(yù)留的空間比例 也就是老年代留多少空間給 新生代來(lái)晉升 , 默認(rèn)是 10%

如果晉升失敗會(huì)觸發(fā)單線程的 old gc 非?？植?, 建議高并發(fā)系統(tǒng)加大機(jī)器內(nèi)存 提高這個(gè)參數(shù)的比例

4.-XX:MaxMetaspaceSize： 元空間最大大小 , 在高并發(fā)且機(jī)器內(nèi)存夠的情況 建議增大元空間的大小

稍微大的點(diǎn)系統(tǒng)都會(huì)有很多依賴的組件，這些組件底層都有可能會(huì)用到一些反射 或者 字節(jié)碼框架 , 會(huì)生成一些你看不懂類名的類

一旦第三方框架出現(xiàn)問(wèn)題 , 你的系統(tǒng)很有可能也會(huì)受影響

調(diào)大元空間 , 有監(jiān)控系統(tǒng)的設(shè)置報(bào)警機(jī)制 , 給自己系統(tǒng)爭(zhēng)取一些緩沖時(shí)間也是有必要的

5.-XX:TraceClassLoading -XX:TraceClassUnloading

追蹤類加載和類卸載的情況 , 可以在 Tomcat 的 catalina.out 日志文件中

打印出來(lái)JVM中加載了哪些類，卸載了哪些類

6.-XX:SoftRefLRUPolicyMSPerMB: JVM 可以忍受多久 軟引用不被回收

如果是 0 則每次都會(huì)把軟引用回收掉釋放內(nèi)存

有一個(gè)情況是反射在 15 次后會(huì)動(dòng)態(tài)生成一些軟引用類來(lái)提高反射的效率 , 當(dāng) ygc 的時(shí)候把這些軟應(yīng)用給回收了

但是它們的類加載器或者一些奇怪名字的類還在元空間 , 那下次要用這個(gè)反射對(duì)象的時(shí)候又得重新創(chuàng)建

就造成了元空間慢慢無(wú)限增大從而觸發(fā) OOM , 建議這個(gè)參數(shù)設(shè)置 2000 - 5000 單位是: ms

7.-XX：+DisableExplicitGC: 關(guān)閉顯示的調(diào)用 System.gc() , System.gc() 是觸發(fā)類似 full gc 的操作

開(kāi)啟 or 關(guān)閉 有兩個(gè)情況

關(guān)閉: 防止 team 里有剛?cè)肼毜男√觳艑?xiě)完一個(gè)業(yè)務(wù)邏輯就給你來(lái)一個(gè) System.gc() 來(lái)優(yōu)化內(nèi)存 (別問(wèn) 問(wèn)那個(gè)小天才就是我)

開(kāi)啟: 項(xiàng)目里面有 Nio 相關(guān)的操作會(huì)用到直接內(nèi)存 , 在 Java 中是 DirecByteBuffer 對(duì)象來(lái)申請(qǐng)的

在某些不合理的情況下導(dǎo)致控制這塊區(qū)域的 DirecByteBuffer 會(huì)晉升到老年代

Nio 在申請(qǐng)堆外內(nèi)存空間不足的時(shí)候會(huì)手動(dòng)調(diào)用 System.gc() 去回收 DirecByteBuffer 堆外內(nèi)存

有用到 Nio 的系統(tǒng)把這個(gè)參數(shù)關(guān)掉是有一定概率發(fā)生 Direct buffer memory 的

關(guān)閉還是打開(kāi)取決于你自己的系統(tǒng) , 以及能不能做到 code review 不讓程序員自己去顯示的調(diào)用 System.gc()

8.-XX:G1MixedGCCountTarget: 設(shè)置垃圾回收混合回收階段，最多可以拆成幾次回收

G1 的垃圾回收是分為 初始標(biāo)記、并發(fā)標(biāo)記、最終標(biāo)記、混合回收 這幾個(gè)階段的

其中混合回收是可以并發(fā)的反復(fù)回收多次 , 這樣的好處是避免單次停頓回收 stw 時(shí)間太長(zhǎng)

停止系統(tǒng)一會(huì)兒 , 回收掉一些 Region , 再讓系統(tǒng)運(yùn)行一會(huì)兒 , 然后再次停止系統(tǒng)一會(huì)兒 , 再次回收掉一些 Region

這樣可以盡可能讓系統(tǒng)不要停頓時(shí)間過(guò)長(zhǎng) , 可以在多次回收的間隙 , 也運(yùn)行一下

在一定程度上可以防止部分接口相應(yīng)超時(shí)

六、小結(jié)

相信你看到這里 , 應(yīng)該對(duì)高并發(fā)系統(tǒng)中 對(duì)象如何吃 JVM 內(nèi)存 頻繁 遇到 gc 如何解決 已經(jīng)有所了解了 。

盡管有效的解決辦法仍然是加機(jī)器 , 但是加多少臺(tái)機(jī)器 , 怎么加機(jī)器 , JVM 參數(shù)要如何設(shè)置都有所了解了。