JVM之堆

1、堆的核心概述

一个java程序对应一个进程 一个进程对应一个jvm实例 一个jvm实例中只有一个运行时数据区 一个运行时数据区只有一个方法区和堆 一个进程中的多个线程需要共享同一个方法区和堆空间 每个线程拥有独立的一套程序计数器，本地方法栈，虚拟机栈

1.1、堆的认识

• 一个JVM实例只存在一个堆内存，堆也是java内存管理的核心区域。
• java堆区在jvm启动的时候即将被创建，其空间大小也就确定了。是JVM管理的最大一块内存空间。
• 堆内存的大小是可以调节的
• 堆可以处于物理上不连续的内存空间中，但在逻辑上它应该被视为连续的
• 所有的线程共享java堆，在这里还可以划分线程私有的缓冲区
• 几乎所有的对象实例以及数组都应当在运行时分配在堆上
• 数组和对象可能永远不会存储在栈上，因为栈帧中保存引用，这个引用指向对象或者数组在堆中的位置
• 在方法结束后，堆中的对象不会马上被移除，仅仅在垃圾收集的时候才会被移除
• 堆，是GC-垃圾回收器指向垃圾回收的重要区域

1.1.1、堆内存大小设置

代码示例

JDK 自带的工具：Java VisualVM ，来查看堆内存

JVM参数

GC查看：四者相加等于10m

1.1.2、堆空间创建对象

代码示例

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.2、堆的细分内存结构

现代垃圾收集器大部分都基于分代收集理论设计，堆空间细分为：

Java7及之前堆内存逻辑上分为三部分：新生区+养老区+永久区

• Young/New Generation Space 新生区，又被划分为Eden区和Survivor区
• Old/Tenure generation space 养老区
• Permanent Space永久区

Java8及之后堆内存逻辑上分为三部分：新生区+养老区+元空间

• Young/New Generation Space 新生区，又被划分为Eden区和Survivor区
• Old/Tenure generation space 养老区
• Meta Space 元空间

约定：新生区 <–> 新生代 <–> 年轻代 、 养老区 <–> 老年区 <–> 老年代、 永久区 <–> 永久代

1.2.1、jdk工具查看堆内存

新生代又细分为伊甸园区、幸存者区。

• Eden Space：伊甸园区
• Surviver 0：幸存者0区
• Surviver 0：幸存者1区
• Old Gen：老年代
• Metaspace：元空间

1.2.2、idea运行查看堆内存

-XX:+PrintGCDetails

• def new generation：新生代    1) eden：伊甸园区    2) from：幸存者0区    3) to：幸存者1区
• tenured generation：老年代
• Metaspace：元空间

2、设置堆内存大小和OOM

2.1、堆空间大小设置

• java堆区用于存储java对象实例，那么堆的大小在JVM启动时就已经设定好了，大家可以通过选项“-Xmx”和“-Xms”来进行设置   1）“-Xms”用于表示堆区的起始内存，等价于-XX:InitialHeapSize   2）“-Xmx”用于表示堆区的最大内存，等价于-XX:MaxHeapSize
• 一旦堆区中的内存大小超过“-Xmx”所指定的最大内存时，就会抛出OutOfMemoryError（内存溢出）异常。
• 通常会将 -Xms 和 -Xmx两个参数配置相同的值，以避免每次垃圾回收完成后JVM重新分配内存，从而提高性能。
• 默认情况下，初始内存大小：物理电脑内存大小 / 64       最大内存大小：物理电脑内存大小 / 4

代码示例

/**
 * 1. 设置堆空间大小的参数
 * -Xms 用来设置堆空间（新生代+老年代）的初始内存大小
 *      -X 是jvm的运行参数
 *      ms 是memory start
 * -Xmx 用来设置堆空间（新生代+老年代）的最大内存大小
 *
 * 2. 默认堆空间的大小
 *      初始内存大小：物理电脑内存大小 / 64
 *      最大内存大小：物理电脑内存大小 / 4
 *
 * 3. 手动设置：-Xms600m -Xmx600m
 *     开发中建议将初始堆内存和最大的堆内存设置成相同的值。
 *
 * 4. 查看设置的参数：方式一： jps   /  jstat -gc 进程id
 *                 方式二：-XX:+PrintGCDetails
 */
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");
    }
}

