【JVM之記憶體與垃圾回收篇】堆

2020 年 7 月 20 日
筆記
JVM

堆

堆的核心概念

堆針對一個 JVM 進程來說是唯一的，也就是一個進程只有一個 JVM，但是進程包含多個執行緒，他們是共享同一堆空間的。

一個 JVM 實例只存在一個堆記憶體，堆也是 Java 記憶體管理的核心區域。

Java 堆區在 JVM 啟動的時候即被創建，其空間大小也就確定了。是 JVM 管理的最大一塊記憶體空間。

堆記憶體的大小是可以調節的。

《Java 虛擬機規範》規定，堆可以處於物理上不連續的記憶體空間中，但在邏輯上它應該被視為連續的。

所有的執行緒共享 Java 堆，在這裡還可以劃分執行緒私有的緩衝區（Thread Local Allocation Buffer，TLAB）。

-Xms10m：最小堆記憶體
-Xmx10m：最大堆記憶體

理解：
ms：memory size
mx：memory max size

下圖就是使用：Java VisualVM 查看堆空間的內容，通過 jdk bin 提供的插件

《Java 虛擬機規範》中對 Java 堆的描述是：所有的對象實例以及數組都應當在運行時分配在堆上。（The heap is the run-time data area from which memory for all class instances and arrays is allocated）

我要說的是：「幾乎」所有的對象實例都在這裡分配記憶體。—從實際使用角度看的。
因為還有一些對象是在棧上分配的

數組和對象可能永遠不會存儲在棧上，因為棧幀中保存引用，這個引用指向對象或者數組在堆中的位置。

在方法結束後，堆中的對象不會馬上被移除，僅僅在垃圾收集的時候才會被移除。

也就是觸發了 GC 的時候，才會進行回收
如果堆中對象馬上被回收，那麼用戶執行緒就會收到影響，因為有 stop the word

堆，是 GC（Garbage Collection，垃圾收集器）執行垃圾回收的重點區域。

堆記憶體細分

Java 7 及之前堆記憶體邏輯上分為三部分：新生區 + 養老區 + 永久區

Young Generation Space 新生區 Young/New，又被劃分為 Eden 區和 Survivor 區
Tenure generation space 養老區 Old/Tenure
Permanent Space 永久區 Perm

Java 8 及之後堆記憶體邏輯上分為三部分：新生區 + 養老區 + 元空間

Young Generation Space 新生區 Young/New，又被劃分為 Eden 區和 Survivor 區
Tenure generation space 養老區 Old/Tenure
Meta Space 元空間 Meta

約定：新生區 <=> 新生代 <=> 年輕代、養老區 <=> 老年區 <=> 老年代、永久區 <=> 永久代

堆空間內部結構，JDK1.8 之前從永久代替換成元空間

設置堆記憶體大小與OOM

Java 堆區用於存儲 Java 對象實例，那麼堆的大小在 JVM 啟動時就已經設定好了，大家可以通過選項「-Xmx」和「-Xms」來進行設置。

「-Xms」用於表示堆區的起始記憶體，等價於 -XX:InitialHeapSize
「-Xmx」則用於表示堆區的最大記憶體，等價於 -XX:MaxHeapSize

一旦堆區中的記憶體大小超過「-Xmx」所指定的最大記憶體時，將會拋出 OutOfMemoryError 異常。

通常會將 -Xms 和 -Xmx 兩個參數配置相同的值，其目的是為了能夠在 Java 垃圾回收機制清理完堆區後不需要重新分隔計算堆區的大小，從而提高性能。

默認情況下

初始記憶體大小：物理電腦記憶體大小/64
最大記憶體大小：物理電腦記憶體大小/4

/**
 * -Xms 用來設置堆空間（年輕代+老年代）的初始記憶體大小
 *  -X：是jvm運行參數
 *  ms：memory start
 * -Xmx：用來設置堆空間（年輕代+老年代）的最大記憶體大小
 *
 * @author: Nemo
 */
public class HeapSpaceInitial {
    public static void main(String[] args) {
        // 返回Java虛擬機中的堆記憶體總量
        long initialMemory = Runtime.getRuntime().totalMemory() / 1024 / 1024;
        // 返回Java虛擬機試圖使用的最大堆記憶體
        long maxMemory = Runtime.getRuntime().maxMemory() / 1024 / 1024;
        System.out.println("-Xms:" + initialMemory + "M");
        System.out.println("-Xmx:" + maxMemory + "M");
    }
}

輸出結果

-Xms:245M
-Xmx:3614M

如何查看堆記憶體的記憶體分配情況

