JVM層GC調優（上）

時間 2021-04-23

標籤 html java linux web 面試算法服務器多線程併發 oracle 欄目 Java 简体版

原文原文鏈接

JVM內存結構簡介（jdk1.8）

JVM層的GC調優是生產環境上必不可少的一個環節，由於咱們須要肯定這個進程能夠佔用多少內存，以及設定一些參數的閥值。以此來優化項目的性能和提升可用性，並且這也是在面試中常常會被問到的問題。html

想要進行GC調優，咱們首先須要簡單瞭解下JVM的內存結構，Java虛擬機的規範文檔以下：java

https://docs.oracle.com/javase/specs/jvms/se8/html/index.htmllinux

在介紹JVM內存結構以前，咱們須要先知道運行時數據區這樣的一個東西，它與JVM的內存結構有着必定的關聯。不過它屬因而一個規範，因此與JVM內存結構是有着物理上的區別的。運行時數據區以下：
web

1.程序計數器（Program Count Register，簡稱PC Register）：面試

JVM支持多線程同時執行，每個線程都有本身的PC Register。當每個新線程被建立時，它都將獲得它本身的PC Register。線程正在執行的方法叫作當前方法。若是執行的是Java方法，那麼PC Register裏存放的就是當前正在執行的指令的地址，若是是native方法（C/C++編寫的方法），則是爲空。此內存區域是惟一一個在java虛擬機規範中沒有規定任何OutOfMemoryError狀況的區域。

2.虛擬機棧（JVM Stacks）：算法

Java虛擬機棧（Java Virtual Machine Stacks）是線程私有的，它的生命週期與線程相同。虛擬機描述的是Java方法執行的內存模型：每一個方法在執行的同時都會建立一個棧幀，用於存儲局部變量表、操做數棧、動態連接、方法出口等信息。每個方法從調用直至執行完成的過程，就對應着一個棧幀在虛擬機棧中入棧到出棧的過程，實際上就是所謂的線程堆棧。
局部變量表存放了各類基本類型、對象引用和returnAddress類型（指向了一條字節碼指令地址）。其中64位長度 long 和 double 佔兩個局部變量空間，其餘只佔一個。
該區域中規定的異常狀況有兩種：1.線程請求的棧的深度大於虛擬機所容許的深度，將拋出StackOverflowError異常；2.若是虛擬機能夠動態擴展，若是擴展時沒法申請到足夠的內存，就拋出OutOfMemoryError異常。

3.堆Heap：服務器

Java堆（Java Heap）是Java虛擬機所管理的內存中最大的一塊。堆是被全部線程共享的一塊內存區域，在虛擬機啓動時建立。此內存區域的惟一目的就是存放對象實例，幾乎全部的對象實例都在這裏分配內存。
Java堆能夠處於物理上不連續的內存空間中，只要邏輯上是連續的便可。堆中可細分爲新生代和老年代，再細分可分爲Eden空間、From Survivor空間、To Survivor空間。堆沒法擴展時，會拋出OutOfMemoryError異常。

4.方法區（Method Area）：多線程

方法區與Java堆同樣，是各個線程共享的內存區域，它用於存儲已被虛擬機加載的類信息、常量、靜態變量、即時編譯器編譯後的代碼等數據。雖然Java虛擬機規範把方法區描述爲堆的一個邏輯部分，可是它卻有一個別名叫作Non-Heap（非堆），目的是與Java堆區分開來。
當方法區沒法知足內存分配需求時，拋出OutOfMemoryError

5.運行時常量池（Run-Time Constant Pool）：併發

如上圖所描述的同樣，它是方法區的一部分。Class文件中除了有類的版本、字段、方法、接口等描述信息外，還有一項是常量池（Const Pool Table），用於存放編譯期生成的各類字面量和符號引用，這部份內容將在類加載後被放入方法區的運行時常量池中存儲。並不是預置入Class文件中常量池的內容才進入方法運行時常量池，運行期間也可能將新的常量放入池中，這種特性被開發人員利用得比較多的即是String類的intern()方法。
一樣的，當方法區沒法知足內存分配需求時，也會拋出OutOfMemoryError

6.本地方法棧（Native Method Stacks）：oracle

