堆的核心概念
堆針對一個 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高很多，即老年代中垃圾回收發生的頻率將大大低於年輕代。