堆

堆的核心概念

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

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

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

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

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

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

-Xms10m：初始堆記憶體

-Xmx10m：最大堆記憶體

下圖就是使用：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會影響使用者執行緒的執行

堆，是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之前從永久代 替換成 元空間

以上是邏輯上的劃分，實際上我們通過"-Xmx"和"-Xms"來進行設定的堆空間只是新生區+養老區的大小，暫時沒管永久代/元空間。

設定堆記憶體大小與OOM

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

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

一旦堆區中的記憶體大小超過“-xmx"所指定的最大記憶體時，將會丟擲outofMemoryError異常。

通常會將-Xms和-Xmx兩個引數配置相同的值，其目的是為了能夠在java垃圾回收機制清理完堆區後不需要重新分隔計算堆區的大小，即避免頻繁GC帶來的系統壓力，從而提高效能。

預設情況下

• 初始記憶體大小：物理電腦記憶體大小1/64

• 最大記憶體大小：物理電腦記憶體大小1/4

/**
 * -Xms 用來設定堆空間（年輕代+老年代）的初始記憶體大小
 *  -X：是jvm執行引數
 *  ms：memory start
 * -Xmx：用來設定堆空間（年輕代+老年代）的最大記憶體大小
 */
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");
		System.out.println("系統記憶體大小為:" + initialMemory * 64.0 / 1024 + "G");
		System.out.println("系統記憶體大小為:" + maxMemory * 64.0 / 1024 + "G");
    }
}

輸出結果

-Xms:245M
-Xmx:3614M
系統記憶體大小為:15.3125G
系統記憶體大小為：14.152345375G

可見，滿足：堆空間初始記憶體大小佔物理電腦記憶體大小1/64，最大記憶體大小佔物理電腦記憶體大小1/4

如何檢視堆記憶體的記憶體分配情況

檢視設定的引數：
	方式一：
		   命令列：
				jps  ->  檢視當前正在執行的程式，得到相應程式id
				jstat -gc 程式id -> 檢視該程式記憶體分配情況

	方式二：
		   -XX:+PrintGCDetails

/**
 * 設定-Xms600m -Xmx600m
 */
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;
     	try{
			Thread.sleep(1000000);
		}catch(InterruptedException e){
			e.printStackTrace();
		}

    }
}

輸出結果

-Xms:575M
-Xmx:575M

可見，結果顯示的堆記憶體大小不等於我們設定的600M，原因：堆空間由伊甸園區和survivor 0區、survivor 1區組成，但儲存物件時，除伊甸園區外，我們只能在survivor 0區和survivor 1區中二選一，這是由於垃圾回收的複製演算法。因此，顯示的堆空間是由伊甸園區加一個survivor區的空間所得。當然，以上三部分相加即為我們設定的總體600M。

堆空間即為新生代+老年代，上圖中OC、OU即為老年代，前者為老年代總共的空間，後者為使用的空間（used）；新生代分為伊甸園區（Eden）、倖存者（Survivor）零區、倖存者（Survivor）一區，同樣“C”表示總體空間，“U”表示使用了的空間。

-XX:+PrintGCDetails

OutOfMemory舉例

我們簡單的寫一個OOM例子（不斷向堆中存資料）

/**
 * OOM測試
 */
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區）

檢視新生代與老年代在在堆結構的佔比方式：

• 方式一：命令列

    jps-->檢視程式id
    jinfo -flag  SurvivorRatio 程式id-->檢視Eden空間和另外兩個survivor空間預設所佔的比例
    							         （預設8：1：1）
    jinfo -flag  NewRatio 程式id-->新生代與老年代在在堆結構的佔比（預設1 : 2）
  

• 方式二：視覺化工具
  

• 方式三：-XX:+PrintGCDetails
  

  執行程式，列印日誌資訊：
  

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

預設情況下

• 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。

這裡需要注意，雖然預設Eden空間和另外兩個survivor空間預設所佔的比例是8：1：1，通過上面的命令列顯示也是8：1：1。但是，事實上，存在自適應機制，導致這個值事實上不是8：1：1，可通過命令列以及Visual GC工具手動計算出來，如下例，自適應的比例為6：1：1。

網上一些資料說，如果想恢復預設的8：1：1比例，我們應當顯式地關閉自適應記憶體分配策略，即：-XX:-UseAdaptiveSizePolicy（第二個減號即意味著關閉，若為加號則意味使用），但實際使用會發現沒用，還是之前6：1：1。因而，我們如果想恢復預設的8：1：1比例，必須顯式地指定比例為8：1：1，即通過“-XX:SurvivorRatio”調整這個空間比例，比如-XX:SurvivorRatio=8。

小結：

• -XX:NewRatio ： 設定新生代與老年代的比例，預設值為2
• -XX:SurvivorRatio ： 設定新生代中Eden區與Survivor區的比例，預設值為8
  • 由於自適應記憶體分配策略，事實上需顯式指定才能為預設的8：1：1