本地方法棧與虛擬機棧所發揮的做用是很是類似的，它們之間的區別不過是虛擬機棧爲虛擬機執行Java方法（字節碼）服務，而本地方法棧則爲虛擬機使用到的Native方法服務。

瞭解了運行時方法區規範後，咱們接下來看看JVM的內存結構圖：

如上圖，能夠看到JVM內存被分爲了兩大區，非堆區用於存儲對象之外的數據：

Metaspace：存放Class、Package、Method、Field、字節碼、常量池、符號引用等等
- CCS：這個區域存放32位指針的Class，也就是壓縮類空間，默認關閉，須要使用JVM參數開啓
- CodeCache：存放JIT編譯後的本地代碼以及JNI使用的C/C++代碼

而堆區則用於存儲對象相關數據：

Young：新生代，存放新的或只通過幾回Minor GC的對象
- Eden：存放最新建立的對象，一些較大的對象則會特殊處理
- S0/S1：當對象通過第一次Minor GC後，若是仍然存活，就會存放到這裏。須要注意的是，S0和S1區域在同一時間上，只有其中一個是有數據的，而另外一個則是空的。
Old：老年代，當S0或S1區域存滿對象了，就會把這些對象存放到這個old區域中

在圖中也能夠看到，堆區還被分爲了年輕代（young）和老年代（old）。那麼爲何會有年輕代：

咱們先來捋一捋，爲何須要把堆區分代？不分代不能完成它所作的事情麼？其實不分代也徹底能夠，分代的惟一理由就是優化GC性能。你先想一想，若是沒有分代，那咱們全部的對象都會存在同一個空間裏。當進行GC的時候，咱們就要找到哪些對象是沒有用的，這樣一來就須要對整個堆區進行掃描。而咱們的不少對象都是隻存活一瞬間的，因此GC就會比較頻繁，而每次GC都得掃描整個堆區，就會致使性能低下。不進行GC的話，又會致使內存空間很快被佔滿。

由於GC性能的緣由，因此咱們才須要對堆區進行分代。若是進行分代的話，咱們就能夠把新建立的對象專門存放到一個單獨的區域中，當進行GC的時候就優先把這塊存放「短命」對象的區域進行回收，這樣就會騰出很大的空間出來，而且因爲不用去掃描整個堆區，也能極大提升GC的性能。

年輕代中的GC：

從上圖中也能夠看到年輕代被分爲了三部分：1個Eden區和2個Survivor區，通常咱們都會簡稱爲S0、S1（同時它們還分爲from和to兩種角色），默認比例爲8:1。通常狀況下，最新建立的對象都會被分配到Eden區(一些大對象會特殊處理)，這些對象通過第一次Minor GC後，若是仍然存活，將會被移到Survivor區。對象在Survivor區中每熬過一次Minor GC，年齡就會增長1歲，當它的年齡增長到必定程度時，就會被移動到年老代中。

由於年輕代中的對象基本都是"短命"的(80%以上)，因此在年輕代的垃圾回收算法使用的是複製算法，複製算法的基本思想就是將內存分爲兩塊，每次只用其中一塊，當這一塊內存用完，就將還活着的對象複製到另一塊上面。因此纔會有S0和S1區，複製算法的優勢就是吞吐量高、可實現高速分配而且不會產生內存碎片，因此才適用於做爲年輕代的GC算法。

在GC開始的時候，對象只會存在於Eden區和名爲「From」的Survivor區，Survivor區「To」是空的。緊接着進行GC，Eden區中全部存活的對象都會被複制到「To」，而在「From」區中，仍存活的對象會根據他們的年齡值來決定去向。年齡達到必定值(年齡閾值，能夠經過-XX:MaxTenuringThreshold來設置)的對象會被移動到年老代中，沒有達到閾值的對象會被複制到「To」區域。通過此次GC後，Eden區和From區已經被清空。這個時候，「From」和「To」會交換他們的角色，也就是新的「To」就是上次GC前的「From」，新的「From」就是上次GC前的「To」。無論怎樣，都會保證名爲To的Survivor區域是空的。Minor GC會一直重複這樣的過程，直到「To」區被填滿，「To」區被填滿以後，會將全部對象移動到年老代中。

JVM中的對象分配：