设置堆初始化空间和最大空间

-Xms600m -Xmx600m

执行结果： -Xms : 580M -Xmx : 580M

两种查看堆内存的方式

1. 命令行指令：jps和jstat -gc 进程id

• OC：老年代总空间（OU为使用空间）
• EC：伊甸园区总空间（EU为使用空间）
• S0C：幸存者0区总空间（S0U为使用空间）
• S1C：幸存者1区总空间（S1U为使用空间）

总空间计算：409600 + 163840 + 20480 + 20480 = 614400；614400/1024 = 600

Java虚拟机中的堆内存总量为580？

因为幸存者0区和1区只能有一个存放对象，也就是说必须有一个是空的，所以只计算一个幸存者区

虚拟机堆空间计算：409600 + 163840 + 20480 = 593920；593920/1024 = 580

1. -XX:+PrintGCDetails

设置VM options

-Xms600m -Xmx600m -XX:+PrintGCDetails

返回结果

2.2、OutOfMemory举例

代码示例

/**
 * 设置虚拟机参数：-Xms600m -Xmx600m
 */
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)));
        }
    }
}

堆内存变化图

Old 区域一点一点在变大，直到最后一次垃圾回收器无法回收垃圾时，堆内存被撑爆，抛出 OutOfMemoryError 错误

执行结果

大对象导致的堆内存溢出

3、年轻代和老年代

3.1、概述分类

• 存储在JVM中的java对象可以被划分为两类：   1）一类是生命周期较短的瞬时对象，这类对象的创建和消亡都非常迅速   2）另外一类对象的生命周期却非常长，在某些极端的情况下还能够与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

配置伊甸园区和幸存者区在堆结构的占比

• Edu空间和另外两个Survivor空间缺省所占比例是8:1:1
• 可以通过-XX:SurvivorRatio=8，调整伊甸园区所占比例大小
• 几乎所有的java对象都是在Eden区被new出来的。
• 绝大部分java对象的销毁都在新生代进行了
• 可以使用选项“-Xmn”设置新生代最大内存大小（一般使用默认值，与比例冲突时有优先级）
• 有自适应机制，可能不是8:1:1，则需要手动设置

代码示例

/**
 * -Xms600m -Xmx600m
 *
 * -XX:NewRatio ： 设置新生代与老年代的比例。默认值是2.
 * -XX:SurvivorRatio ：设置新生代中Eden区与Survivor区的比例。默认值是8
 * -XX:-UseAdaptiveSizePolicy ：关闭自适应的内存分配策略  （暂时用不到）
 * -Xmn:设置新生代的空间的大小。 （一般不设置）
 *
 */
