第 8 章深入理解堆

1、堆的核心概述

1.1、認識堆記憶體

堆與行程

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

對堆的認識

一個JVM實體只存在一個堆記憶體，堆也是Java記憶體管理的核心區域，
Java堆區 在JVM啟動的時候即被創建，其空間大小也就確定了，堆是JVM管理的最大一塊記憶體空間，并且 堆記憶體的大小是可以調節的，
《Java虛擬機規范》規定， 堆可以處于物理上不連續的記憶體空間中，但在邏輯上它應該被視為連續的，
所有的執行緒共享Java堆，在這里還可以劃分 執行緒私有的緩沖區（Thread Local Allocation Buffer，TLAB），
《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，垃圾收集器）執行垃圾回收的重點區域，

一個JVM實體只存在一個堆記憶體，并且堆記憶體的大小是可以調節的

如何設定堆記憶體大小

行程 1

-Xms10m -Xmx10m

行程 2

-Xms20m -Xmx20m

1.2、查看堆記憶體

使用 JDK 自帶的工具：Java VisualVM ，來查看堆記憶體

Java VisualVM 在 JDK 的 bin 目錄下

行程 1 ：堆記憶體為 10 M

行程 2 ：堆記憶體為 20 M

代碼示例

代碼

public class SimpleHeap {
    private int id;

    public SimpleHeap(int id) {
        this.id = id;
    }

    public void show() {
        System.out.println("My ID is " + id);
    }

    public static void main(String[] args) {
        SimpleHeap sl = new SimpleHeap(1);
        SimpleHeap s2 = new SimpleHeap(2);
        int[] arr = new int[10];
        Object[] arr1 = new Object[10];
    }
}

位元組碼指令

1.3、堆記憶體磁區

堆記憶體細分

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

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

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

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

約定：新生區
堆空間內部結構，JDK1.8之前從永久代替換成元空間

Java VisualVM 查看堆記憶體

安裝 Visual GC

吶：新生代、老年代、元空間

2、設定堆記憶體大小與 OOM

2.1、設定堆記憶體

設定堆空間大小

Java堆區用于存盤Java物件實體，那么堆的大小在JVM啟動時就已經設定好了，大家可以通過選項"-Xms"和"-Xmx"來進行設定，

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

一旦堆區中的記憶體大小超過"-Xmx"所指定的最大記憶體時，將會拋出OutofMemoryError例外，
通常會將-Xms和-Xmx兩個引數配置相同的值，其目的是為了能夠在Java垃圾回識訓制清理完堆區后不需要重新分隔計算堆區的大小，從而提高性能，
默認情況下:

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

代碼示例

代碼


public class HeapSpaceInitial {
    public static void main(String[] args) {

        long initialMemory = Runtime.getRuntime().totalMemory() / 1024 / 1024;

        long maxMemory = Runtime.getRuntime().maxMemory() / 1024 / 1024;

        System.out.println("-Xms : " + initialMemory + "M");
        System.out.println("-Xmx : " + maxMemory + "M");
    }
}

兩種查看堆記憶體的方式
- 方式一：命令列依次執行如下兩個指令
  - jps
  - jstat -gc 行程id
- 方式二：設定虛擬機引數 -XX:+PrintGCDetails
為什么設定 600MB ，算出來只有 575MB 呢？
- JVM 認為幸存者 to 區并不存放物件（to 區一直為空），所以沒把它算上
- 可以看到新生區的大小 = 伊甸園區大小 + 幸存者 from 區大小
- 即 179200KB = 153600KB + 25600KB

2.2、OOM 舉例

OOM舉例

代碼