jps  ->  staat -gc  進程id

-XX:+PrintGCDetails

OutOfMemory 舉例

我們簡單的寫一個 OOM 例子

/**
 * OOM測試
 *
 * @author: Nemo
 */
public class OOMTest {
    public static void main(String[] args) {
        List<Integer> list = new ArrayList<>();
        while(true) {
            list.add(999999999);
        }
    }
}

然後設置啟動參數

-Xms10m -Xmx:10m

運行後，就出現 OOM 了，那麼我們可以通過 VisualVM 這個工具查看具體是什麼參數造成的 OOM

年輕代與老年代

存儲在 JVM 中的 Java 對象可以被劃分為兩類：

一類是生命周期較短的瞬時對象，這類對象的創建和消亡都非常迅速

生命周期短的，及時回收即可
另外一類對象的生命周期卻非常長，在某些極端的情況下還能夠與 JVM 的生命周期保持一致

Java堆區進一步細分的話，可以劃分為年輕代（YoungGen）和老年代（OldGen）

其中年輕代又可以劃分為 Eden 空間、Survivor0 空間和 Survivor1 空間（有時也叫做 from 區、to 區）

下面這參數開發中一般不會調：

Eden：From：to -> 8:1:1
新生代：老年代 -> 1 : 2

配置新生代與老年代在堆結構的佔比。

默認 -XX:NewRatio=2，表示新生代占 1，老年代占 2，新生代占整個堆的 1/3
可以修改 -XX:NewRatio=4，表示新生代占 1，老年代占 4，新生代占整個堆的 1/5

當發現在整個項目中，生命周期長的對象偏多，那麼就可以通過調整老年代的大小，來進行調優

在 HotSpot 中，Eden 空間和另外兩個 survivor 空間預設所佔的比例是 8：1：1

當然開發人員可以通過選項「-xx:SurvivorRatio」調整這個空間比例。比如 -xx:SurvivorRatio=8

幾乎所有的 Java 對象都是在 Eden 區被 new 出來的。

絕大部分的 Java 對象的銷毀都在新生代進行了。（有些大的對象在 Eden 區無法存儲時候，將直接進入老年代）

IBM 公司的專門研究表明，新生代中 80% 的對象都是「朝生夕死」的。

可以使用選項「-Xmn」設置新生代最大記憶體大小

這個參數一般使用默認值就可以了。
理解：mn：memory new

圖解對象分配過程

概念

為新對象分配記憶體是一件非常嚴謹和複雜的任務，JVM 的設計者們不僅需要考慮記憶體如何分配、在哪裡分配等問題，並且由於記憶體分配演算法與記憶體回收演算法密切相關，所以還需要考慮 GC 執行完記憶體回收後是否會在記憶體空間中產生記憶體碎片。

new 的對象先放伊甸園區。此區有大小限制。
當伊甸園的空間填滿時，程式又需要創建對象，JVM 的垃圾回收器將對伊甸園區進行垃圾回收（MinorGC），將伊甸園區中的不再被其他對象所引用的對象進行銷毀。再載入新的對象放到伊甸園區
然後將伊甸園中的剩餘對象移動到倖存者 0 區。
如果再次觸發垃圾回收，此時上次倖存下來的放到倖存者 0 區的，如果沒有回收，就會放到倖存者 1 區。
如果再次經歷垃圾回收，此時會重新放回倖存者 0 區，接著再去倖存者 1 區。
啥時候能去養老區呢？可以設置次數。默認是 15 次。

可以設置參數：-XX:MaxTenuringThreshold=<N> 進行設置
在養老區，相對悠閑。當養老區記憶體不足時，再次觸發 GC：Major GC，進行養老區的記憶體清理
若養老區執行了 Major GC 之後，發現依然無法進行對象的保存，就會產生 OOM 異常。

可以設置參數：-XX:MaxTenuringThreshold=N 進行設置

圖解過程

我們創建的對象，一般都是存放在 Eden 區的，當我們 Eden 區滿了後，就會觸發 GC 操作，一般被稱為 YGC / Minor GC 操作

當我們進行一次垃圾收集後，紅色的將會被回收，而綠色的還會被佔用著，存放在 S0(Survivor From)區。同時我們給每個對象設置了一個年齡計數器，一次回收後就是 1。

同時 Eden 區繼續存放對象，當 Eden 區再次存滿的時候，又會觸發一個 MinorGC 操作，此時 GC 將會把 Eden 和 Survivor From 中的對象進行一次收集，把存活的對象放到 Survivor To 區，同時讓年齡 + 1
To 區是一個為空的區，是 S0、S1 中的某一個（輪流交換，有時是 S0，有時是 S1）