public class EdenSurvivorTest {
    public static void main(String[] args) {
        System.out.println("我只是来打个酱油~");
        try {
            Thread.sleep(1000000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

通过命令行查看：

• jinfo -flag SurvivorRatio 进程id：查询伊甸园区在年轻代的占比（默认8/10）
• jinfo -flag NewRatio 进程id：查询老年代在堆中的占比（默认2/3）

通过Java VisualVM查看：

• 伊甸园区：幸存者0区：幸存者1区 = 160:20:20 = 8:1:1
• 老年区：新生区 = 400:160+20+20 = 2:1

4、图解对象分配过程

4.1、概述

1. new的对象先放伊甸园区。此区有大小限制。
2. 当伊甸园区的空间填满时，程序又需要创建对象，JVM的垃圾回收器将对伊甸园区进行垃圾回收（Minor GC），将伊甸园区中的不再被其他对象所引用的对象进行销毁。再加载新的对象放到伊甸园区
3. 然后将伊甸园区中的剩余对象移动到幸存者0区
4. 如果再次触发垃圾回收，此时上次幸存下来的放到幸存者0区，如果没有回收，就会放到幸存者1区
5. 如果再次经历垃圾回收，此时会重新放回幸存者0区，接着再去幸存者1区。
6. 什么时候去养老区？可以设置次数。默认15次。可以设置参数：-XX:MaxTenuringThreshold=<N>进行设置
7. 在养老区，相对悠闲。当养老区内存不足时，再次触发GC：Major GC，进行养老区的内存清理
8. 若养老区执行了Major GC之后发现依然无法进行对象的保存，就会生成OOM异常（java.lang.OutOfMemoryError：Java heap space）

4.2、图解对象分配过程

• 我们创建的对象，一般都是存放在Eden区的，当我们Eden区满了后，就会触发GC操作，一般被称为 YGC / Minor GC操作
• 当我们进行一次垃圾收集后，红色的对象将会被回收，而绿色的独享还被占用着，存放在S0(Survivor From)区。同时我们给每个对象设置了一个年龄计数器，经过一次回收后还存在的对象，将其年龄加 1。

• 当Eden区再次存满的时候，又会触发一个MinorGC操作，此时GC将会把 Eden和Survivor From中的对象进行一次垃圾收集，把存活的对象放到 Survivor To区，同时让存活的对象年龄 + 1

在这里插入图片描述

• 不断的进行对象生成和垃圾回收，当Survivor中的对象的年龄达到15的时候，将会触发一次 Promotion 晋升的操作，也就是将年轻代中的对象晋升到老年代中

代码示例

/**
 * -Xms600m -Xmx600m
 */
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();
            }
        }
    }
}

注意【伊甸园区、幸存者区、老年区】的内存变化趋势

• 幸存者0区和1区只能有一个有对象
• 伊甸园可以主动触发GC，幸存者区只能跟随伊甸园区被动触发GC

4.3、对象分配的特殊情况

1. 如果来了一个新对象，先看看 Eden 是否放的下？   1）如果 Eden 放得下，则直接放到 Eden 区   2）如果 Eden 放不下，则触发 YGC ，执行垃圾回收，看看还能不能放下？放得下最好当然最好咯
2. 将对象放到老年区又有两种情况：   1）如果Eden放不下，且对象大于Eden空间，则不触发GC，直接放入老年代   2）如果 Eden 执行了 YGC 还是无法放不下该对象，那没得办法，只能说明是超大对象，只能直接怼到老年代   3）那万一老年代都放不下，则先触发重 GC ，再看看能不能放下，放得下最好，但如果还是放不下，那只能报 OOM 啦
3. 如果 Eden 区满了，将对象往幸存区拷贝时，发现幸存区放不下啦，那只能便宜了某些新对象，让他们直接晋升至老年区

5、Minor GC、Major GC与Full GC

JVM在进行GC时，并非每次都对上面三个内存（新生代、老年代；方法区）区域一起回收的，大部分时候回收的都是指新生代。 针对HotSpot VM的实现，它里面的GC按照回收区域又分为两个种类型：一种是部分收集（Partial GC），一种是整堆收集（Full GC）

• 部分收集：不是完整收集整个java堆的垃圾收集。   1）新生代收集（Minor GC / Young GC）：只是新生代的垃圾收集   2）老年代收集（Major GC / Old GC）：只是老年代的垃圾收集   3）混合收集（Mixed GC）：收集整个新生代以及部分老年代的垃圾收集。目前，只有G1 GC会有这种行为
• 整堆收集（Full GC）：收集整个java堆和方法区的垃圾收集

5.1、年轻代 GC

年轻代GC（Minor GC / Young GC）触发机制

• 当年轻代空间不足时，就会触发Minor GC，这里的年轻代满指的是Eden满，Survivor满不会触发GC。（每次Minor GC会清理年轻代的内存）
• 因为java对象大多都具备朝生夕死的特性，所以Minor GC非常频繁，一般回收素的也比较快。
• Minor GC会引发STW（暂停其他用户的线程，等垃圾回收结束，用户线程才能恢复运行）

图解垃圾回收

5.2、老年代 GC

老年代GC（Major GC / Full GC）触发机制