對象優先在Eden區分配
大對象則會直接進入老年代

咱們瞭解完JVM內存結構後，再來看看一些經常使用的JVM參數：

1.設置年輕代的大小，和年輕代的最大值，具體的值須要根據實際業務場景進行判斷。若是存在大量臨時對象就能夠設置大一些，不然小一些，通常爲整個堆大小的1/3或者1/4。爲了防止年輕代的堆收縮，兩個參數的值需設爲同樣大：

-XX:NewSize
-XX:MaxNewSize

2.設置Metaspace的大小，和Metaspace的最大值，一樣需設爲同樣大：

-XX:MetaspaceSize
-XX:MaxMetaspaceSize

3.設置Eden和其中一個Survivor的比例，這個值也比較重要：

-XX:SurvivorRatio

4.設置young和old區的比例：

-XX:NewRatio

5.這個參數用於顯示每次Minor GC時Survivor區中各個年齡段的對象的大小：

-XX:+PrintTenuringDistribution

6.用於設置晉升到老年代的對象年齡的最小值和最大值，每一個對象在堅持過一次Minor GC以後，年齡就加1：

-XX:InitialTenuringThreshol
-XX:MaxTenuringThreshold

7.使用短直針，也就是啓用壓縮類空間（CCS）：

-XX:+UseCompressedClassPointers

8.設置CCS空間的大小，默認是一個G：

-XX:CompressedClassSpaceSize

9.設置CodeCache的一個初始大小：

-XX:InitialCodeCacheSize

10.設置CodeCache的最大值：

-XX:ReservedCodeCacheSize

11.設置多大的對象會被直接放進老年代：

-XX:PretenureSizeThreshold

12.長期存活的對象會被放入Old區，使用如下參數設置就能夠設置對象的最大存活年齡：

-XX:MaxTenuringThreshold

注：若是設置爲0的話，則年輕代對象不通過Survivor區，直接進入年老代。對於年老代比較多的應用，能夠提升效率。若是將此值設置爲一個較大值，則年輕代對象會在Survivor區進行屢次複製，這樣能夠增長對象再年輕代的存活時間，增長在年輕代即被回收的概論，linux64的java6默認值是15：

13.設置Young區每發生GC的時候，就打印有效的對象的歲數狀況：

-XX:+PrintTenuringDistribution

14.設置Survivor區發生GC後對象所存活的比例值：

-XX:TargetSurvivorRatio

常見垃圾回收算法

本小節咱們來簡單介紹一些常見的垃圾回收算法，衆所周知Java區別與C/C++的一點就是，Java是能夠自動進行垃圾回收的。因此在Java中的內存泄露概念和C/C++中的內存泄露概念不同。在Java中，一個對象的指針一直被應用程序所持有得不到釋放就屬因而內存泄露。而C/C++則是把對象指針給弄丟了，該對象就永遠沒法獲得釋放，這就是C/C++裏的內存泄露。

在進行垃圾回收的是時候，要如何確認一個對象是不是垃圾呢？在好久之前有一種方式就是使用引用計數，當一個對象指針被其餘對象所引用時就會進行一個計數。在進行垃圾回收時，只要這個計數存在，那麼就會判斷該對象就是存活的。而沒有引用計數的對象，就會被判斷爲垃圾，能夠進行回收。可是這種方法缺陷很明顯，計數會佔用資源不說，若是當一個A對象和一個B對象互相持有對方引用時，那麼這兩個對象的引用計數都不會爲0，就永遠不會被回收掉，這樣就會致使內存泄露的問題。

在Java中，則是採用枚舉根節點的方式：

思想：枚舉根節點，作可達性分析
根節點：能夠是類加載器、Thread、虛擬機棧的本地變量表、static成員、常量引用、本地方法棧的變量等等

如上圖，JVM會從根節點開始遍歷引用，只要順着引用路線所遍歷到的對象都會判斷爲存活對象，便是具備可達性的，這些對象就不會被回收。而沒有被遍歷到的對象，也就是圖中的E和F對象，即使它們倆互相都還存在引用，也會被回收掉，由於它們不存在根節點的引用路線中，便是不具備可達性的。

既然瞭解了JVM如何判斷一個對象是否爲垃圾後，咱們就能夠來看看一些垃圾回收算法了：