我們繼續不斷的進行對象生成和垃圾回收，當 Survivor 中的對象的年齡達到15的時候，將會觸發一次 Promotion 晉陞的操作，也就是將年輕代中的對象晉陞到老年代中

思考：倖存區區滿了後？

特別注意，在 Eden 區滿了的時候，才會觸發 MinorGC，而倖存者區滿了後，不會觸發 MinorGC 操作

如果 Survivor 區滿了後，將會觸發一些特殊的規則，也就是可能直接晉陞老年代

舉例：以當兵為例，正常人的晉陞可能是：新兵 -> 班長 -> 排長 -> 連長

但是也有可能有些人因為做了非常大的貢獻，直接從新兵 -> 排長

對象分配的特殊情況

程式碼演示對象分配過程

我們不斷的創建大對象

/**
 * 程式碼演示對象創建過程
 *
 * @author: Nemo
 */
public class HeapInstanceTest {
    byte [] buffer = new byte[new Random().nextInt(1024 * 200)];
    public static void main(String[] args) throws InterruptedException {
        ArrayList<HeapInstanceTest> list = new ArrayList<>();
        while (true) {
            list.add(new HeapInstanceTest());
            Thread.sleep(10);
        }
    }
}

然後設置 JVM 參數

-Xms600m -Xmx600m

然後cmd輸入下面命令，打開VisualVM圖形化介面

jvisualvm

然後通過執行上面程式碼，通過 VisualGC 進行動態化查看

最終，在老年代和新生代都滿了，就出現 OOM

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
  at com.atguigu.java.chapter08.HeapInstanceTest.<init>(HeapInstanceTest.java:13)
  at com.atguigu.java.chapter08.HeapInstanceTest.main(HeapInstanceTest.java:17)

常用的調優工具

JDK命令行
Eclipse：Memory Analyzer Tool
Jconsole
Visual VM（實時監控推薦~）
Jprofiler（推薦~）
Java Flight Recorder（實時監控）
GCViewer
GC Easy

總結

針對倖存者 s0，s1 區的總結：複製之後有交換，誰空誰是 to
關於垃圾回收：頻繁在新生區收集，很少在老年代收集，幾乎不再永久代和元空間進行收集
新生代採用複製演算法的目的：是為了減少內碎片

Minor GC，MajorGC、Full GC

Minor GC：新生代的 GC
Major GC：老年代的 GC
Full GC：整堆收集，收集整個 Java 堆和方法區的垃圾收集

我們都知道，JVM 的調優的一個環節，也就是垃圾收集，我們需要盡量的避免垃圾回收，因為在垃圾回收的過程中，容易出現 STW 的問題

而 Major GC 和 Full GC 出現 STW 的時間，是 Minor GC 的 10 倍以上

JVM 在進行 GC 時，並非每次都對上面三個記憶體區域一起回收的，大部分時候回收的都是指新生代。針對 Hotspot JVM 的實現，它裡面的 GC 按照回收區域又分為兩大種類型：一種是部分收集（Partial GC），一種是整堆收集（FullGC）

部分收集：不是完整收集整個 Java 堆的垃圾收集。其中又分為：

新生代收集（MinorGC/YoungGC）：只是新生代的垃圾收集
老年代收集（MajorGC/oldGC）：只是老年代的圾收集。
- 目前，只有 CMSGC 會有單獨收集老年代的行為。
- 注意，很多時候 Major GC 會和 FullGC 混淆使用，需要具體分辨是老年代回收還是整堆回收。
混合收集（MixedGC）：收集整個新生代以及部分老年代的垃圾收集。
- 目前，只有 G1 GC 會有這種行為

整堆收集（FullGC）：收集整個 java 堆和方法區的垃圾收集。

Minor GC

年輕代 GC（Minor GC）觸發機制：

當年輕代空間不足時，就會觸發 MinorGC，這裡的年輕代滿指的是 Eden 代滿，Survivor 滿不會引發 GC。（每次 Minor GC 會清理年輕代的記憶體。）
因為 Java 對象大多都具備 朝生夕滅 的特性，所以 Minor GC 非常頻繁，一般回收速度也比較快。這一定義既清晰又易於理解。
Minor GC 會引發 STW，暫停其它用戶的執行緒，等垃圾回收結束，用戶執行緒才恢復運行

STW：stop the world

Major GC

老年代 GC（Major GC/Full GC）觸發機制：