• 发生在老年代的GC，对象从老年代消失时，我们说“Major GC”或“Full GC”发生了
• 出现了Major GC，经常会伴随至少一次的Minor GC（但非绝对的，在ParallelScavenge收集器的手机策略中就有直接进行Major GC的策略选择过程）
• 在老年代空间不足时，会先尝试触发Minor GC。如果之后空间还不足，则触发Major GC
• Major GC的速度一般会比Minor GC慢10倍以上，STW的时间更长
• 如果Major GC后，内存还不足，就报OOM了

Full GC触发机制（后面细讲 ）

• 调用System.gc()时，系统建议执行Full GC，但是不必然执行
• 老年代空间不足
• 方法区空间不足
• 通过Minor GC后进入老年代的平均大小大于老年代的可用内存
• 由Eden区、S0区向S1区复制时，对象大小大于S1可用内存，则把该对象转存到老年代，且老年代的可用内存小于该对象大小

full gc是开发或者调优中尽量要避免的。这样用户线程暂停的时间会短一些

5.3、GC举例与日志分析

代码示例

/**
 * 测试MinorGC 、 MajorGC、FullGC
 * VM参数：-Xms9m -Xmx9m -XX:+PrintGCDetails
 *
 */
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);
        }
    }
}

执行结果

6、堆空间分代思想

为什么需要把java堆分代？不分代就不能正常工作了吗？

• 经研究，不同对象的生命周期不用。70%-99%的对象是临时对象
• 新生代：有Eden、两块大小相同的Survivor（又称为from/to，s0/s1）构成，to总是空。
• 老年代：存放新生代中经历多次GC仍然存活的对象
• 其实不分代完全可以，分代的唯一理由就是优化GC性能   1）如果没有分代，那所有的对象都在一块，就如同把一个学校的人都关在一个教室。GC的时候要找到哪些对象没用，这样就会对堆的所有区域进行扫描   2）而很多对象都是朝生夕死的，如果分代的话，把新创建的对象放到某一地方，当GC的时候先把这块存储“朝生夕死”对象的区域进行回收，这样就会腾出很大的空间出来

在这里插入图片描述

7、内存分配策略

内存分配策略或对象提升（Promotion）规则

针对不同年龄段的对象分配原则如下所示：

• 优先分配到Eden：开发中比较长的字符串或者数组，会直接存在老年代，但是因为新创建的对象都是朝生夕死的，所以这个大对象可能也很快被回收，但是因为老年代触发Major GC的次数比 Minor GC要更少，因此可能回收起来就会比较慢
• 大对象直接分配到老年代：尽量避免程序中出现过多的大对象
• 长期存活的对象分配到老年代
• 动态对象年龄判断：如果Survivor区中相同年龄的所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。
• 空间分配担保： -XX:HandlePromotionFailure ，也就是经过Minor GC后，所有的对象都存活，因为Survivor比较小，所以就需要将Survivor无法容纳的对象，存放到老年代中。

代码示例

/**
 * 测试：大对象直接进入老年代
 * VM参数：-Xms60m -Xmx60m -XX:NewRatio=2 -XX:SurvivorRatio=8 -XX:+PrintGCDetails
 */
public class YoungOldAreaTest {
    public static void main(String[] args) {
        byte[] buffer = new byte[1024 * 1024 * 20];//20m
    }
}

执行结果

年轻代占比3/1，伊甸园占比10/8，所以Eden16m，老年代40m；数组20m，Eden放不下而且整个空间小于20m，所以没有执行GC，直接放入老年代。

8、为对象分配内存：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中分配对象失败（空间不足），则在Eden中加锁并且为对象分配空间，防止其他线程操作此空间

9、小结堆空间参数设置

常用参数设置

• -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：是否设置空间分配担保

-XX:HandlePromotionFalilure 设置空间分配担保

在发生Minor GC之前，虚拟机会检查老年代最大可用的连续空间是否大于新生代所有对象的总空间。   1）如果大于，则此次Minor GC是安全的   2）如果小于，则虚拟机会查看-XX:HandlePromotionFailure设置值是否允担保失败。     a.如果HandlePromotionFailure=true，那么会继续检查老年代最大可用连续空间是否大于历次晋升到老年代的对象的平均大小。       I.如果大于，则尝试进行一次Minor GC，但这次Minor GC依然是有风险的；       II.如果小于，则进行一次Full GC。     b.如果HandlePromotionFailure=false，则进行一次Full GC。