public class OOMTest {
    public static void main(String[] args) {
        ArrayList<Picture> list = new ArrayList<>();
        while(true){
            try {
                Thread.sleep(20);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            list.add(new Picture(new Random().nextInt(1024 * 1024)));
        }
    }
}

設定虛擬機引數

-Xms600m -Xmx600m

監控堆記憶體變化：Old 區域一點一點在變大，直到最后一次垃圾回收器無法回收垃圾時，堆記憶體被撐爆，拋出 OutOfMemoryError 錯誤

堆記憶體變化圖

分析原因： *大物件導致堆記憶體溢位

3、年輕代與老年代

3.1、Java 物件分類

Java 物件的分類

存盤在JVM中的Java物件可以被劃分為兩類：

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

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

Java堆區進一步細分的話，可以劃分為 年輕代（YoungGen）和 老年代（oldGen）
其中年輕代又可以劃分為Eden空間、Survivor0空間和Survivor1空間（有時也叫做from區、to區）

3.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"設定新生代最大記憶體大小，但這個引數一般使用默認值就可以了，
新生區的物件默認生命周期超過 15 ，就會去養老區養老

代碼示例

代碼


public class EdenSurvivorTest {
    public static void main(String[] args) {
        System.out.println("我只是來打個醬油~");
        try {
            Thread.sleep(1000000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

通過命令列查看各種比例
- 查看新生代與老年代的比例

jps
jinfo -flag NewRatios &#x8FDB;&#x7A0B;id

查看新生區中伊甸園區與幸存者區的比例

jps
jinfo -flag SurvivorRatio &#x8FDB;&#x7A0B;id

設定 JVM 引數

-Xms600m -Xmx600m -XX:SurvivorRatio=8

新生區中：伊甸園區 : 幸存者 0 區 : 幸存者 1 區 = 8 : 1 : 1
新生區 : 老年區 = 1 : 2

4、圖解物件分配程序

4.1、物件分配程序

物件分配程序

物件分配難點：

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

物件分配程序

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

4.2、圖解物件分配

圖解物件分配程序

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

當我們進行一次垃圾收集后，紅色的物件將會被回收，而綠色的獨享還被占用著，存放在S0(Survivor From)區，同時我們給每個物件設定了一個年齡計數器，經過一次回收后還存在的物件，將其年齡加 1，
同時Eden區繼續存放物件，當Eden區再次存滿的時候，又會觸發一個MinorGC操作，此時GC將會把 Eden和Survivor From中的物件進行一次垃圾收集，把存活的物件放到 Survivor To區，同時讓存活的物件年齡 + 1

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

代碼示例

代碼


public class HeapInstanceTest {
    byte[] buffer = new byte[new Random().nextInt(1024 * 200)];

    public static void main(String[] args) {
        ArrayList<HeapInstanceTest> list = new ArrayList<HeapInstanceTest>();
        while (true) {
            list.add(new HeapInstanceTest());
            try {
                Thread.sleep(10);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }
}

注意【伊甸園區、幸存者區、老年區】的記憶體變化趨勢

4.3、特殊情況說明

思考：幸存區滿了咋辦？

特別注意，在Eden區滿了的時候，才會觸發MinorGC，而 幸存者區滿了后，不會觸發MinorGC操作
如果Survivor區滿了后，將會觸發一些特殊的規則，也就是可能直接晉升老年代

物件分配的特殊情況

如果來了一個新物件，先看看 Eden 是否放的下？

如果 Eden 放得下，則直接放到 Eden 區
如果 Eden 放不下，則觸發 YGC ，執行垃圾回收，看看還能不能放下？放得下最好當然最好咯~~~

將物件放到老年區又有兩種情況：

如果 Eden 執行了 YGC 還是無法放不下該物件，那沒得辦法，只能說明是超大物件，只能直接懟到老年代
那萬一老年代都放不下，則先觸發重 GC ，再看看能不能放下，放得下最好，但如果還是放不下，那只能報 OOM 啦~~~

如果 Eden 區滿了，將物件往幸存區拷貝時，發現幸存區放不下啦，那只能便宜了某些新物件，讓他們直接晉升至老年區

4.4、常用調優工具

常用的 JVM 調優工具

常用調優工具

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

Jprofiler 基本使用

在 IDEA 中啟動 Jprofiler

點擊 Instrumentation

選擇默認配置即可，點擊【OK】啟動

喏~~~

總結

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

5、GC 垃圾回收器

5.1、分代收集思想

Minor GC、Major GC、Full GC

我們都知道，JVM的調優的一個環節，也就是垃圾收集，我們需要盡量的避免垃圾回收，因為在垃圾回收的程序中，容易出現STW（Stop the World）的問題， 而 Major GC 和 Full GC出現STW的時間，是Minor GC的10倍以上
JVM在進行GC時，并非每次都對上面三個記憶體區域一起回收的，大部分時候回收的都是指新生代，針對Hotspot VM的實作，它里面的GC按斬訓收區域又分為兩大種型別：一種是部分收集（Partial GC），一種是整堆收集（FullGC）

分代收集：

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

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

整堆收集（Full GC）：收集整個java堆和方法區的垃圾收集，

5.2、Young GC

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

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

; 5.3、Major/Full GC

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

指發生在老年代的GC，物件從老年代消失時，我們說 "Major Gc" 或 "Full GC" 發生了
出現了MajorGc，經常會伴隨至少一次的Minor GC

但非絕對的，在Parallel Scavenge收集器的收集策略里就有直接進行MajorGC的策略選擇程序
也就是在老年代空間不足時，會先嘗試觸發Minor GC（哈？我有點迷？），如果之后空間還不足，則觸發Major GC

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

Full GC 觸發機制（后面細講）

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

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

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

GC 日志分析

代碼


public class GCTest {
    public static void main(String[] args) {
        int i = 0;
        try {
            List<String> list = new ArrayList<>();
            String a = "atguigu.com";
            while (true) {
                list.add(a);
                a = a + a;
                i++;
            }

        } catch (Throwable t) {
            t.printStackTrace();
            System.out.println("遍歷次數為：" + i);
        }
    }
}

JVM 引數

-Xms9m -Xmx9m -XX:+PrintGCDetails

GC 日志：在 OOM 之前，一定會觸發一次 Full GC ，因為只有在老年代空間不足時候，才會爆出OOM例外

"C:\Program Files\Java\jdk1.8.0_144\bin\java" -Xms9m -Xmx9m -XX:+PrintGCDetails "-javaagent:C:\Program Files\JetBrains\IntelliJ IDEA 2017.3.1\lib\idea_rt.jar=13200:C:\Program Files\JetBrains\IntelliJ IDEA 2017.3.1\bin" -Dfile.encoding=UTF-8 -classpath "C:\Program Files\Java\jdk1.8.0_144\jre\lib\charsets.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\deploy.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\access-bridge-64.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\cldrdata.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\dnsns.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\jaccess.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\jfxrt.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\localedata.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\nashorn.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\sunec.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\sunjce_provider.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\sunmscapi.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\sunpkcs11.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\zipfs.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\javaws.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\jce.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\jfr.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\jfxswt.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\jsse.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\management-agent.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\plugin.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\resources.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\rt.jar;C:\Users\Heygo\Desktop\JVMDemo\out\production\chapter08" com.atguigu.java1.GCTest
[GC (Allocation Failure) [PSYoungGen: 2020K->510K(2560K)] 2020K->812K(9728K), 0.0021339 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[GC (Allocation Failure) [PSYoungGen: 2550K->488K(2560K)] 2852K->2278K(9728K), 0.0005931 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[GC (Allocation Failure) [PSYoungGen: 1949K->504K(2560K)] 3740K->3062K(9728K), 0.0005918 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[Full GC (Ergonomics) [PSYoungGen: 1319K->0K(2560K)] [ParOldGen: 6782K->4864K(7168K)] 8102K->4864K(9728K), [Metaspace: 3452K->3452K(1056768K)], 0.0050464 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
[GC (Allocation Failure) [PSYoungGen: 0K->0K(2560K)] 4864K->4864K(9728K), 0.0003452 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[Full GC (Allocation Failure) [PSYoungGen: 0K->0K(2560K)] [ParOldGen: 4864K->4846K(7168K)] 4864K->4846K(9728K), [Metaspace: 3452K->3452K(1056768K)], 0.0061555 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
&#x904D;&#x5386;&#x6B21;&#x6570;&#x4E3A;&#xFF1A;16
Heap
 PSYoungGen      total 2560K, used 134K [0x00000000ffd00000, 0x0000000100000000, 0x0000000100000000)
  eden space 2048K, 6% used [0x00000000ffd00000,0x00000000ffd219f0,0x00000000fff00000)
  from space 512K, 0% used [0x00000000fff80000,0x00000000fff80000,0x0000000100000000)
  to   space 512K, 0% used [0x00000000fff00000,0x00000000fff00000,0x00000000fff80000)
 ParOldGen       total 7168K, used 4846K [0x00000000ff600000, 0x00000000ffd00000, 0x00000000ffd00000)
  object space 7168K, 67% used [0x00000000ff600000,0x00000000ffabba00,0x00000000ffd00000)
 Metaspace       used 3498K, capacity 4496K, committed 4864K, reserved 1056768K
  class space    used 384K, capacity 388K, committed 512K, reserved 1048576K
java.lang.OutOfMemoryError: Java heap space
	at java.util.Arrays.copyOf(Arrays.java:3332)
	at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
	at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:448)
	at java.lang.StringBuilder.append(StringBuilder.java:136)
	at com.atguigu.java1.GCTest.main(GCTest.java:21)

Process finished with exit code 0

[PSYoungGen: 1319K->0K(2560K)] ：年輕代總空間為 2560K ，當前占用 1319K ，經過垃圾回收后剩余 0K
[ParOldGen: 6782K->4864K(7168K)] ：老年代總空間為 7168K ，當前占用 6782K ，經過垃圾回收后剩余 4864K
8102K->4864K(9728K)：堆記憶體總空間為 9728K ，當前占用 8102K ，經過垃圾回收后剩余 4864K
[Metaspace: 3452K->3452K(1056768K)] ：元空間總空間為 1056768K ，當前占用 3452K ，經過垃圾回收后剩余 3452K
0.0050464 secs ：垃圾回收用時 0.0050464 secs

[Full GC (Ergonomics) [PSYoungGen: 1319K->0K(2560K)] [ParOldGen: 6782K->4864K(7168K)] 8102K->4864K(9728K), [Metaspace: 3452K->3452K(1056768K)], 0.0050464 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]

6、堆空間分代思想

為什么需要分代？

為什么要把Java堆分代？不分代就不能正常作業了嗎？經研究，不同物件的生命周期不同，70%-99%的物件是臨時物件，

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

其實不分代完全可以， 分代的唯一理由就是優化GC性能，

如果沒有分代，那所有的物件都在一塊，就如同把一個學校的人都關在一個教室，GC的時候要找到哪些物件沒用，這樣就會對堆的所有區域進行掃描，
而很多物件都是朝生夕死的，如果分代的話，把新創建的物件放到某一地方，當GC的時候先把這塊存盤"朝生夕死"物件的區域進行回收，這樣就會騰出很大的空間出來，

7、記憶體分配策略

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

如果物件在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無法容納的物件，存放到老年代中，

代碼示例

代碼


public class YoungOldAreaTest {
    public static void main(String[] args) {
        byte[] buffer = new byte[1024 * 1024 * 20];

    }
}

JVM 引數

-Xms60m -Xmx60m -XX:NewRatio=2 -XX:SurvivorRatio=8 -XX:+PrintGCDetails

整個程序并沒有進行垃圾回收，并且 ParOldGen 區直接占用了 20MB 的空間，說明大物件直接懟到了老年代中

"C:\Program Files\Java\jdk1.8.0_144\bin\java" -Xms60m -Xmx60m -XX:NewRatio=2 -XX:SurvivorRatio=8 -XX:+PrintGCDetails "-javaagent:C:\Program Files\JetBrains\IntelliJ IDEA 2017.3.1\lib\idea_rt.jar=5495:C:\Program Files\JetBrains\IntelliJ IDEA 2017.3.1\bin" -Dfile.encoding=UTF-8 -classpath "C:\Program Files\Java\jdk1.8.0_144\jre\lib\charsets.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\deploy.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\access-bridge-64.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\cldrdata.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\dnsns.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\jaccess.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\jfxrt.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\localedata.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\nashorn.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\sunec.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\sunjce_provider.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\sunmscapi.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\sunpkcs11.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\zipfs.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\javaws.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\jce.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\jfr.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\jfxswt.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\jsse.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\management-agent.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\plugin.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\resources.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\rt.jar;C:\Users\Heygo\Desktop\JVMDemo\out\production\chapter08" com.atguigu.java1.YoungOldAreaTest
Heap
 PSYoungGen      total 18432K, used 2637K [0x00000000fec00000, 0x0000000100000000, 0x0000000100000000)
  eden space 16384K, 16% used [0x00000000fec00000,0x00000000fee935c8,0x00000000ffc00000)
  from space 2048K, 0% used [0x00000000ffe00000,0x00000000ffe00000,0x0000000100000000)
  to   space 2048K, 0% used [0x00000000ffc00000,0x00000000ffc00000,0x00000000ffe00000)
 ParOldGen       total 40960K, used 20480K [0x00000000fc400000, 0x00000000fec00000, 0x00000000fec00000)
  object space 40960K, 50% used [0x00000000fc400000,0x00000000fd800010,0x00000000fec00000)
 Metaspace       used 3469K, capacity 4496K, committed 4864K, reserved 1056768K
  class space    used 381K, capacity 388K, committed 512K, reserved 1048576K

Process finished with exit code 0

8、為物件分配記憶體

8.1、為什么有 TLAB

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

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

為什么有TLAB（Thread Local Allocation Buffer）？

TLAB：Thread Local Allocation Buffer，也就是為每個執行緒單獨分配了一個緩沖區
堆區是執行緒共享區域，任何執行緒都可以訪問到堆區中的共享資料
由于物件實體的創建在JVM中非常頻繁，因此在并發環境下從堆區中劃分記憶體空間是執行緒不安全的
為避免多個執行緒操作同一地址，需要使用 加鎖等機制，進而影響分配速度，

8.2、什么是 TLAB

什么是 TLAB？

從記憶體模型而不是垃圾收集的角度，對Eden區域繼續進行劃分， JVM為每個執行緒分配了一個私有快取區域，它包含在Eden空間內，
多執行緒同時分配記憶體時， 使用TLAB可以避免一系列的非執行緒安全問題，同時還能夠提升記憶體分配的吞吐量，因此我們可以將這種記憶體分配方式稱之為 快速分配策略，
據我所知所有OpenJDK衍生出來的JVM都提供了TLAB的設計，

8.3、TLAB 分配程序

TLAB 的說明

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

TLAB 分配程序

代碼示例

代碼


public class TLABArgsTest {
    public static void main(String[] args) {
        System.out.println("我只是來打個醬油~");
        try {
            Thread.sleep(1000000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

查看 UseTLAB 標志位的狀態

C:\Users\Heygo>jps
C:\Users\Heygo>jinfo -flag UseTLAB 15420

我并沒有設定任何 JVM 引數，通過命令列查看 TLAB 是否開啟：結論是默認情況是開啟 TLAB

9、堆空間引數設定

9.1、常用引數設定

官方檔案

https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html

常用引數設定

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

9.2、空間分配擔保

關于空間分配擔保

在發生Minor GC之前，虛擬機會檢查老年代最大可用的連續空間是否大于新生代所有物件的總空間，

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

歷史版本

在JDK6 Update 24之后，HandlePromotionFailure引數不會再影響到虛擬機的空間分配擔保策略，觀察openJDK中的原始碼變化，雖然原始碼中還定義了HandlePromotionFailure引數，但是在代碼中已經不會再使用它，
JDK6 Update 24之后的規則變為只要老年代的連續空間大于新生代物件總大小或者歷次晉升的平均大小就會進行Minor GC，否則將進行Full GC，即 HandlePromotionFailure=true

代碼示例

代碼


public class HeapArgsTest {
    public static void main(String[] args) {

    }
}

10、致命面試題

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

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

隨著JIT編譯期的發展與逃逸分析技術逐漸成熟， 堆疊上分配、標量替換優化技術將會導致一些微妙的變化，所有的物件都分配到堆上也漸漸變得不那么"絕對"了，
在Java虛擬機中，物件是在Java堆中分配記憶體的，這是一個普遍的常識，但是，有一種特殊情況，那就是如果經過逃逸分析（Escape Analysis）后發現，一個物件并沒有逃逸出方法的話，那么就可能被優化成堆疊上分配，這樣就無需在堆上分配記憶體，也無須進行垃圾回收了，這也是最常見的堆外存盤技術，
此外，前面提到的基于OpenJDK深度定制的TaoBao VM，其中創新的GCIH（GC invisible heap）技術實作off-heap，將生命周期較長的Java物件從heap中移至heap外，并且GC不能管理GCIH內部的Java物件，以此達到降低GC的回收頻率和提升GC的回收效率的目的，

如何將堆上的物件分配到堆疊，需要使用逃逸分析手段，

這是一種可以有效減少Java程式中同步負載和記憶體堆分配壓力的跨函式全域資料流分析演算法，
通過逃逸分析，Java Hotspot編譯器能夠分析出一個新的物件的參考的使用范圍從而決定是否要將這個物件分配到堆上，
逃逸分析的基本行為就是分析物件動態作用域：

當一個物件在方法中被定義后，物件只在方法內部使用，則認為沒有發生逃逸，
當一個物件在方法中被定義后，它被外部方法所參考，則認為發生逃逸，例如作為呼叫引數傳遞到其他地方中，

10.1、逃逸分析

逃逸分析舉例

沒有發生逃逸的物件，則可以分配到堆疊上，隨著方法執行的結束，堆疊空間就被移除

public void my_method() {
    V v = new V();

    v = null;
}

下面代碼中的 StringBuffer sb 發生了逃逸

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();
}

逃逸分析的舉例


public class EscapeAnalysis {

    public EscapeAnalysis obj;

    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 useEscapeAnalysis1(){
        EscapeAnalysis e = getInstance();

    }
}

逃逸分析引數設定

在JDK 1.7 版本之后，HotSpot中默認就已經開啟了逃逸分析
如果使用的是較早的版本，開發人員則可以通過：

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

逃逸分析結論

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

逃逸分析之代碼優化

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

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

10.2、堆疊上分配

堆疊上分配

JIT編譯器在編譯期間根據逃逸分析的結果，發現如果一個物件并沒有逃逸出方法的話，就可能被優化成堆疊上分配，
分配完成后，繼續在呼叫堆疊內執行，最后執行緒結束，堆疊空間被回收，區域變數物件也被回收，這樣就無須進行垃圾回收了，
常見的堆疊上分配的場景：在逃逸分析中，已經說明了，分別是給成員變數賦值、方法回傳值、實體參考傳遞，

堆疊上分配舉例

代碼


public class StackAllocation {
    public static void main(String[] args) {
        long start = System.currentTimeMillis();

        for (int i = 0; i < 10000000; i++) {
            alloc();
        }

        long end = System.currentTimeMillis();
        System.out.println("花費的時間為： " + (end - start) + " ms");

        try {
            Thread.sleep(1000000);
        } catch (InterruptedException e1) {
            e1.printStackTrace();
        }
    }

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

    static class User {

    }
}

未開啟逃逸分析的情況

JVM 引數設定

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

日志列印：發生了 GC ，耗時 46ms

"C:\Program Files\Java\jdk1.8.0_144\bin\java" -Xmx256m -Xms256m -XX:-DoEscapeAnalysis -XX:+PrintGCDetails "-javaagent:C:\Program Files\JetBrains\IntelliJ IDEA 2017.3.1\lib\idea_rt.jar=4674:C:\Program Files\JetBrains\IntelliJ IDEA 2017.3.1\bin" -Dfile.encoding=UTF-8 -classpath "C:\Program Files\Java\jdk1.8.0_144\jre\lib\charsets.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\deploy.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\access-bridge-64.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\cldrdata.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\dnsns.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\jaccess.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\jfxrt.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\localedata.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\nashorn.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\sunec.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\sunjce_provider.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\sunmscapi.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\sunpkcs11.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\zipfs.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\javaws.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\jce.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\jfr.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\jfxswt.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\jsse.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\management-agent.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\plugin.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\resources.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\rt.jar;C:\Users\Heygo\Desktop\JVMDemo\out\production\chapter08" com.atguigu.java2.StackAllocation
[GC (Allocation Failure) [PSYoungGen: 65536K->808K(76288K)] 65536K->816K(251392K), 0.0009467 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[GC (Allocation Failure) [PSYoungGen: 66344K->872K(76288K)] 66352K->880K(251392K), 0.0006768 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
&#x82B1;&#x8D39;&#x7684;&#x65F6;&#x95F4;&#x4E3A;&#xFF1A; 46 ms

堆上面有好多好多 User 物件

開啟逃逸分析的情況

JVM 引數設定

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

日志列印：并沒有發生 GC ，耗時 3ms ，堆疊上分配是真的快啊

"C:\Program Files\Java\jdk1.8.0_144\bin\java" -Xmx256m -Xms256m -XX:+DoEscapeAnalysis -XX:+PrintGCDetails "-javaagent:C:\Program Files\JetBrains\IntelliJ IDEA 2017.3.1\lib\idea_rt.jar=4732:C:\Program Files\JetBrains\IntelliJ IDEA 2017.3.1\bin" -Dfile.encoding=UTF-8 -classpath "C:\Program Files\Java\jdk1.8.0_144\jre\lib\charsets.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\deploy.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\access-bridge-64.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\cldrdata.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\dnsns.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\jaccess.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\jfxrt.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\localedata.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\nashorn.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\sunec.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\sunjce_provider.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\sunmscapi.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\sunpkcs11.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\zipfs.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\javaws.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\jce.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\jfr.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\jfxswt.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\jsse.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\management-agent.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\plugin.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\resources.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\rt.jar;C:\Users\Heygo\Desktop\JVMDemo\out\production\chapter08" com.atguigu.java2.StackAllocation
&#x82B1;&#x8D39;&#x7684;&#x65F6;&#x95F4;&#x4E3A;&#xFF1A; 3 ms

其實我有點迷糊，不是說堆疊上分配嗎，為啥堆中還是有 User 物件？

10.3、同步省略

同步省略

執行緒同步的代價是相當高的，同步的后果是降低并發性和性能，
在動態編譯同步塊的時候，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);
}

位元組碼分析

代碼

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

注意：位元組碼檔案中并沒有進行優化，可以看到加鎖和釋放鎖的操作依然存在， *同步省略操作是在解釋運行時發生的

10.4、標量替換

分離物件或標量替換

標量（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這個聚合量經過逃逸分析后，發現他并沒有逃逸，就被替換成兩個聚合量了，
那么標量替換有什么好處呢？就是可以大大減少堆記憶體的占用，因為一旦不需要創建物件了，那么就不再需要分配堆記憶體了，
標量替換為堆疊上分配提供了很好的基礎，

標量替換引數設定

引數 -XX:+ElimilnateAllocations：開啟了標量替換（默認打開），允許將物件打散分配在堆疊上，

代碼示例

代碼


public class ScalarReplace {
    public static class User {
        public int id;
        public String name;
    }

    public static void alloc() {
        User u = new User();
        u.id = 5;
        u.name = "www.atguigu.com";
    }

    public static void main(String[] args) {
        long start = System.currentTimeMillis();
        for (int i = 0; i < 10000000; i++) {
            alloc();
        }
        long end = System.currentTimeMillis();
        System.out.println("花費的時間為： " + (end - start) + " ms");
    }
}

未開啟標量替換

JVM 引數

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

日志分析：伴隨著 GC 的垃圾回收，用時 46ms

"C:\Program Files\Java\jdk1.8.0_144\bin\java" -Xmx100m -Xms100m -XX:+DoEscapeAnalysis -XX:+PrintGC -XX:-EliminateAllocations "-javaagent:C:\Program Files\JetBrains\IntelliJ IDEA 2017.3.1\lib\idea_rt.jar=12593:C:\Program Files\JetBrains\IntelliJ IDEA 2017.3.1\bin" -Dfile.encoding=UTF-8 -classpath "C:\Program Files\Java\jdk1.8.0_144\jre\lib\charsets.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\deploy.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\access-bridge-64.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\cldrdata.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\dnsns.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\jaccess.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\jfxrt.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\localedata.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\nashorn.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\sunec.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\sunjce_provider.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\sunmscapi.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\sunpkcs11.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\zipfs.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\javaws.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\jce.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\jfr.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\jfxswt.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\jsse.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\management-agent.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\plugin.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\resources.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\rt.jar;C:\Users\Heygo\Desktop\JVMDemo\out\production\chapter08" com.atguigu.java2.ScalarReplace
[GC (Allocation Failure)  25600K->816K(98304K), 0.0009418 secs]
[GC (Allocation Failure)  26416K->792K(98304K), 0.0007337 secs]
[GC (Allocation Failure)  26392K->792K(98304K), 0.0006104 secs]
[GC (Allocation Failure)  26392K->856K(98304K), 0.0009474 secs]
[GC (Allocation Failure)  26456K->824K(98304K), 0.0007392 secs]
[GC (Allocation Failure)  26424K->808K(101376K), 0.0009449 secs]
[GC (Allocation Failure)  32552K->720K(101376K), 0.0010633 secs]
[GC (Allocation Failure)  32464K->720K(100352K), 0.0004493 secs]
&#x82B1;&#x8D39;&#x7684;&#x65F6;&#x95F4;&#x4E3A;&#xFF1A; 46 ms

Process finished with exit code 0

開啟標量替換

JVM 引數

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

日志分析：無垃圾回收，用時 4ms

"C:\Program Files\Java\jdk1.8.0_144\bin\java" -Xmx100m -Xms100m -XX:+DoEscapeAnalysis -XX:+PrintGC -XX:+EliminateAllocations "-javaagent:C:\Program Files\JetBrains\IntelliJ IDEA 2017.3.1\lib\idea_rt.jar=12607:C:\Program Files\JetBrains\IntelliJ IDEA 2017.3.1\bin" -Dfile.encoding=UTF-8 -classpath "C:\Program Files\Java\jdk1.8.0_144\jre\lib\charsets.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\deploy.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\access-bridge-64.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\cldrdata.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\dnsns.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\jaccess.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\jfxrt.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\localedata.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\nashorn.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\sunec.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\sunjce_provider.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\sunmscapi.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\sunpkcs11.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\zipfs.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\javaws.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\jce.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\jfr.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\jfxswt.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\jsse.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\management-agent.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\plugin.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\resources.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\rt.jar;C:\Users\Heygo\Desktop\JVMDemo\out\production\chapter08" com.atguigu.java2.ScalarReplace
&#x82B1;&#x8D39;&#x7684;&#x65F6;&#x95F4;&#x4E3A;&#xFF1A; 4 ms

Process finished with exit code 0

逃逸分析引數設定總結

上述代碼在主函式中呼叫了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字串快取和靜態變數并不是被轉移到元資料區，而是直接在堆上分配，所以這一點同樣符合前面一點的結論：物件實體都是分配在堆上，

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

綜上： 物件實體都是分配在堆上，What the fuck？

11、堆小結

年輕代是物件的誕生、成長、消亡的區域，一個物件在這里產生、應用，最后被垃圾回收器收集、結束生命，
老年代放置長生命周期的物件，通常都是從Survivor區域篩選拷貝過來的Java物件，
當然，也有特殊情況，我們知道普通的物件可能會被分配在TLAB上；
如果物件較大，無法分配在 TLAB 上，則JVM會試圖直接分配在Eden其他位置上；
如果物件太大，完全無法在新生代找到足夠長的連續空閑空間，JVM就會直接分配到老年代，
當GC只發生在年輕代中，回收年輕代物件的行為被稱為Minor GC，
當GC發生在老年代時則被稱為Major GC或者Full GC，
一般的，Minor GC的發生頻率要比Major GC高很多，即老年代中垃圾回收發生的頻率將大大低于年輕代，

你只管學習，我來負責記筆記?? 關注公眾號！ ,更多筆記，等你來拿，謝謝

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/168236.html

標籤：其他

上一篇：<table> tr 洗掉

下一篇：java

深入理解堆

第 8 章 深入理解堆

1、堆的核心概述

1.1、認識堆記憶體

1.2、查看堆記憶體

1.3、堆記憶體磁區

2、設定堆記憶體大小與 OOM

2.1、設定堆記憶體

2.2、OOM 舉例

3、年輕代與老年代

3.1、Java 物件分類

3.2、配置新老比例

4、圖解物件分配程序

4.1、物件分配程序

4.2、圖解物件分配

4.3、特殊情況說明

4.4、常用調優工具

5、GC 垃圾回收器

5.1、分代收集思想

5.2、Young GC

; 5.3、Major/Full GC

6、堆空間分代思想

7、記憶體分配策略

8、為物件分配記憶體

8.1、為什么有 TLAB

8.2、什么是 TLAB

8.3、TLAB 分配程序

9、堆空間引數設定

9.1、常用引數設定

9.2、空間分配擔保

10、致命面試題

10.1、逃逸分析

10.2、堆疊上分配

10.3、同步省略

10.4、標量替換

11、堆小結

第 8 章深入理解堆