堆的核心概念
堆針對一個 JVM 程式來說是唯一的，也就是一個程式只有一個JVM，但是程式包含多個執行緒，他們是共享同一堆空間的。
一個JVM例項只存在一個堆記憶體，堆也是Java記憶體管理的核心區域。
Java堆區在JVM啟動的時候即被建立，其空間大小也就確定了。它是 JVM 管理的最大一塊記憶體空間。
《Java虛擬機器規範》規定，堆可以處於物理上不連續的記憶體空間中，但在邏輯上它應該被視為連續的。所有的執行緒共享Java堆，在堆中還可以劃分執行緒私有的緩衝區（Thread Local Allocation Buffer，TLAB）。
堆記憶體的大小如何調節？
-Xms10m：設定最小堆記憶體為10M。
-Xmx10m：設定最大堆記憶體為10M。
使用 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的時候，才會進行回收。如果堆中物件馬上被回收，那麼使用者執行緒就會收到影響。
堆，是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之前從永久代 替換成 元空間：
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: 若離
*
*/
public class Test {
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");
}
}
執行結果：
檢視堆記憶體的記憶體分配情況
檢視JVM堆記憶體GC情況:
jps（檢視JVM程式）--> jstat -gc 程式id（檢視JVM的GC情況）
jstat顯示結果：各引數所代表的內容。
JVM堆記憶體GC情況
配置JVM引數，檢視堆記憶體分配情況：（推薦）
-XX:+PrintGCDetails
Eclipse下配置:
當前專案程式編寫介面下點選右鍵 --> Run As --> Run configurations --> Arguments --> VM arguments中填寫引數 --> Apply --> Run。
堆記憶體分配情況
OutOfMemoryError示例
public class Test {
public static void main(String[] args) {
List<Integer> list = new ArrayList<>();
while(true) {
list.add(666666666);
}
}
}
執行結果：
年輕代和老年代
儲存在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"設定新生代最大記憶體大小。
這個引數一般使用預設值就可以了。
圖解記憶體分配過程
概念
為新物件分配記憶體是一件非常嚴謹和複雜的任務，JVM的設計者們不僅需要考慮記憶體如何分配、在哪裡分配等問題，並且由於記憶體分配演算法與記憶體回收演算法密切相關，所以還需要考慮GC執行完記憶體回收後是否會在記憶體空間中產生記憶體碎片。
➷ new的物件先放伊甸園區，此區有大小限制。
➷ 當伊甸園的空間填滿時，程式又需要建立物件，JVM的垃圾回收器將對伊甸園區進行垃圾回收（MinorGC），將伊甸園區中的不再被其他物件所引用的物件進行銷燬，然後將伊甸園中的剩餘物件移動到倖存者0區（或者1區，不確定），再載入新的物件放到伊甸園區。
➷ 如果再次觸發垃圾回收，此時上次倖存下來的放到倖存者0區的物件，如果沒有被回收，將會和本次伊甸園區中倖存下來的物件一起放到倖存者1區。
➷ 如果再次經歷垃圾回收，此時會將兩個有物件的區中倖存下來的物件重新放回倖存者0區。
➷ 之後，再放到倖存者1區，迴圈往復。
➷ 啥時候能去養老區呢？可以設定次數，預設是15次。可以通過設定引數：-XX:MaxTenuringThreshold= N 進行最大年齡的設定。
➷ 在養老區，相對悠閒。當養老區記憶體不足時，再次觸發GC：Major GC，進行養老區的記憶體清理。
➷ 若養老區執行了Major GC之後，發現依然無法進行物件的儲存，就會產生OOM異常。
圖解過程
當我們進行一次垃圾收集後，紅色的將會被回收，而綠色的還會被佔用著，存放在S0(Survivor From)區。同時我們給每個物件設定了一個年齡計數器，第一次回收後就是1。
同時Eden區繼續存放物件，當Eden區再次存滿的時候，又會觸發一個MinorGC操作，此時GC將會把 Eden和Survivor From中的物件進行一次收集，把存活的物件放到 Survivor To區，同時讓年齡 + 1。
我們繼續不斷的進行物件生成 和 垃圾回收，當Survivor中的物件的年齡達到15的時候，將會觸發一次 Promotion晉升的操作，也就是將年輕代中的物件 晉升到 老年代中。
注意事項
★ 如果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);
}
}
}
設定引數：-Xms600m -Xmx600m
然後cmd輸入：jvisualvm，開啟VisualVM圖形化介面
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
總結
✔ 針對倖存者s0，s1區的總結：複製之後有交換，誰空誰是to。
✔ 關於垃圾回收：頻繁在新生區收集，很少在老年代收集，幾乎不再永久代或元空間進行收集（也就是方法區）。
✔ 新生代採用複製演算法的目的：是為了減少記憶體碎片。
Minor GC，Major GC，Full GC
Minor GC：新生代的GC。
Major GC：老年代的GC。
Full GC：整堆收集，收集整個Java堆和方法區的垃圾收集。
我們都知道，JVM的調優的一個環節，也就是垃圾收集，我們需要儘量的避免垃圾回收，因為在垃圾回收的過程中，容易出現STW的問題，而 Major GC 和 Full GC出現STW的時間，是Minor GC的10倍以上。
JVM在進行GC時，並非每次都對上面三個記憶體區域一起回收的，大部分時候回收的都是指新生代。針對Hotspot VM的實現，它裡面的GC按照回收區域又分為兩大種型別：一種是部分收集（Partial GC），一種是整堆收集（FullGC）。
★ 部分收集：不是完整收集整個Java堆的垃圾收集。其中又分為：
➷ 新生代收集（MinorGC/YoungGC）：只是新生代的垃圾收集。
➷ 老年代收集（MajorGC/oldGC）：只是老年代的垃圾收集。
目前，只有CMS GC會有單獨收集老年代的行為。
注意，很多時候Major GC會和Fu11GC混淆使用，需要具體分辨是老年代回收還是整堆回收。
★ 混合收集（MixedGC）：收集整個新生代以及部分老年代的垃圾收集。
目前，只有G1 GC會有這種行為。
★ 整堆收集（FullGC）：收集整個java堆和方法區的垃圾收集。
Minor GC
當年輕代空間不足時，就會觸發MinorGC，這裡的年輕代滿指的是Eden代滿，Survivor滿不會引發GC。（每次Minor GC會清理年輕代的記憶體。）
因為Java物件大多都具備『朝生夕滅』的特性，所以Minor GC非常頻繁，一般回收速度也比較快。
Minor GC會引發STW：暫停其它使用者的執行緒，等垃圾回收結束，使用者執行緒才恢復執行。
STW：stop the word。
Major GC
指發生在老年代的GC，物件從老年代消失時，我們說 “Major Gc” 或 “Full GC” 發生了。
出現了Major GC，經常會伴隨至少一次的Minor GC（但非絕對的，在Paralle1 Scavenge收集器的收集策略裡就有直接進行Major GC的策略選擇過程）。
也就是在老年代空間不足時，會先嚐試觸發Minor GC，如果之後空間還不足，則觸發Major GC。
Major GC的速度一般會比MinorGc慢10倍以上，STW的時間更長，如果Major GC後，記憶體還不足，就報OOM了。
Full GC
觸發Fu11 GC執行的情況有如下五種：
① 呼叫System.gc（）時，系統建議執行Fu11 GC，但是不必然執行。
② 老年代空間不足。
③ 方法區空間不足。
④ 通過Minor GC後進入老年代的平均大小大於老年代的可用記憶體。
⑤ 由Eden區、survivor space0（From Space）區向survivor space1（To Space）區複製時，物件大小大於To Space可用記憶體，則把該物件轉存到老年代，且老年代的可用記憶體小於該物件大小。
注意：Full GC 是開發或調優中儘量要避免的，這樣暫時時間會短一些。觸發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區中每熬過一次Minor GC，年齡就增加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中成功分配記憶體，但JVM確實是將TLAB作為記憶體分配的首選。
在程式中，開發人員可以通過選項“-XX:UseTLAB”設定是否開啟TLAB空間。預設情況下，TLAB空間的記憶體非常小，僅佔有整個Eden空間的1%。當然，我們可以通過選項“-XX:TLABWasteTargetPercent”設定TLAB空間所佔用Eden空間的百分比大小。
一旦物件在TLAB空間分配記憶體失敗時（放不下），JVM就會嘗試著通過使用加鎖機制確保資料操作的原子性，從而直接在Eden空間中分配記憶體。
TLAB分配過程
物件首先是通過TLAB開闢空間，如果不能放入，那麼需要通過Eden來進行分配。
堆空間的引數設定
➷ -XX:+PrintFlagsInitial：檢視所有的引數的預設初始值。
➷ -XX:+PrintFlagsFinal：檢視所有的引數的最終值（可能會存在修改，不再是初始值）。
➷ -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依然是有風險的。
如果小於，則改為進行一次Full GC。
☆ 如果HandlePromotionFailure=false，則改為進行一次Full GC。
堆是分配物件的唯一選擇麼？
逃逸分析
在《深入理解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 nb = new StringBuffer();
nb.append(s1);
nb.append(s2);
return nb;
}
如果想要不發生逃逸，可以這樣寫：
public static String createStringBuffer(String s1, String s2) {
StringBuffer nb = new StringBuffer();
nb.append(s1);
nb.append(s2);
return nb.toString();
}
傳到外面的並不是new出來的物件，而是生成的字串常量。
如何快速的判斷是否發生了逃逸分析？
就看new的物件是否在方法外被呼叫。
引數設定
在JDK 1.7 版本之後，HotSpot中預設就已經開啟了逃逸分析
如果使用的是較早的版本，開發人員則可以通過：
選項“-xx：+DoEscapeAnalysis"：顯式開啟逃逸分析。
選項“-xx：+PrintEscapeAnalysis"：檢視逃逸分析的篩選結果。
結論
開發中能使用區域性變數的，就不要使用在方法外定義。
使用逃逸分析，編譯器可以對程式碼做如下優化：
➷ 棧上分配：將堆分配轉化為棧分配。如果一個物件在子程式中被分配，要使指向該物件的指標永遠不會發生逃逸，物件可能是棧上分配的候選，而不是堆上分配
➷ 同步省略：如果一個物件被發現只有一個執行緒被訪問到，那麼對於這個物件的操作可以不考慮同步。
➷ 分離物件或標量替換：有的物件可能不需要作為一個連續的記憶體結構存在也可以被訪問到，那麼物件的部分（或全部）可以不儲存在記憶體，而是儲存在CPU暫存器中。
棧上分配
JIT編譯器在編譯期間根據逃逸分析的結果，發現如果一個物件並沒有逃逸出方法的話，就可能被優化成棧上分配。分配完成後，繼續在呼叫棧內執行，最後執行緒結束，棧空間被回收，區域性變數物件也被回收。這樣就無須進行垃圾回收了。
常見的棧上分配的場景：
給成員變數賦值
方法返回值
例項引用傳遞
舉例
我們通過舉例來說明 開啟逃逸分析 和 未開啟逃逸分析時候的情況。
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);
}
分析與總結
關於逃逸分析的論文在1999年就已經發表了，但直到JDK1.6才有實現，而且這項技術到如今也並不是十分成熟的。
其根本原因就是無法保證逃逸分析的效能消耗一定能高於它的消耗。雖然經過逃逸分析可以做標量替換、棧上分配、和鎖消除。但是逃逸分析自身也是需要進行一系列複雜的分析的，這其實也是一個相對耗時的過程。一個極端的例子，就是經過逃逸分析之後，發現沒有一個物件是不逃逸的，那這個逃逸分析的過程就白白浪費掉了。
雖然這項技術並不十分成熟，但是它也是即時編譯器優化技術中一個十分重要的手段。注意到有一些觀點，認為通過逃逸分析，JVM會在棧上分配那些不會逃逸的物件，這在理論上是可行的，但是取決於JVM設計者的選擇。就目前來說，oracle Hotspot JVM中並未這麼做，這一點在逃逸分析相關的文件裡已經說明，所以可以明確所有的物件例項都是建立在堆上。
目前很多書籍還是基於JDK7以前的版本，JDK已經發生了很大變化，intern字串的快取和靜態變數曾經都被分配在永久代上，而永久代已經被後設資料區取代。但是，intern字串快取和靜態變數並不是被轉移到後設資料區，而是直接在堆上分配，所以這一點同樣符合前面一點的結論：物件例項都是分配在堆上。
年輕代是物件的誕生、成長、消亡的區域，一個物件在這裡產生、應用，最後被垃圾回收器收集、結束生命。
老年代放置長生命週期的物件，通常都是從survivor區域篩選拷貝過來的Java物件。當然，也有特殊情況，我們知道普通的物件會被分配在TLAB上；如果物件較大，JVM會試圖直接分配在Eden其他位置上；如果物件太大，完全無法在新生代找到足夠長的連續空閒空間，JVM就會直接分配到老年代。
當GC只發生在年輕代中，回收年輕代物件的行為被稱為Minor Gc。
當GC發生在老年代時則被稱為Major Gc或者FullGC。一般的，Minor GC的發生頻率要比MajorGC高很多，即老年代中垃圾回收發生的頻率將大大低於年輕代。