JDK7以后，此参数不可设置，默认为true

10、堆的优化

10.1、逃逸分析

堆是分配对象存储的唯一选择吗？

• 在《深入理解Java虚拟机》中关于java堆内存有这样一段描述：随着JIT编译期的发展与逃逸分析技术逐渐成熟，栈上分配、标量替换优化技术将会导致一些微妙的变化，所有的对象都分配到堆上也渐渐变得不那么“绝对”了
• 在java虚拟机中，对象是在java堆中分配内存的，这是一个普遍的常识，但是，有一种特殊情况，那就是如果经过逃逸分析后发现，一个对象并没有逃逸出方法的话，那么久可能被优化成栈上分配。这样就无需在堆上分配内存，也无序进行垃圾回收了。这也是最常见的堆外存储技术。
• 此外，前面提到的基于OpenJDK深度定制的TaoBaoVM，其中创建的GCIH（GC invisible heap）技术实现off-heap，将生命周期较长的java对象从heap移至heap外，并且GC不能管理GCIH内部的java对象，一次达到降低GC的回收频率和提升GC的回收效率的目的。

逃逸分析概述

• 如何将堆上的对象分配到栈，需要使用逃逸分析手段
• 这是一种可以有效减少java程序中同步负载和内存堆分配压力的跨函数全局数据流分析算法
• 通过逃逸分析，java hostspot 编译器能够分析出一个新的对象的引用的使用范围从而决定是否将这个对象分配到堆上。
• 逃逸分析的基本行为就是分析对象动态作用域   1）当一个对象在方法中被定义后，对象只在方法内部使用，则认为没有发生逃逸   2）当一个对象在方法中被定义后，它被外部方法所引用，则认为发生逃逸。
• 开发中能使用局部变量的，就不要使用在方法外定义。

逃逸分析参数设置

• 在JDK 1.7 版本之后，HotSpot中默认就已经开启了逃逸分析
• 如果使用的是较早的版本，开发人员则可以通过：   1）选项“-XX:+DoEscapeAnalysis"显式开启逃逸分析   2）选项“-XX:+PrintEscapeAnalysis"查看逃逸分析的筛选结果

代码示例

1. 没有发生逃逸的对象，则可以分配到栈上，随着方法执行的结束，栈空间就被移除

public void my_method() {
    V v = new V();
    // use v
    // ....
    v = null;
}

1. 下面代码中的 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();
}

10.2、栈上分配

• 将堆分配转化为栈分配。如果一个对象在子程序中被分配，要使指向该对象的指针永远不会逃逸，对象可能是栈分配的候选，而不是堆分配。
• JIT编译器在编译期间根据逃逸分析的结果，发现如果一个对象并没有逃逸出方法的话，就可能被优化成栈上分配。分配完成后，继续在调用栈内执行，最后线程结束，栈空间被回收，局部变量对象也被回收。这样就不需要进行垃圾回收了
• 常见的栈上分配场景，在逃逸分析中已说明。分别是给成员变量赋值、方法返回值、实例引用传递。

代码示例

/**
 * 栈上分配测试
 * VM参数：-server -Xmx1G -Xms1G -XX:-DoEscapeAnalysis -XX:+PrintGCDetails
 */
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");
        // 为了方便查看堆内存中对象个数，线程sleep
        try {
            Thread.sleep(1000000);
        } catch (InterruptedException e1) {
            e1.printStackTrace();
        }
    }

    private static void alloc() {
        User user = new User();//未发生逃逸
    }
    static class User {
    }
}

• VM参数：-server -Xmx1G -Xms1G -XX:-DoEscapeAnalysis -XX:+PrintGCDetails
• 花费的时间：43ms
• 关闭逃逸分析，此时1000万对象都创建在堆上