1.標記-清除：

算法：該算法分爲「標記」和「清除」兩個階段：首先標記出全部須要回收的對象，在標記完成後統一進行回收
缺點：效率不高，標記和清除兩個過程的效率都不高。容易產生內存碎片，碎片太多就會致使提早GC。

2.複製算法：

算法：它將可用內存按容量劃分爲大小相等的兩個塊，每次只使用其中的一塊。當這一塊內存用完了，就將還存活的對象複製到另外一個塊上，而後再把已使用過的內存空間一次清理掉。
優缺點：實現簡單，運行高效，吞吐量大，可是空間利用率低，一次只能利用50%

3.標記-整理：

算法：標記過程仍然與「標記-清除」算法同樣，當後續步驟不是直接對可回收對象進行清理，而是讓全部存活的對象都向一端移動，而後直接清理掉邊界之外的內存。
優缺點：沒有了內存碎片，可是整理內存比較耗時

4.分代垃圾回收：

算法：這就是目前JVM所使用的垃圾回收算法，能夠看到以上所介紹到的算法都各自有優缺點。而JVM就是把這些算法都整合了起來，在不一樣的區域使用不一樣的垃圾回收算法。Young區使用複製算法，Old區則使用標記清除或者標記整理算法。

垃圾收集器

在上一小節瞭解了一些常見的垃圾回收算法後，咱們再來看看JVM中常見的垃圾收集器：

1.串行收集器Serial：Serial、Serial Old
2.並行收集器Parallel：Parallel Scavenge、Parallel Old，吞吐量優先，是Server模式下的默認收集器。默認在內存大於2G，CPU核心數大於2核的環境下爲Server模式
3.併發收集器Concurrent：CMS、G1，停頓時間優先

注：串行收集器幾乎不會在web應用中使用，因此主要介紹並行和併發收集器

串行 VS 並行 VS 併發：

串行（Serial）：指只有單個垃圾收集線程進行工做，也就是單線程的，當垃圾收集線程啓動的時候，用戶線程會處於一個等待狀態。適合內存較小的嵌入式開發中
並行（Parallel）：指多條垃圾收集線程並行工做，但此時用戶線程仍然處於等待狀態。適合科學計算、後臺處理等弱交互場景
併發（Concurrent）：指用戶線程與垃圾收集線程同時執行（但不必定是並行的，可能會交替執行），垃圾收集線程在執行的時候不會停頓用戶程序的運行。適合對響應時間有要求、交互性強的場景，好比Web開發

停頓時間 VS 吞吐量：

停頓時間：指垃圾收集器在進行垃圾回收時所中斷應用執行的時間。可使用如下參數進行設置：
- -XX:MaxGCPauseMillis
吞吐量：指花在垃圾收集的時間和花在應用時間的佔比。可使用如下參數進行設置：
- -XX:GCTimeRatio=< n > 垃圾收集時間佔：1/1+n

開啓串行收集器：

-XX:+UseSerialGC（Young區）
-XX:+UseSerialOldGC（Old區）

開啓並行收集器:

-XX:+UseParallelGC（Young區）
-XX:+UseParallelOldGC（Old區）
-XX:ParallelGCThread=< N > 設置N個GC線程，N取決於CPU核心數

併發收集器在JDK1.8裏有兩個，一個是CMS，CMS由於具備響應時間優先的特色，因此是低延遲、低停頓的，CMS是老年代收集器。開啓該收集器的參數以下：

-XX:+UseParNewGC（Young區）
-XX:+UseConcMarkSweepGC（Old區）

另外一個是G1，開啓該收集器的參數以下：

-XX:+UseG1GC（Young區、Old區）

垃圾收集器搭配圖：

注：實線表明可搭配使用的，虛線表示當內存分配失敗的時候CMS會退化成SerialOld。JDK1.8中建議使用的是G1收集器

有這麼多的垃圾收集器，那麼咱們要如何去選擇合適的垃圾收集器呢？這個是沒有具體答案的，都得按照實際的場景進行選擇，但通常都會按照如下原則來進行選擇：