• -XX:-UseAdaptiveSizePolicy ： 關閉自適應記憶體分配策略（暫時用不到）
• 幾乎所有的Java物件都是在Eden區被new出來的。（有些大的物件在Eden區無法儲存時候，將直接進入老年代）
• 絕大部分的Java物件的銷燬都在新生代進行了。

IBM公司的專門研究表明，新生代中80%的物件都是“朝生夕死”的。

可以使用選項"-Xmn"設定新生代最大記憶體大小
當同時設定-XX:NewRatio和-Xmn時，以-Xmn顯式指定的記憶體大小為準。
不過這個引數一般使用預設值就可以了，一般不設定。

圖解物件分配過程

概念

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

• new的物件先放伊甸園區。此區有大小限制。
• 當伊甸園的空間填滿時，程式又需要建立物件，JVM的垃圾回收器將對伊甸園區進行垃圾回收（MinorGC），將伊甸園區中的不再被其他物件所引用的物件進行銷燬。再載入新的物件放到伊甸園區
• 然後將伊甸園中的剩餘物件移動到倖存者0區。
• 如果再次觸發垃圾回收，此時上次倖存下來的放到倖存者0區的，如果沒有回收，就會放到倖存者1區。
• 如果再次經歷垃圾回收，此時會重新放回倖存者0區，接著再去倖存者1區。
• 啥時候能去養老區呢？可以設定次數。預設是15次。
  • 可以設定引數：-XX:MaxTenuringThreshold= N進行設定
• 在養老區，相對悠閒。當養老區記憶體不足時，再次觸發GC：Major GC，進行養老區的記憶體清理
• 若養老區執行了Major GC之後，發現依然無法進行物件的儲存，就會產生OOM異常。

圖解過程

我們建立的物件，一般都是先存放在Eden區的，當我們Eden區滿了後，就會觸發GC操作，一般被稱為 YGC / Minor GC操作（Young GC）

當我們進行一次垃圾收集後，紅色的將會被回收，而綠色的還會被佔用著，存放在倖存者S0(Survivor From)區。同時我們給每個物件設定了一個年齡計數器，一次回收後就是1。（此時，Eden區清空。此時，s1空，所以此時s1為to區，s0為from區。）
同時Eden區繼續存放物件，當Eden區再次存滿的時候，又會觸發一個MinorGC操作，此時GC將會把 Eden和Survivor From中的物件 進行一次收集，把存活的物件放到 Survivor To區，同時讓年齡 + 1。（此時，s0清空，所以此時s0變為to區，s1為from區。每一次執行GC後，誰空誰就是to區，to區即代表下一次GC時，Eden區的物件要往哪放）

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

總結：

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

思考：倖存區區滿了後？

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

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

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

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

物件分配的特殊情況

程式碼演示物件分配過程

我們不斷的建立大物件

/**
 * 程式碼演示物件建立過程
 */
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
• GCEasy

Minor GC，MajorGC、Full GC

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

我們都知道，JVM的調優的一個環節，也就是垃圾收集，我們需要儘量的避免垃圾回收，因為在垃圾回收的過程中，容易出現STW（stop the world，中止使用者執行緒）的問題

而 Major GC 和 Full GC出現STW的時間，是Minor GC的10倍以上，因此，主要關注 Major GC 和 Full GC

Stop the World機制，簡稱STW，即在執行垃圾收集演算法時,Java應用程式的其他所有除了垃圾收集收集器執行緒之外的執行緒都被掛起

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

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

• 新生代收集（Minor GC/Young GC）：只是新生代（Eden\S0,S1）的垃圾收集
• 老年代收集（Major GC/old GC）：只是老年代的圾收集。
  • 目前，只有CMS GC會有單獨收集老年代的行為。
  • 注意，很多時候Major GC會和Full GC混淆使用，需要具體分辨是老年代回收還是整堆回收。
• 混合收集（Mixed GC）：收集整個新生代以及部分老年代的垃圾收集。
  • 目前，只有G1 GC會有這種行為

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

Minor GC

新生代GC（Minor GC/YGC）觸發機制：

當年輕代空間不足時，就會觸發Minor GC，這裡的年輕代滿指的是Eden代滿，Survivor滿不會引發GC。（每次Minor GC會清理年輕代的記憶體。）

因為Java物件大多都具備 朝生夕滅 的特性，所以Minor GC非常頻繁，一般回收速度也比較快。這一定義既清晰又易於理解。

Minor GC會引發STW，暫停其它使用者的執行緒，等垃圾回收結束，使用者執行緒才恢復執行

STW：stop the word

Major GC

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

指發生在老年代的GC，物件從老年代消失時，我們說 “Major GC” 或 “Full GC” 發生了