• VM参数：-server -Xmx1G -Xms1G -XX:+DoEscapeAnalysis -XX:+PrintGCDetails
• 花费的时间：4ms
• 开启逃逸分析，这里起作用的是标量替换（后面会讲，默认开启，如果关闭则所有对象都会分配到堆上），另外有一部分对象依然分配在堆上，如果循环少一些（创建对象少一些），堆上则不会创建对象。这里暂时没搞懂为啥

结论：开启逃逸分析后，应该就是只有标量替换生效，而没有使用栈上分配

10.3、同步省略

如果一个对象被发现只能从一个线程被访问到，那么对于这个对象的操作可以不考虑同步。

• 线程同步的代价是相当高的，同步的后果是降低并发性和性能
• 在动态编译同步块的时候，JIT编译器可以借助逃逸分析来判断同步块所使用的锁对象是否只能够被一个线程访问而没有被发布到其他线程。如果没有，那么JIT编译器在编译这个同步块的时候就会取消对这部分代码的同步。这样就能大大提供并发性和性能。这个取消同步的过程就叫同步省略，也叫锁消除。

代码示例

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

以上代码，hellis作为锁，每个线程进入f()方法，都会创建Object()对象，此时每个线程都能进入同步方法，锁已无意义，所以JIT编译器会将同步过程消除成为以下代码

public void f() {
    Object hellis = new Object();
	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);
}

结论： 1.可以看到，Point这个聚合量经过逃逸分析后，发现他并没有逃逸，就被替换成两个聚合量了。 2.那么标量替换有什么好处呢？就是可以大大减少堆内存的占用。因为一旦不需要创建对象了，那么就不再需要分配堆内存了。 3.标量替换为栈上分配提供了很好的基础。

标量替换参数设置

参数 -XX:+EliminateAllocations：开启了标量替换（默认打开），允许将对象打散分配在栈上，不需要GC。

逃逸分析的不足

• 关于逃逸分析的论文在1999年就已经发表了，但直到JDK1.6才有实现，而且这项技术到如今也并不是十分成熟的。
• 其根本原因就是无法保证逃逸分析的性能消耗一定能高于他的消耗。虽然经过逃逸分析可以做标量替换、栈上分配、和锁消除。但是逃逸分析自身也是需要进行一系列复杂的分析的，这其实也是一个相对耗时的过程。一个极端的例子，就是经过逃逸分析之后，发现没有一个对象是不逃逸的。那这个逃逸分析的过程就白白浪费掉了。
• 虽然这项技术并不十分成熟，但是它也是即时编译器优化技术中一个十分重要的手段。注意到有一些观点，认为通过逃逸分析，JVM会在栈上分配那些不会逃逸的对象，这在理论上是可行的，但是取决于JVM设计者的选择。Oracle Hotspot JVM中并未这么做，这一点在逃逸分析相关的文档里已经说明，所以可以明确所有的对象实例都是创建在堆上。
• 目前很多书籍还是基于JDK7以前的版本，JDK已经发生了很大变化，intern字符串的缓存和静态变量曾经都被分配在永久代上，而永久代已经被元数据区取代。但是intern字符串缓存和静态变量并不是被转移到元数据区，而是直接在堆上分配，所以这一点同样符合前面一点的结论：对象实例都是分配在堆上。

栈上分配（创建对象还没实现），只是实现了标量替换（将对象打散），所以本质上对象还是都分配在堆上

11、堆小结

• 年轻代是对象的诞生、成长、消亡的区域，一个对象在这里产生、应用，最后被垃圾回收器收集、结束生命。
• 老年代放置长生命周期的对象，通常都是从Survivor区域筛选拷贝过来的Java对象。
• 当然，也有特殊情况，我们知道普通的对象可能会被分配在TLAB上；
• 如果对象较大，无法分配在 TLAB 上，则JVM会试图直接分配在Eden其他位置上；
• 如果对象太大，完全无法在新生代找到足够长的连续空闲空间，JVM就会直接分配到老年代。
• 当GC只发生在年轻代中，回收年轻代对象的行为被称为Minor GC。
• 当GC发生在老年代时则被称为Major GC或者Full GC。
• 一般的，Minor GC的发生频率要比Major GC高很多，即老年代中垃圾回收发生的频率将大大低于年轻代。