優先調整堆的大小讓服務器本身來選擇
若是內存小於100M，使用串行收集器
如何是單核，而且沒有停頓時間的要求，就可使用串行或由JVM本身選擇
若是容許停頓時間超過1秒，選擇並行或者JVM本身選擇
若是響應時間最重要，而且不能超過1秒，則使用併發收集器

其中並行收集器是支持自適應的，經過設置如下幾個參數，並行收集器會以停頓時間優先去動態調整參數：

-XX:MaxGCPauseMillis=< N >
-XX:GCTimeRatio=< N >
-Xmx< N >

當內存不夠的時候並行收集器能夠動態調整內存，雖然實際生產環境中用的比較少，至於每次動態調整多少內存，則使用如下參數進行設置：

-XX:YoungGenerationSizeIncrement=< Y > （增長，Young區，默認20%）
-XX:TenuredGenerationSizeIncrement=< T > （增長，Old區，默認20%）
-XX:AdaptiveSizeDecrementScaleFactor=< D >（減小，默認4%）

瞭解了並行收集器後，咱們來簡單看看CMS收集器其餘的一些特性以及相關調優參數。

CMS垃圾收集過程：

1.CMS initial mark：初識標記Root，STW
2.CMS concurrent mark：併發標記
3.CMS-concurrent-preclean：併發預清理
4.CMS remark：從新標記，STW
5.CMS concurrent sweep：併發清除
6.CMS concurrent-reset：併發重置

CMS的缺點：

CPU敏感
會產生浮動垃圾
會產生空間碎片

CMS的相關調優參數：

設置併發的GC線程數：

-XX:ConcGCThreads

開啓如下參數能夠在Full GC以後對內存進行一個壓縮，以此減小空間碎片：

-XX:+UseCMSCompactAtFullCollection

這個參數則是設置多少次Full GC以後才進行壓縮：

-XX:CMSFullGCsBeforeCompaction

設置Old區存滿多少對象的時候觸發Full GC，默認值爲92%：

-XX:CMSInitiatingOccupancyFraction

啓用該參數表示不可動態調整以上參數的值：

-XX:+UseCMSInitiatingOccupancyOnly

啓用該參數表示在Full GC以前先作Young GC：

-XX:+CMSScavengeBeforeRemark

在jdk1.7以前可使用如下參數，啓用回收Perm區：

-XX:+CMSClassUnloadingEnable

在jdk1.8後，推薦使用的垃圾收集器是G1。G1收集器在jdk1.7中第一次出現，因此到了jdk1.8裏就很是成熟了。

G1收集器官網介紹以下：

The Garbage-First (G1) garbage collector is fully supported in Oracle JDK 7 update 4 and later releases. The G1 collector is a server-style garbage collector, targeted for multi-processor machines with large memories. It meets garbage collection (GC) pause time goals with high probability, while achieving high throughput. Whole-heap operations, such as global marking, are performed concurrently with the application threads. This prevents interruptions proportional to heap or live-data size.

The first focus of G1 is to provide a solution for users running applications that require large heaps with limited GC latency. This means heap sizes of around 6GB or larger, and stable and predictable pause time below 0.5 seconds.

官方文檔地址：

http://www.oracle.com/technetwork/java/javase/tech/g1-intro-jsp-135488.html

原理概述：

G1 也是屬於分代收集器的，可是G1的分代是邏輯上的，而不是物理上的

G1 將整個對區域劃分爲若干個Region，每一個Region的大小是2的倍數（1M,2M,4M,8M,16M,32M，經過設置堆的大小和Region數量計算得出。

Region區域劃分與其餘收集相似，不一樣的是單獨將大對象分配到了單獨的region中，會分配一組連續的Region區域（Humongous start 和 humonous Contoinue 組成），因此一共有四類Region（Eden，Survior，Humongous和Old），G1 做用於整個堆內存區域，設計的目的就是減小Full GC的產生。在Full GC過程當中因爲G1 是單線程進行，會產生較長時間的停頓。

G1的OldGc標記過程能夠和yongGc並行執行，可是OldGc必定在YongGc以後執行，即MixedGc在yongGC以後執行。

結構圖：

G1垃圾收集算法主要應用在多CPU大內存的服務中，在知足高吞吐量的同時，儘量的知足垃圾回收時的暫停時間，該設計主要針對以下應用場景：