指發生在老年代的 GC，對象從老年代消失時，我們說「Major GC」或「Full GC」發生了
出現了 MajorGC，經常會伴隨至少一次的 Minor GC（但非絕對的，在 Parallel Scavenge 收集器的收集策略里就有直接進行 MajorGC 的策略選擇過程）
- 也就是在老年代空間不足時，會先嘗試觸發 MinorGC。如果之後空間還不足，則觸發 Major GC
Major GC 的速度一般會比 MinorGC 慢 10 倍以上，STW 的時間更長，
如果 Major GC 後，記憶體還不足，就報 OOM 了

Full GC

Full GC 觸發機制：
觸發 FullGC 執行的情況有如下五種：

調用 System.gc() 時，系統建議執行 FullGC，但是不必然執行
老年代空間不足
方法區空間不足
通過 Minor GC 後進入老年代的平均大小大於老年代的可用記憶體
由 Eden 區、survivor space（From Space）區向 survivor spacel（To Space）區複製時，對象大小大於 To Space 可用記憶體，則把該對象轉存到老年代，且老年代的可用記憶體小於該對象大小

注意：Full GC 是開發或調優中盡量要避免的。這樣暫停時間會短一些

GC 舉例

我們編寫一個 OOM 的異常，因為我們在不斷的創建字元串，是存放在元空間的

/**
 * GC測試
 *
 * @author: Nemo
 */
public class GCTest {
    public static void main(String[] args) {
        int i = 0;
        try {
            List<String> list = new ArrayList<>();
            String a = "mogu blog";
            while(true) {
                list.add(a);
                a = a + a;
                i++;
            }
        }catch (Exception e) {
            e.getStackTrace();
        }
    }
}

設置JVM啟動參數

-Xms10m -Xmx10m -XX:+PrintGCDetails

列印出的日誌

