[[399065]]

本文只介紹一些原理和思路的內(nèi)容，希望對你與所幫助!

先了解原理，然后在進(jìn)行調(diào)優(yōu)。

一定要記住的是任何的調(diào)優(yōu)都不是一蹴而就，不要指望改動(dòng)一個(gè)參數(shù)就達(dá)到調(diào)優(yōu)的目的，也不要僅僅改動(dòng)了一個(gè)參數(shù)，就認(rèn)為是做了調(diào)優(yōu)。調(diào)優(yōu)是在已有的資源和要達(dá)到的目標(biāo)的前提上，進(jìn)行權(quán)衡。

從類加載到整個(gè)JVM的運(yùn)行周期內(nèi)大致流程和結(jié)構(gòu)如下：

從上圖可以看到，JVM 可以劃分為這些部分：

執(zhí)行引擎，包括：GC、JIT 編譯器

類加載子系統(tǒng)，這部分的問題，一般在開發(fā)過程中出現(xiàn)

JNI 部分，這部分問題一般在 JVM 之外

運(yùn)行時(shí)數(shù)據(jù)區(qū);Java 將內(nèi)存分為 2 大塊：堆內(nèi)存和棧內(nèi)存

首先我們要對上述的內(nèi)容有一定的了解，從全局出發(fā)?？戳松蠄D，在調(diào)優(yōu)中我們能做的也就是對運(yùn)行時(shí)數(shù)據(jù)區(qū)進(jìn)行一些操作，然后選擇執(zhí)行引擎用何種垃圾收集器對垃圾進(jìn)行回收。

1、本文調(diào)優(yōu)思路只針對JVM1.8，先看下JVM1.8內(nèi)存模型

注意：JVM 線程占用的是系統(tǒng)空間，所以當(dāng)JVM的堆內(nèi)存越大，系統(tǒng)本身的內(nèi)存就越少，自然可生成的線程數(shù)量就越少。

2、JVM調(diào)優(yōu)，主要從兩個(gè)方面考慮：堆內(nèi)存大小配置和垃圾回收算法選擇

# 設(shè)置堆內(nèi)存 
-Xmx4g -Xms4g  
# 指定 GC 算法 
-XX:+UseG1GC -XX:MaxGCPauseMillis=50  
# 指定 GC 并行線程數(shù) 
-XX:ParallelGCThreads=4  
# 打印 GC 日志 
-XX:+PrintGCDetails -XX:+PrintGCDateStamps  
# 指定 GC 日志文件 
-Xloggc:gc.log  
# 指定 Meta 區(qū)的最大值 
-XX:MaxMetaspaceSize=2g  
# 設(shè)置單個(gè)線程棧的大小 
-Xss1m  
# 指定堆內(nèi)存溢出時(shí)自動(dòng)進(jìn)行 Dump 
-XX:+HeapDumpOnOutOfMemoryError  
-XX:HeapDumpPath=/usr/local 

3、JVM - GC類型組合以及適用場合

垃圾回收，分為Young區(qū)垃圾回收器，以及Old區(qū)垃圾回收器兩部分，兩部分需要組合使用：

新生代收集器：Serial、ParNew、Parallel Scavenge;

老年代收集器：Serial Old、Parallel Old、CMS;

serial：新生代收集器，是最早出現(xiàn)最成熟的收集器，單線程，獨(dú)占式，GC時(shí)會stop the world 應(yīng)用暫停。

ParNew ：新生代收集器，是Serial 收集器的多線程版本，獨(dú)占式，同樣地GC時(shí)會stop the world 應(yīng)用暫停。

Parallel Scavenge：新生代收集器， 獨(dú)占式， 與ParNew相似，特點(diǎn)：吞吐量優(yōu)先

CMS：(concurrent-mark-sweep)，老年代收集器，非獨(dú)占式，多個(gè)線程，標(biāo)記并清除算法，響應(yīng)時(shí)間優(yōu)先，缺點(diǎn)是GC后不進(jìn)行內(nèi)存整理，會有內(nèi)存碎片。

Serial Old：是Serial 的老年代版本，同樣是單線程收集器， 獨(dú)占式

Parallel Old 是Parallel Scavenge 收集器的老年代版本，多線程收集， 獨(dú)占式

G1：備受期待的新一代垃圾收集器，可預(yù)測的停頓：這又是G1相對于CMS的一大優(yōu)勢，結(jié)合了Parallel Scavenge以及CMS兩種收集器的優(yōu)點(diǎn)，又摒棄了其缺陷， 非獨(dú)占式

收集器的好壞，主要有兩個(gè)指標(biāo)：停頓時(shí)間和吞吐量

GC 選擇的經(jīng)驗(yàn)總結(jié)

綜合來看，G1 是 JDK11 之前 HotSpot JVM 中最先進(jìn)的準(zhǔn)產(chǎn)品級(production-ready) 垃圾收集器。重要的是，HotSpot 工程師的主要精力都放在不斷改進(jìn) G1 上面。在更新的 JDK 版本中，將會帶來更多強(qiáng)大的功能和優(yōu)化。

可以看到，G1 作為 CMS 的代替者出現(xiàn)，解決了 CMS 中的各種疑難問題，包括暫停時(shí)間的可預(yù)測性，并終結(jié)了堆內(nèi)存的碎片化。對單業(yè)務(wù)延遲非常敏感的系統(tǒng)來說，如果 CPU 資源不受限制，那么 G1 可以說是 HotSpot 中最好的選擇，特別是在最新版本的 JVM 中。當(dāng)然這種降低延遲的優(yōu)化也不是沒有代價(jià)的：由于額外的寫屏障和守護(hù)線程，G1 的開銷會更大。如果系統(tǒng)屬于吞吐量優(yōu)先型的，又或者 CPU 持續(xù)占用 100%，而又不在乎單次 GC 的暫停時(shí)間，那么 CMS 是更好的選擇。

總之，G1 適合大內(nèi)存，需要較低延遲的場景。

選擇正確的 GC 算法，唯一可行的方式就是去嘗試，并找出不合理的地方，一般性的指導(dǎo)原則：

• 如果系統(tǒng)考慮吞吐優(yōu)先，CPU 資源都用來最大程度處理業(yè)務(wù)，用 Parallel GC;
• 如果系統(tǒng)考慮低延遲有限，每次 GC 時(shí)間盡量短，用 CMS GC;
• 如果系統(tǒng)內(nèi)存堆較大，同時(shí)希望整體來看平均 GC 時(shí)間可控，使用 G1 GC。

對于內(nèi)存大小的考量：

• 一般 4G 以上，算是比較大，用 G1 的性價(jià)比較高。
• 一般超過 8G，比如 16G-64G 內(nèi)存，非常推薦使用 G1 GC。

最后討論一個(gè)很多開發(fā)者經(jīng)常忽視的問題，也是面試大廠常問的問題：

JDK 8 的默認(rèn) GC 是什么?

很多人或覺得是 CMS，甚至 G1，其實(shí)都不是。

答案是：JDK 8并行 GC 是 JDK8 里的默認(rèn) GC 策略。默認(rèn)使用的是 Parallel Scavenge (新生代) 和 Parallel Old (老年代),基于我的Jdk 1.8.0_181-b13版本

注意，G1 成為 JDK9 以后版本的默認(rèn) GC 策略，同時(shí)，ParNew + SerialOld 這種組合不被支持。

最后在分享一下，調(diào)優(yōu)后如果還遇到JVM相關(guān)問題，請記住十六字箴言：做好監(jiān)控，定位問題，驗(yàn)證結(jié)果，總結(jié)歸納。