堆
堆的核心概念
堆針對一個 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 來進行分配
小結：堆空間的引數設定
官網說明：https://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 高很多，即老年代中垃圾回收發生的頻率將大大低於年輕代。