出現了MajorGC，經常會伴隨至少一次的Minor GC（但非絕對的，在Paralle1 Scavenge收集器的收集策略裡就有直接進行MajorGC的策略選擇過程）

• 也就是在老年代空間不足時，會先嚐試觸發MinorGC。如果之後空間還不足，則觸發Major GC

Major GC的速度一般會比MinorGC慢10倍以上，STW的時間更長，如果Major GC後，記憶體還不足，就報OOM了

Full GC

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

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

說明：Full GC 是開發或調優中儘量要避免的。這樣暫時時間會短一些

GC 舉例

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

/**
 * GC測試
 */
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的時候先把這塊儲存“朝生夕死”物件的區域進行回收，這樣就會騰出很大的空間出來。

記憶體分配策略（或物件提升（Promotion）規則）

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

物件晉升老年代的年齡閥值，可以通過選項**-XX:MaxTenuringThreshold**來設定

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

• 優先分配到Eden
  • 開發中比較長的字串或者陣列，會直接存在老年代，但是因為新建立的物件 都是 朝生夕死的，所以這個大物件可能也很快被回收，如此為了儲存該大物件承受的STW就顯得很可惜。但是因為老年代觸發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中成功分配記憶體，但JVM確實是將TLAB作為記憶體分配的首選。

在程式中，開發人員可以通過選項“-XX:UseTLAB”設定是否開啟TLAB空間，預設開啟。

預設情況下，TLAB空間的記憶體非常小，僅佔有整個Eden空間的1%，當然我們可以通過選項“-Xx:TLABWasteTargetPercent”設定TLAB空間所佔用Eden空間的百分比大小。

一旦物件在TLAB空間分配記憶體失敗時，JVM就會嘗試著通過使用加鎖機制確保資料操作的原子性，從而直接在Eden空間中分配記憶體。

TLAB分配過程

物件首先是通過TLAB開闢空間，如果不能放入，那麼需要通過Eden來進行分配。當然，對於一些大物件，我們直接放在老年區。

小結：堆空間的引數設定

• -XX：+PrintFlagsInitial：檢視所有的引數的預設初始值

• -XX：+PrintFlagsFinal：檢視所有的引數的最終值（可能會存在修改，不再是初始值，前面有“："即說明存在重新賦值）

  相當於具體檢視某個引數的指令：
  jps：檢視當前 執行中的程式
  jinfo -flag 要檢視的引數（如：SurvivorRatio） 程式id

• -Xms：初始堆空間記憶體（預設為實體記憶體的1/64）

• -Xmx：最大堆空間記憶體（預設為實體記憶體的1/4）

• -Xmn：設定新生代的大小。（初始值及最大值）

• -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，即理解恆為ture即可。

堆是分配物件的唯一選擇麼？

逃逸分析

在《深入理解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的物件實體是否在方法外被呼叫。
 */
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"檢視逃逸分析的篩選結果

結論

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

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

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

棧上分配

JIT編譯器在編譯期間根據逃逸分析的結果，發現如果一個物件並沒有逃逸出方法的話，就可能被優化成棧上分配。分配完成後，繼續在呼叫棧內執行，最後執行緒結束，棧空間被回收，區域性變數物件也被回收。這樣就無須進行垃圾回收了（棧上不需要GC）。

常見的發生逃逸，不能棧上分配的場景

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

舉例

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

/**
 * 棧上分配
 * -Xmx1G -Xms1G -XX:-DoEscapeAnalysis -XX:+PrintGCDetails
 */
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引數，表示未開啟逃逸分析

-Xmx256m -Xms256m -XX:-DoEscapeAnalysis -XX:+PrintGCDetails

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

花費的時間為：664 ms

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

我們在開啟逃逸分析

-Xmx256m -Xms256m -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階段，如果經過逃逸分析，發現一個物件不會被外界訪問的話，那麼經過J工T優化，就會把這個物件拆解成若干個其中包含的若干個成員變數來代替。這個過程就是標量替換。

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這個聚合量經過逃逸分析後，發現他並沒有逃逸，就被替換成兩個聚合量了。那麼標量替換有什麼好處呢？就是可以大大減少堆記憶體的佔用。因為一旦不需要建立物件了，那麼就不再需要分配堆記憶體了，同時由於直接在棧上分配，也避免了GC。

標量替換為棧上分配提供了很好的基礎。

標量替換引數設定

引數-XX:+EliminateAllocations:開啟了標量替換（預設開啟），允許將物件打散分配在棧上，相當於變形的棧上分配。

可見，使用標量替換，大大節省執行時間，且無需GC（棧不需要GC）。

程式碼優化之標量替換

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

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

這裡設定引數如下：

• 引數-server：啟動Server模式，因為在server模式下，才可以啟用逃逸分析。（64位預設即為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高很多，即老年代中垃圾回收發生的頻率將大大低於年輕代。