[GC (Allocation Failure) [PSYoungGen: 2038K->500K(2560K)] 2038K->797K(9728K), 0.3532002 secs] [Times: user=0.01 sys=0.00, real=0.36 secs] 
[GC (Allocation Failure) [PSYoungGen: 2108K->480K(2560K)] 2405K->1565K(9728K), 0.0014069 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (Ergonomics) [PSYoungGen: 2288K->0K(2560K)] [ParOldGen: 6845K->5281K(7168K)] 9133K->5281K(9728K), [Metaspace: 3482K->3482K(1056768K)], 0.0058675 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
[GC (Allocation Failure) [PSYoungGen: 0K->0K(2560K)] 5281K->5281K(9728K), 0.0002857 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (Allocation Failure) [PSYoungGen: 0K->0K(2560K)] [ParOldGen: 5281K->5263K(7168K)] 5281K->5263K(9728K), [Metaspace: 3482K->3482K(1056768K)], 0.0058564 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
Heap
 PSYoungGen      total 2560K, used 60K [0x00000000ffd00000, 0x0000000100000000, 0x0000000100000000)
  eden space 2048K, 2% used [0x00000000ffd00000,0x00000000ffd0f138,0x00000000fff00000)
  from space 512K, 0% used [0x00000000fff00000,0x00000000fff00000,0x00000000fff80000)
  to   space 512K, 0% used [0x00000000fff80000,0x00000000fff80000,0x0000000100000000)
 ParOldGen       total 7168K, used 5263K [0x00000000ff600000, 0x00000000ffd00000, 0x00000000ffd00000)
  object space 7168K, 73% used [0x00000000ff600000,0x00000000ffb23cf0,0x00000000ffd00000)
 Metaspace       used 3514K, capacity 4498K, committed 4864K, reserved 1056768K
  class space    used 388K, capacity 390K, committed 512K, reserved 1048576K
  
  Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
  at java.util.Arrays.copyOfRange(Arrays.java:3664)
  at java.lang.String.<init>(String.java:207)
  at java.lang.StringBuilder.toString(StringBuilder.java:407)
  at com.atguigu.java.chapter08.GCTest.main(GCTest.java:20)

觸發 OOM 的時候，一定是進行了一次 Full GC，因為只有在老年代空間不足時候，才會爆出 OOM 異常

堆空間分代思想

為什麼要把 Java 堆分代？不分代就不能正常工作了嗎？
經研究，不同對象的生命周期不同。70%-99% 的對象是臨時對象。

新生代：有 Eden、兩塊大小相同的 survivor（又稱為 from/to，s0/s1）構成，to 總為空。
老年代：存放新生代中經歷多次 GC 仍然存活的對象。

其實不分代完全可以，分代的唯一理由就是優化 GC 性能。如果沒有分代，那所有的對象都在一塊，就如同把一個學校的人都關在一個教室。GC 的時候要找到哪些對象沒用，這樣就會對堆的所有區域進行掃描。而很多對象都是朝生夕死的，如果分代的話，把新創建的對象放到某一地方，當 GC 的時候先把這塊存儲「朝生夕死」對象的區域進行回收，這樣就會騰出很大的空間出來。

記憶體分配策略

如果對象在 Eden 出生並經過第一次 Minor GC 後仍然存活，並且能被 Survivor 容納的話，將被移動到 survivor 空間中，並將對象年齡設為 1。對象在 survivor 區中每熬過一次 MinorGC，年齡就增加 1 歲，當它的年齡增加到一定程度（默認為 15 歲，其實每個 JVM、每個 GC 都有所不同）時，就會被晉陞到老年代

對象晉陞老年代的年齡閥值，可以通過選項 -XX:MaxTenuringThreshold 來設置

針對不同年齡段的對象分配原則如下所示：

優先分配到 Eden
- 開發中比較長的字元串或者數組，會直接存在老年代，但是因為新創建的對象都是朝生夕死的，所以這個大對象可能也很快被回收，但是因為老年代觸發 Major GC 的次數比 Minor GC 要更少，因此可能回收起來就會比較慢
大對象直接分配到老年代
- 盡量避免程式中出現過多的大對象
長期存活的對象分配到老年代
動態對象年齡判斷
- 如果 Survivor 區中相同年齡的所有對象大小的總和大於 Survivor 空間的一半，年齡大於或等於該年齡的對象可以直接進入老年代，無須等到 MaxTenuringThreshold 中要求的年齡。
空間分配擔保：
- -XX:HandlePromotionFailure

也就是經過 Minor GC 後，所有的對象都存活，因為 Survivor 比較小，所以就需要將 Survivor 無法容納的對象，存放到老年代中。

為對象分配記憶體：TLAB

問題：堆空間都是共享的么？

不一定，因為還有 TLAB 這個概念，在堆中劃分出一塊區域，為每個執行緒所獨佔

為什麼有 TLAB？

TLAB：Thread Local Allocation Buffer，也就是為每個執行緒單獨分配了一個緩衝區

堆區是執行緒共享區域，任何執行緒都可以訪問到堆區中的共享數據

由於對象實例的創建在 JVM 中非常頻繁，因此在並發環境下從堆區中劃分記憶體空間是執行緒不安全的

為避免多個執行緒操作同一地址，需要使用加鎖等機制，進而影響分配速度。

什麼是 TLAB

從記憶體模型而不是垃圾收集的角度，對 Eden 區域繼續進行劃分，JVM 為每個執行緒分配了一個私有快取區域，它包含在 Eden 空間內。

多執行緒同時分配記憶體時，使用 TLAB 可以避免一系列的非執行緒安全問題，同時還能夠提升記憶體分配的吞吐量，因此我們可以將這種記憶體分配方式稱之為快速分配策略。

據我所知所有 OpenJDK 衍生出來的 JVM 都提供了 TLAB 的設計。

TLAB 的再說明：

儘管不是所有的對象實例都能夠在 TLAB 中成功分配記憶體，但 JVM 確實是將 TLAB 作為記憶體分配的首選。
在程式中，開發人員可以通過選項「-XX:UseTLAB」設置是否開啟 TLAB 空間。
默認情況下，TLAB 空間的記憶體非常小，僅佔有整個 Eden 空間的 1%，當然我們可以通過選項「-XX:TLABWasteTargetPercent」設置 TLAB 空間所佔用 Eden 空間的百分比大小。
一旦對象在 TLAB 空間分配記憶體失敗時，JVM 就會嘗試著通過使用加鎖機制確保數據操作的原子性，從而直接在 Eden 空間中分配記憶體。

TLAB分配過程

對象首先是通過 TLAB 開闢空間，如果不能放入，那麼需要通過 Eden 來進行分配

小結：堆空間的參數設置

官網說明：//docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html

-XX：+PrintFlagsInitial：查看所有的參數的默認初始值
-XX：+PrintFlagsFinal：查看所有的參數的最終值（可能會存在修改，不再是初始值）
-Xms(memory size)：初始堆空間記憶體（默認為物理記憶體的 1/64）
-Xmx(memory max)：最大堆空間記憶體（默認為物理記憶體的 1/4）
-Xmn(memory new)：設置新生代的大小。（初始值及最大值）
-XX:NewRatio：配置新生代與老年代在堆結構的佔比
-XX:SurvivorRatio：設置新生代中 Eden 和 S0/S1 空間的比例
-XX:MaxTenuringThreshold：設置新生代垃圾的最大年齡
-XX：+PrintGCDetails：輸出詳細的 GC 處理日誌
- 列印gc簡要資訊：①-XX：+PrintGC ② – verbose:gc
–XX:HandlePromotionFalilure：是否設置空間分配擔保

空間分配擔保的作用流程：
在發生 Minor GC 之前，虛擬機會檢查老年代最大可用的連續空間是否大於新生代所有對象的總空間。

如果大於，則此次 Minor GC 是安全的
如果小於，則虛擬機會查看 -XX:HandlePromotionFailure 設置值是否允擔保失敗。
- 如果HandlePromotionFailure=true，那麼會繼續檢查老年代最大可用連續空間是否大於歷次晉陞到老年代的對象的平均大小。
- 如果大於，則嘗試進行一次 Minor GC，但這次 Minor GC 依然是有風險的；
- 如果小於，則改為進行一次 FullGC。
- 如果 HandlePromotionFailure=false，則改為進行一次 Full GC。

在 JDK6 Update24 之後（JDK7），HandlePromotionFailure 參數不會再影響到虛擬機的空間分配擔保策略，觀察 openJDK 中的源碼變化，雖然源碼中還定義了 HandlePromotionFailure 參數，但是在程式碼中已經不會再使用它。JDK6 Update 24 之後的規則變為只要老年代的連續空間大於新生代對象總大小或者歷次晉陞的平均大小就會進行 Minor GC，否則將進行 FullGC。

堆是分配對象的唯一選擇么？

逃逸分析

在《深入理解 Java 虛擬機》中關於 Java 堆記憶體有這樣一段描述：

隨著 JIT 編譯期的發展與逃逸分析技術逐漸成熟，棧上分配、標量替換優化技術將會導致一些微妙的變化，所有的對象都分配到堆上也漸漸變得不那麼「絕對」了。

在 Java 虛擬機中，對象是在 Java 堆中分配記憶體的，這是一個普遍的常識。但是，有一種特殊情況，那就是如果經過逃逸分析（Escape Analysis）後發現，一個對象並沒有逃逸出方法的話，那麼就可能被優化成棧上分配。這樣就無需在堆上分配記憶體，也無須進行垃圾回收了。這也是最常見的堆外存儲技術。

此外，前面提到的基於 OpenJDK 深度訂製的 TaoBaovm，其中創新的 GCIH（GC invisible heap）技術實現 off-heap，將生命周期較長的 Java 對象從 heap 中移至 heap 外，並且 GC 不能管理 GCIH 內部的 Java 對象，以此達到降低 GC 的回收頻率和提升 GC 的回收效率的目的。

如何將堆上的對象分配到棧，需要使用逃逸分析手段。

這是一種可以有效減少 Java 程式中同步負載和記憶體堆分配壓力的跨函數全局數據流分析演算法。通過逃逸分析，Java Hotspot 編譯器能夠分析出一個新的對象的引用的使用範圍從而決定是否要將這個對象分配到堆上。

逃逸分析的基本行為就是分析對象動態作用域：

當一個對象在方法中被定義後，對象只在方法內部使用，則認為沒有發生逃逸。
當一個對象在方法中被定義後，它被外部方法所引用，則認為發生逃逸。例如作為調用參數傳遞到其他地方中。

逃逸分析舉例

沒有發生逃逸的對象，則可以分配到棧上，隨著方法執行的結束，棧空間就被移除，每個棧裡面包含了很多棧幀，也就是發生逃逸分析

public void my_method() {
    V v = new V();
    // use v
    // ....
    v = null;
}

針對下面的程式碼

public static StringBuffer createStringBuffer(String s1, String s2) {
    StringBuffer sb = new StringBuffer();
    sb.append(s1);
    sb.append(s2);
    return sb;
}

如果想要 StringBuffer sb 不發生逃逸，可以這樣寫

public static String createStringBuffer(String s1, String s2) {
    StringBuffer sb = new StringBuffer();
    sb.append(s1);
    sb.append(s2);
    return sb.toString();
}

完整的逃逸分析程式碼舉例

/**
 * 逃逸分析
 * 如何快速的判斷是否發生了逃逸分析，大家就看new的對象是否在方法外被調用。
 * @author: Nemo
 */
public class EscapeAnalysis {

    public EscapeAnalysis obj;

    /**
     * 方法返回EscapeAnalysis對象，發生逃逸
     * @return
     */
    public EscapeAnalysis getInstance() {
        return obj == null ? new EscapeAnalysis():obj;
    }

    /**
     * 為成員屬性賦值，發生逃逸
     */
    public void setObj() {
        this.obj = new EscapeAnalysis();
    }

    /**
     * 對象的作用於僅在當前方法中有效，沒有發生逃逸
     */
    public void useEscapeAnalysis() {
        EscapeAnalysis e = new EscapeAnalysis();
    }

    /**
     * 引用成員變數的值，發生逃逸
     */
    public void useEscapeAnalysis2() {
        EscapeAnalysis e = getInstance();
        // getInstance().XXX  發生逃逸
    }
}

參數設置

在 JDK 1.7 版本之後，HotSpot 中默認就已經開啟了逃逸分析

如果使用的是較早的版本，開發人員則可以通過：

選項「-XX：+DoEscapeAnalysis」顯式開啟逃逸分析
通過選項「-XX：+PrintEscapeAnalysis」查看逃逸分析的篩選結果

結論

開發中能使用局部變數的，就不要使用在方法外定義。

使用逃逸分析，編譯器可以對程式碼做如下優化：

棧上分配：將堆分配轉化為棧分配。如果一個對象在子程式中被分配，要使指向該對象的指針永遠不會發生逃逸，對象可能是棧上分配的候選，而不是堆上分配
同步省略：如果一個對象被發現只有一個執行緒被訪問到，那麼對於這個對象的操作可以不考慮同步。
分離對象或標量替換：有的對象可能不需要作為一個連續的記憶體結構存在也可以被訪問到，那麼對象的部分（或全部）可以不存儲在記憶體，而是存儲在 CPU 暫存器中。

棧上分配

JIT 編譯器在編譯期間根據逃逸分析的結果，發現如果一個對象並沒有逃逸出方法的話，就可能被優化成棧上分配。分配完成後，繼續在調用棧內執行，最後執行緒結束，棧空間被回收，局部變數對象也被回收。這樣就無須進行垃圾回收了。

常見的棧上分配的場景

在逃逸分析中，已經說明了。分別是給成員變數賦值、方法返回值、實例引用傳遞。

舉例

我們通過舉例來說明開啟逃逸分析和未開啟逃逸分析時候的情況

/**
 * 棧上分配
 * -Xmx1G -Xms1G -XX:-DoEscapeAnalysis -XX:+PrintGCDetails
 * @author: Nemo
 */
class User {
    private String name;
    private String age;
    private String gender;
    private String phone;
}
public class StackAllocation {
    public static void main(String[] args) throws InterruptedException {
        long start = System.currentTimeMillis();
        for (int i = 0; i < 100000000; i++) {
            alloc();
        }
        long end = System.currentTimeMillis();
        System.out.println("花費的時間為：" + (end - start) + " ms");

        // 為了方便查看堆記憶體中對象個數，執行緒sleep
        Thread.sleep(10000000);
    }

    private static void alloc() {
        User user = new User();
    }
}

設置 JVM 參數，表示未開啟逃逸分析

-Xmx1G -Xms1G -XX:-DoEscapeAnalysis -XX:+PrintGCDetails

運行結果，同時還觸發了 GC 操作

花費的時間為：664 ms

然後查看記憶體的情況，發現有大量的 User 存儲在堆中

我們在開啟逃逸分析

-Xmx1G -Xms1G -XX:+DoEscapeAnalysis -XX:+PrintGCDetails

然後查看運行時間，我們能夠發現花費的時間快速減少，同時不會發生 GC 操作

花費的時間為：5 ms

然後在看記憶體情況，我們發現只有很少的 User 對象，說明 User 發生了逃逸，因為他們存儲在棧中，隨著棧的銷毀而消失

同步省略

執行緒同步的代價是相當高的，同步的後果是降低並發性和性能。

在動態編譯同步塊的時候，JIT 編譯器可以藉助逃逸分析來判斷同步塊所使用的鎖對象是否只能夠被一個執行緒訪問而沒有被發布到其他執行緒。如果沒有，那麼 JIT 編譯器在編譯這個同步塊的時候就會取消對這部分程式碼的同步。這樣就能大大提高並發性和性能。這個取消同步的過程就叫同步省略，也叫鎖消除。

例如下面的程式碼

public void f() {
    Object hellis = new Object();
    synchronized(hellis) {
        System.out.println(hellis);
    }
}

程式碼中對 hellis 這個對象加鎖，但是 hellis 對象的生命周期只在 f() 方法中，並不會被其他執行緒所訪問到，所以在 JIT 編譯階段就會被優化掉，優化成：

public void f() {
    Object hellis = new Object();
  System.out.println(hellis);
}

我們將其轉換成位元組碼

分離對象和標量替換

標量（scalar）是指一個無法再分解成更小的數據的數據。Java 中的原始數據類型就是標量。

相對的，那些還可以分解的數據叫做聚合量（Aggregate），Java 中的對象就是聚合量，因為他可以分解成其他聚合量和標量。

在 JIT 階段，如果經過逃逸分析，發現一個對象不會被外界訪問的話，那麼經過 JIT 優化，就會把這個對象拆解成若干個其中包含的若干個成員變數來代替。這個過程就是標量替換。

public static void main(String args[]) {
    alloc();
}
class Point {
    private int x;
    private int y;
}
private static void alloc() {
    Point point = new Point(1,2);
    System.out.println("point.x" + point.x + ";point.y" + point.y);
}

以上程式碼，經過標量替換後，就會變成

private static void alloc() {
    int x = 1;
    int y = 2;
    System.out.println("point.x = " + x + "; point.y=" + y);
}

可以看到，Point 這個聚合量經過逃逸分析後，發現他並沒有逃逸，就被替換成兩個聚合量了。那麼標量替換有什麼好處呢？就是可以大大減少堆記憶體的佔用。因為一旦不需要創建對象了，那麼就不再需要分配堆記憶體了。
標量替換為棧上分配提供了很好的基礎。

程式碼優化之標量替換

上述程式碼在主函數中進行了 1 億次 alloc。調用進行對象創建，由於 User 對象實例需要佔據約 16 位元組的空間，因此累計分配空間達到將近 1.5GB。如果堆空間小於這個值，就必然會發生 GC。使用如下參數運行上述程式碼：

-server -Xmx100m -Xms100m -XX:+DoEscapeAnalysis -XX:+PrintGC -XX:+EliminateAllocations

這裡設置參數如下：

參數-server：啟動 Server 模式，因為在 server 模式下，才可以啟用逃逸分析。
參數-XX:+DoEscapeAnalysis：啟用逃逸分析
參數-Xmx10m：指定了堆空間最大為 10MB
參數-XX:+PrintGC：將列印 GC 日誌。
參數-XX：+EliminateAllocations：開啟了標量替換（默認打開），允許將對象打散分配在棧上，比如對象擁有 id 和 name 兩個欄位，那麼這兩個欄位將會被視為兩個獨立的局部變數進行分配

逃逸分析的不足

關於逃逸分析的論文在 1999 年就已經發表了，但直到 JDK1.6 才有實現，而且這項技術到如今也並不是十分成熟的。

其根本原因就是無法保證逃逸分析的性能消耗一定能高於他的消耗。雖然經過逃逸分析可以做標量替換、棧上分配、和鎖消除。但是逃逸分析自身也是需要進行一系列複雜的分析的，這其實也是一個相對耗時的過程。

一個極端的例子，就是經過逃逸分析之後，發現沒有一個對象是不逃逸的。那這個逃逸分析的過程就白白浪費掉了。

雖然這項技術並不十分成熟，但是它也是即時編譯器優化技術中一個十分重要的手段。

注意到有一些觀點，認為通過逃逸分析，JVM 會在棧上分配那些不會逃逸的對象，這在理論上是可行的，但是取決於 JVM 設計者的選擇。據我所知，oracle Hotspot JVM 中並未這麼做，這一點在逃逸分析相關的文檔里已經說明，所以可以明確所有的對象實例都是創建在堆上。

目前很多書籍還是基於 JDK7 以前的版本，JDK 已經發生了很大變化，intern 字元串的快取和靜態變數曾經都被分配在永久代上，而永久代已經被元數據區取代。但是，intern 字元串快取和靜態變數並不是被轉移到元數據區，而是直接在堆上分配，所以這一點同樣符合前面一點的結論：對象實例都是分配在堆上。

小結

年輕代是對象的誕生、成長、消亡的區域，一個對象在這裡產生、應用，最後被垃圾回收器收集、結束生命。

老年代放置長生命周期的對象，通常都是從 survivor 區域篩選拷貝過來的 Java 對象。當然，也有特殊情況，我們知道普通的對象會被分配在 TLAB 上；如果對象較大，JVM 會試圖直接分配在 Eden 其他位置上；如果對象太大，完全無法在新生代找到足夠長的連續空閑空間，JVM 就會直接分配到老年代。當 GC 只發生在年輕代中，回收年輕代對象的行為被稱為 MinorGC。

當 GC 發生在老年代時則被稱為 MajorGC 或者 FullGC。一般的，MinorGC 的發生頻率要比 MajorGC 高很多，即老年代中垃圾回收發生的頻率將大大低於年輕代。

Tags: JVM