第八章 堆
1、堆的核心概述
这里的堆和方法区都是用红色显示，一方面是说明其重要，另一方面呢？一个Java程序运行，对应着一个进程，也就对应着一个JVM实例(Runtime实例，这个类也是用管道单例模式，饿汉式)，对于一个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，垃圾收集器）执行垃圾回收的重点区域。
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]; } }
比如这个main方法创建的s1和s2对象，是在哪里呢？
堆内存细分
现代垃圾收集器大部分都基于分代收集理论设计，堆空间细分为：
- Java7 及之前堆内存逻辑上分为三部分：新生区+养老区+永久区
- Young Generation Space 新生区 Young/New
- 又被划分为Eden区和Survivor区
- Old generation space 养老区 Old/Tenure
- Permanent Space 永久区 Perm
- Young Generation Space 新生区 Young/New
- Java 8及之后堆内存逻辑上分为三部分：新生区+养老区+元空间
- Young Generation Space 新生区，又被划分为Eden区和Survivor区
- Old generation space 养老区
- Meta Space 元空间 Meta
约定：新生区 <=> 新生代 <=> 年轻代 、 养老区 <=> 老年区 <=> 老年代、 永久区 <=> 永久代
理论上堆空间分为：新生区、养老区、养老区(jdk8后是元空间)。但是实际上堆空间只是年轻代和老年代，永久代不在堆空间的管辖范围，其有方法区管辖。这有点像中华人民共和国分为中国大陆、港澳和台湾，但是呢？台湾暂时不属于咱管辖。
jvisualvm可视化查看堆内存
通过这个可视化，我们可以看出虽然堆是分为新生代、养老代和元空间。但是呢？实际实现上元空间不归堆管理。
package com.atguigu.java; /* * -Xms10m -Xmx10m * */ public class HeapDemo { public static void main(String[] args) { System.out.println("start..."); try { Thread.sleep(10000000000L); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println("end..."); } }
运行上述代码：并在运行前设置VM参数：Run->Edit Configurations->VM Options: -Xms10m -Xmx10m -> apply；然后运行程序
打开jdk自带的工具jvisualvm：方式1：找到jdk，找到bin目录；找到该工具；双击打开。2、在cmd窗口下输入jvisualvm并回车，因为我们已经配置了环境变量。
可以看到：新生代和养老代总和正是我们设置的10M。而新生代又分为三个，这个后面讲。
堆空间内部结构：jdk8及之后由永久代 替换成员空间
怎么证明上面的改变呢？运行如下程序：并设置VM参数。(其实此时我们要查看一下这个模块选择的JDK版本是不是8，还有运行时的jre环境是不是8)
/* * -Xms10m -Xmx10m -XX:+PrintGCDetails * */ public class HeapDemo { public static void main(String[] args) { System.out.println("start..."); System.out.println("end..."); } }
然后控制台为：
start...
end...
Heap
PSYoungGen total 2560K, used 1550K [0x00000000ffd00000, 0x0000000100000000, 0x0000000100000000)
eden space 2048K, 75% used [0x00000000ffd00000,0x00000000ffe83bf0,0x00000000fff00000)
from space 512K, 0% used [0x00000000fff80000,0x00000000fff80000,0x0000000100000000)
to space 512K, 0% used [0x00000000fff00000,0x00000000fff00000,0x00000000fff80000)
ParOldGen total 7168K, used 0K [0x00000000ff600000, 0x00000000ffd00000, 0x00000000ffd00000)
object space 7168K, 0% used [0x00000000ff600000,0x00000000ff600000,0x00000000ffd00000)
Metaspace used 3032K, capacity 4496K, committed 4864K, reserved 1056768K
class space used 328K, capacity 388K, committed 512K, reserved 1048576K
由于我这里没有其它JDK版本，我就选择老师的图放在这里。当我们设置jre环境为8以下，比如7时：
2、设置堆内存大小与OOM
-
Java堆区用于存储Java对象实例，那么堆的大小在JVM启动时就已经设定好了，大家可以通过选项"-Xms"和"-Xmx"来进行设置。
- -Xms用于表示堆区的起始内存，等价于**-XX:InitialHeapSize**
- -Xmx则用于表示堆区的最大内存，等价于**-XX:MaxHeapSize**
-
一旦堆区中的内存大小超过“-Xmx"所指定的最大内存时，将会抛出OutofMemoryError异常。
-
通常会将-Xms和-Xmx两个参数配置相同的值
- 原因：假设两个不一样，初始内存小，最大内存大。在运行期间如果堆内存不够用了，会一直扩容直到最大内存。如果内存够用且多了，也会不断的缩容释放。频繁的扩容和释放造成不必要的压力，避免在GC之后调整堆内存给服务器带来压力。
- 如果两个设置一样的就少了频繁扩容和缩容的步骤。内存不够了就直接报OOM
-
默认情况下:
- 初始内存大小：物理电脑内存大小/64
- 最大内存大小：物理电脑内存大小/4
package com.atguigu.java; /** * 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; // Runtime.getRuntime()相当于整个运行时数据区的实例，是单例的 //返回Java虚拟机试图使用的最大堆内存量 long maxMemory = Runtime.getRuntime().maxMemory() / 1024 / 1024; // 和就是没有做任何参数设置时的默认值 System.out.println("-Xms : " + initialMemory + "M"); System.out.println("-Xmx : " + maxMemory + "M"); System.out.println("系统内存大小为：" + initialMemory * 64.0 / 1024 + "G"); System.out.println("系统内存大小为：" + maxMemory * 4.0 / 1024 + "G"); try { Thread.sleep(1000000); } catch (InterruptedException e) { e.printStackTrace(); } } }
在我们不设置VM参数时的默认运行结果：
-Xms : 243M
-Xmx : 3605M
系统内存大小为：15.1875G
系统内存大小为：14.08203125G
可以看到我的电脑内存出现两个值，其实我电脑是16G内存的，为什么结果和这个值不一样呢？那是因为电脑在运行时，内存还会加载一些其它东西，其实你可用的内存是不够16G的。
下面是设置参数：-Xms600m -Xmx600m
-Xms : 575M
-Xmx : 575M
系统内存大小为：35.9375G
系统内存大小为：2.24609375G
此时后面两个值已经毫无意义。我们看前两个是我们设置的初始内存和最大内存，是575M。这里并不是我们设置的600M，其实很疑惑，为什么不是呢？这个575M是怎么算出来的呢？
有两种方式：上面代码的注释汇总已经写出来了：
方式一：win+r；jps查看进程得到2080；jstat -gc 2080查得该进程锁占的内存空间情况。
方式二：设置VM参数，此时运行程序就需要把休眠去掉。-Xms600m -Xmx600m -XX:+PrintGCDetails
运行结果如下：
-Xmx : 575M
系统内存大小为：35.9375G
系统内存大小为：2.24609375G
Heap
PSYoungGen total 179200K, used 9216K [0x00000000f3800000, 0x0000000100000000, 0x0000000100000000)
eden space 153600K, 6% used [0x00000000f3800000,0x00000000f41001a0,0x00000000fce00000)
from space 25600K, 0% used [0x00000000fe700000,0x00000000fe700000,0x0000000100000000)
to space 25600K, 0% used [0x00000000fce00000,0x00000000fce00000,0x00000000fe700000)
ParOldGen total 409600K, used 0K [0x00000000da800000, 0x00000000f3800000, 0x00000000f3800000)
object space 409600K, 0% used [0x00000000da800000,0x00000000da800000,0x00000000f3800000)
Metaspace used 3152K, capacity 4496K, committed 4864K, reserved 1056768K
class space used 342K, capacity 388K, committed 512K, reserved 1048576K
上面新生代的179200K = 153600K + 25600K，显示的是有用的，存储对象的区域。
OOM举例
我们知道创建的对象和数组是存放在堆空间的(当然也不完全是)，如果对象和数组过多，堆空间不足，就会撑爆了，就OOM了。
package com.atguigu.java; import java.util.ArrayList; import java.util.Random; /* * -Xms600M -Xmx600M * */ public class OOMTest { public static void main(String[] args) { ArrayList<Picture> list = new ArrayList<Picture>(); while(true){ try { Thread.sleep(20); } catch (InterruptedException e) { e.printStackTrace(); } list.add(new Picture(new Random().nextInt(1024 * 1024))); } } } class Picture{ private byte[] pixels; public Picture(int length) { this.pixels = new byte[length]; } }
运行上述代码时，我们要设置堆内存空间的初始大小和最大大小(-Xms600M -Xmx600M)，不然岂不是等到猴年马月了。最后控制台信息是:
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space at com.atguigu.java.Picture.<init>(OOMTest.java:27) at com.atguigu.java.OOMTest.main(OOMTest.java:18)
预热：
对内存空间图：运行时打开jvisualvm软件(打开方式是两种，上面已经提到)。在Visual GC处可以看到：Eden的内存占有先变慢，然后Old增加，同时Eden变少，再变慢；Old增加，同时Eden变少。如此循环直到Old占满，此时抛出异常。
此外，我们还能在运行时看到出现OOM的原因：在抽样器->内存中可以看到一个byte[]数组占有率非常高。
3、年轻代与老年代
堆空间实际上是由年轻代和老年代构成(元空间实际由方法区掌握)。
- 存储在JVM中的Java对象可以被划分为两类：
- 一类是声明周期较短的瞬时对象，这类对象的创建和消亡都非常迅速 -- 及时回收即可
- 另外一类对象的生命周期却非常长，在某些极端的情况下还能够与JVM的生命周期保持一致 -- 比如一些连接操作 -- 没必要每次GC的时候，都按断他要不要回收，要不要回收
- Java堆区进一步细分的话，可以划分为年轻代（YoungGen）和老年代（oldGen）
- 其中年轻代又可以划分为Eden空间、Survivor0空间和Survivor1空间（有时也叫做from区、to区）
下面这参数开发中一般不会调：一般不会调。如果你去确实知道程序中许多对象的生命周期都不长，可以把新生代调大一些。
配置新生代与老年代在堆结构的占比
-
默认-XX:NewRatio=2，表示新生代占1，老年代占2，新生代占整个堆的1/3
-
可以修改-XX:NewRatio=4，表示新生代占1，老年代占4，新生代占整个堆的1/5
运行下面程序:注意运行时设置堆空间默认初始大小和最大空间。应为这样你好计算比例，用默认的太大了，不好算。
package com.atguigu.java1; /** * -Xms600m -Xmx600m * * -XX:NewRatio ： 设置新生代与老年代的比例。默认值是2. * -XX:SurvivorRatio ：设置新生代中Eden区与Survivor区的比例。默认值是8 * -XX:-UseAdaptiveSizePolicy ：关闭自适应的内存分配策略 （暂时用不到） - 是关闭 * -Xmn:设置新生代的空间的大小。 （一般不设置） * * @author shkstart shkstart@126.com * @create 2020 17:23 */ public class EdenSurvivorTest { public static void main(String[] args) { System.out.println("我只是来打个酱油~"); try { Thread.sleep(1000000); } catch (InterruptedException e) { e.printStackTrace(); } } }
用jvisualvm观察，发现默认情况下新生代和养老代就是1:2。其实我们还可以注意新生代中Eden：Survior1：Survior2=6:1：1。官方是8:1:1，其实用的时候不是。如果想用8:1:1，需要我们用命令显式的指定一下。-XX:SurvivorRatio=8
-
在HotSpot中，Eden空间和另外两个survivor空间缺省所占的比例是8 : 1 : 1，但实际使用时不是8:1:1，上面我们看到的是6:1:1
-
当然开发人员可以通过选项**-XX:SurvivorRatio**调整这个空间比例。比如-XX:SurvivorRatio=8
-
几乎所有的Java对象都是在Eden区被new出来的。 如果我们new了一个对象非常大，大到Eden区放不下了，那放到哪里呢？后面学，其实是直接存储到老年代
-
绝大部分的Java对象的销毁都在新生代进行了（有些大的对象在Eden区无法存储时候，将直接进入老年代），
-
IBM公司的专门研究表明，新生代中80%的对象都是“朝生夕死”的。这是试验得到的。换句话说绝大部分情况下：对象的生命周期都比较短。
-
-
可以使用选项"-Xmn"设置新生代最大内存大小，但这个参数一般使用 默认值就可以了。这个参数一般不用。不过有趣的是：如果你设置-Xms600m -Xmx600m；并设置-XX:NewRatio=2；并设置-Xmn=100m。那最后新生代到底是100M还是200M呢？到底听第二个命令按比例分200M呢？还是听第三个设置为100M。可以试验一下，似乎是听第三个。当然，一般我们只设置比例，不会再设置这个命令。
4、图解对象分配过程
为新对象分配内存是一件非常严谨和复杂的任务，JVM的设计者们不仅需要考虑内存如何分配、在哪里分配等问题，并且由于内存分配算法与内存回收算法密切相关，所以还需要考虑GC执行完内存回收后是否会在内存空间中产生内存碎片。
具体过程
- new的对象先放伊甸园区。此区有大小限制。
- 当伊甸园的空间填满时，程序又需要创建对象，JVM的垃圾回收器将对伊甸园区进行垃圾回收（MinorGC，下图中老师也叫YGC，代表YoungGC），将伊甸园区中的不再被其他对象所引用的对象进行销毁。再加载新的对象放到伊甸园区。 -- 这里会判断这5个对象谁是垃圾，谁不是垃圾。其中红色是垃圾。
- 然后将伊甸园中的剩余对象移动到幸存者0区(此时Enen区没有数据了)。 -- 其实呢？每个对象在创建时都有一个年龄计数器，当这个对象没有被销毁，并存入Survivor0时，这个年龄计数器+1 = 1
- 此时，再往Eden区放对象，满了后再次触发垃圾回收，此时上次幸存下来的放到幸存者0区的，如果没有回收，就会放到幸存者1区。
- 如果再次经历垃圾回收，此时会重新放回幸存者0区，接着再去幸存者1区。
- 啥时候能去养老区呢？可以设置次数。默认是15次。可以设置新生区进入养老区的年龄限制，设置 JVM 参数：-XX:MaxTenuringThreshold=N 进行设置
- 在养老区，相对悠闲。当养老区内存不足时，再次触发GC：Major GC，进行养老区的内存清理
- 若养老区执行了Major GC之后，发现依然无法进行对象的保存，就会产生OOM异常。
这里问一个很重要的问题？Survivor区会出发垃圾回收吗？答案是不会！那Survivor会有垃圾回收吗？答案是会。那什么时候回收呢？Survivor是被动回收，当Eden区满的时候，Eden会触发垃圾回收，此时Survivor也会被动的回收(不是主动触发的)。
再问一个问题？那一个对象出生肯定是在Eden，那后面是必须经过Survivor，然后再到老年代吗？不是，有的一出生，就奔向老年代了。
总结
- 针对幸存者s0，s1区的总结：复制之后由交换，谁空谁是to。
- 关于垃圾回收：频繁在新生区手机，很少在养老区手机，几乎不再永久区/元空间收集。
- 研究表明，80%的对象在Eden就被回收了，很少一部分进入Survivor区。 -- 朝生即死
对象分配的特殊情况
上面讲述的是对象分配的一般情况，那是否有特殊情况呢？我们再像是说一下：
新产生了一个对象，上面说一定是放在Eden区。但是呢？如果这个对象非常大(Eden=10M > 对象=12M)，此时几乎触发YGC，会回收Eden和Survivor区，请注意：回收之后，Eden一定是空的，Survivor-from不一定是空的，to一定是空的。然后再往Eden放，如果还放不下，就将该对象直接放到老年代。如果放下还好，直接分配对象内存，如果放不下，就会触发FGC(其实叫MajorGC)。然后回收老年代，如果还是放不下，就OOM了。
我们要注意：对于上面当Eden区YGC时，Survivor也会被动YGC，并且有部分Eden区的对象(存活下来了)，就会往Survivor区搬，如果此时Survivor放得下，则放。如果放不下，这里面的对象也直接晋升到老年代(超过阈值也会晋升到老年代)，因此老年代的东西，未必是达到阈值的，可能是连Survivor都没经过的，也可能是经过了Survivor，但是满了，直接晋升的。
常用调优工具
- JDK命令行 -- jinfo jstate javap
- Eclipse：Memory Analyzer Tool
- Jconsole
- Visual VM（实时监控，推荐）
- Jprofiler（IDEA插件）
- Java Flight Recorder（实时监控）
- GCViewer
- GCEasy
5、Minor GC、Major GC、Full GC
-
我们都知道，JVM的调优的一个环节，也就是垃圾收集，我们需要尽量的避免垃圾回收，因为在垃圾回收的过程中，容易出现STW（Stop the World）的问题，而 Major GC 和 Full GC出现STW的时间，是Minor GC的10倍以上。(其实性能调优呢？就是希望垃圾回收出现的频率少一些。程序是用户线程，当要垃圾回收时，就会出现GC线程，此时用户线程停止，即STW。而Major GC和Full GC的STW时间是Minor GC的10倍以上，因此，调优时希望Major GC和Full GC出现的少一些)
-
JVM在进行GC时，并非每次都对上面三个内存(新生代、老年代；方法区，8及之后叫元空间)区域一起回收的，大部分时候回收的都是指新生代。针对Hotspot VM的实现，它里面的GC按照回收区域又分为两大种类型：一种是部分收集（Partial GC），一种是整堆收集（FullGC）
-
部分收集：不是完整收集整个Java堆的垃圾收集。其中又分为：
- 新生代收集（Minor GC/Young GC）：只是新生代（Eden，s0，s1）的垃圾收集
- 老年代收集（Major GC/Old GC）：只是老年代的圾收集。
- 目前，只有CMS GC(这是一个垃圾收集器)会有单独收集老年代的行为。 换句话说其它的垃圾收集器在手机老年代的时候不会单独手机老年代
- 注意，很多时候Major GC会和Full GC混淆使用，需要具体分辨是老年代回收还是整堆回收。严格上说Major GC就是单收集老年代，Full GC是整堆回收，但是呢？JVM发展这么多年，很多东西不是那么清晰了，外界解释也模糊了。
- 混合收集（Mixed GC）：收集整个新生代以及部分老年代的垃圾收集。目前，只有G1 GC会有这种行为。主要是因为G1是按照一个个Region(小区)来划分的，一个Region里面可能有新生代，也可能有老年代
-
整堆收集（Full GC）：收集整个java堆和方法区的垃圾收集。
最简单的分代式GC策略的出发条件
- 年轻代GC(Minor GC)出发机制：
- 当年轻代空间不足时，就会出发Minor GC，这里的年轻代满指的是Eden代满，Survivor满不会引发GC。(每次Minor GC会清理年轻代的内存。其实Survivor满了后，不会再盲目的有对象，因为对象从Eden到来，总是伴随着一次Minor GC)。
- 因为Java对象大多具备朝生夕灭的特性，所以Minor GC非常频繁，一般回收速度也比较快。这一定义既清晰又易于理解。
- Minor GC会引发STW，暂停其它用户的线程，等垃圾回收结束，用户线程才回复运行。
- 老年代GC(Major GC/Full GC)触发机制：
- 指发生在老年代的GC，对象从老年代消失时，我们说"Major GC"或"Full GC"发生了。
- 出现了Major GC，京城会伴随至少一次的Minor GC(但非绝对的，在Parallel Scavenge收集器的收集策略里就有直接进行Major GC的策略选择过程)。
- 也就是在老年代空间不足时，会先尝试触发Minor GC。如果之后空间还不足，则触发Major GC。 这就有点懵逼了，你老年代空间不足，我Minor GC也管不住你啊。？？
- Major GC的速度一般会比Minor慢10倍以上，STW的时间更长。
- 如果Major GC后，内存还不足，就报OOM了。
- Major GC的速度一般会比Minor GC慢10倍以上。
- Full GC触发机制：(后面细讲)
- 触发Full GC执行的情况有如下五种：
- 低啊用System.gc()时，系统建议执行Full GC，但是不必然执行
- 老年代空间不足
- 方法区空间不足
- 通过Minor GC后进入老年代的平均大小大于老年代的可用内存
- 由Eden区、Survivor space0(From Space)区向Survivor space1(To Space)区复制时，对象大小大于To Space可用内存，则把该对象转存到老年代，且老年代的可用内存小于该对象大小
- 说明：full gc是开发或调优中尽量要避免的。这样暂时时间会短一些。
举例子：GC日志分析
/** * 测试MinorGC 、 MajorGC、FullGC * -Xms9m -Xmx9m -XX:+PrintGCDetails * @author shkstart shkstart@126.com * @create 2020 14:19 */ 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); } } }
[GC (Allocation Failure) [PSYoungGen: 2028K->508K(2560K)] 2028K->807K(9728K), 0.0043623 secs] [Times: user=0.05 sys=0.00, real=0.03 secs]
[GC (Allocation Failure) [PSYoungGen: 2218K->510K(2560K)] 2517K->1690K(9728K), 0.0051520 secs] [Times: user=0.02 sys=0.00, real=0.01 secs]
[GC (Allocation Failure) [PSYoungGen: 1979K->504K(2560K)] 3160K->2444K(9728K), 0.0012129 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[Full GC (Ergonomics) [PSYoungGen: 1261K->0K(2560K)] [ParOldGen: 6164K->4822K(7168K)] 7426K->4822K(9728K), [Metaspace: 3195K->3195K(1056768K)], 0.0100150 secs] [Times: user=0.06 sys=0.00, real=0.01 secs]
[GC (Allocation Failure) [PSYoungGen: 0K->0K(2560K)] 4822K->4822K(9728K), 0.0006694 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[Full GC (Allocation Failure) [PSYoungGen: 0K->0K(2560K)] [ParOldGen: 4822K->4804K(7168K)] 4822K->4804K(9728K), [Metaspace: 3195K->3195K(1056768K)], 0.0113634 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
遍历次数为：16
Heap
PSYoungGen total 2560K, used 139K [0x00000000ffd00000, 0x0000000100000000, 0x0000000100000000)
eden space 2048K, 6% used [0x00000000ffd00000,0x00000000ffd22e90,0x00000000fff00000)
from space 512K, 0% used [0x00000000fff80000,0x00000000fff80000,0x0000000100000000)
to space 512K, 0% used [0x00000000fff00000,0x00000000fff00000,0x00000000fff80000)
ParOldGen total 7168K, used 4804K [0x00000000ff600000, 0x00000000ffd00000, 0x00000000ffd00000)
object space 7168K, 67% used [0x00000000ff600000,0x00000000ffab12e0,0x00000000ffd00000)
Metaspace used 3242K, capacity 4496K, committed 4864K, reserved 1056768K
class space used 351K, capacity 388K, committed 512K, reserved 1048576K
java.lang.OutOfMemoryError: Java heap space
表示暂时看不懂哈。但是我们暂时可以看到：在OOM前(OOM是因为老年代满了，GC之后依然无法放下)。执行了Full GC，并且Failure。
-
[PSYoungGen: 2028K->508K(2560K)]：年轻代总空间为 2560K(Eden+from) ，当前占用2028K ，经过垃圾回收后剩余5048K
-
2028K->807K(9728K)：堆内存总空间为 9728K ，当前占用2028K ，经过垃圾回收后剩余807K
这些具体的后面我们再学，其实还有喝多疑惑。
6、堆空间分代思想
为什么需要把Java堆分代？不分代就不能正常工作了吗？
- 经研究，不同对象的生命周期不同。70%-99%的对象是临时对象
- 新生代：有Eden、两块大小相同的survivor（又称为from/to或s0/s1）构成，to总为空。
- 老年代：存放新生代中经历多次GC仍然存活的对象。
- 其实不分代完全可以，分代的唯一理由就是优化GC性能。如果没有分代，那所有的对象都在一块，就如同把一个学校的人都关在一个教室。GC的时候要找到哪些对象没用，这样就会对堆的所有区域进行扫描。（性能低）而很多对象都是朝生夕死的，如果分代的话，把新创建的对象放到某一地方，当GC的时候先把这块存储“朝生夕死”对象的区域进行回收，这样就会腾出很大的空间出来。（多回收新生代，少回收老年代，性能会提高很多）
其实这个很好理解：分代不是必须的，但是分代呢？可以优化GC性能。如果大家都在一起，每次判断谁是垃圾的时候，都要遍历一遍，工作量非常大。因为我们知道有一些对象呢？其实不太需要被回收，或者说很可能不是垃圾。因此如果分开，就减少了遍历的耗时。同时也方便了GC。
7、内存分配策略
如果对象在Eden出生并经过第一次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并将对象年龄设为1。对象在Survivor区中每熬过一次MinorGC，年龄就增加1岁，当它的年龄增加到一定程度（默认为15岁，其实每个JVM、每个GC都有所不同）时，就会被晋升到老年代中。
对象晋升老年代的年龄阀值，可以通过选项**-XX:MaxTenuringThreshold**来设置
内存范培策略(或对象提升(Promotion)规则)
针对不同年龄段的对象分配原则如下所示：
- 优先分配到Eden：
- 大对象直接分配到老年代：尽量避免程序中出现过多的大对象。开发中比较长的字符串或者数组，会直接存在老年代，但是因为新创建的对象都是朝生夕死的，所以这个大对象可能也很快被回收，但是因为老年代触发Major GC的次数比 Minor GC要更少，因此可能回收起来就会比较慢
- 长期存活的对象分配到老年代
- 动态对象年龄判断：如果Survivor区中相同年龄的所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。
- 空间分配担保： -XX:HandlePromotionFailure 。
下面演示一下：大对象直接放进老年代
/* * 测试：大对象直接进入老年代 * -Xms60m -Xmx60m -XX:NewRatio=2 -XX:SurvivorRatio=8 -XX:+PrintGCDetails * 最终 E S S O * 16 2 2 40 * */ public class YoungOldAreaTest { public static void main(String[] args) { byte[] buffer = new byte[1024 *1024 * 20]; //20m } }
控制台
Heap
PSYoungGen total 18432K, used 2294K [0x00000000fec00000, 0x0000000100000000, 0x0000000100000000)
eden space 16384K, 14% used [0x00000000fec00000,0x00000000fee3db58,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 3215K, capacity 4496K, committed 4864K, reserved 1056768K
class space used 348K, capacity 388K, committed 512K, reserved 1048576K
老年代用了20M，说明大对象直接进入老年代。
8、为对象分配内存：TLAB
为什么又TLAB(Thread Local Allocation Buffer)?
- 堆区是线程共享区域，任何线程都可以访问到堆区中的共享数据 --- 好处是非常方便的实现线程之间的通信
- 由于对象实例的创建在JVM中非常频繁，因此在并发环境下从堆区中划分内存空间是线程不安全的 -- 多个线程操作共享数据，就可能线程不安全
- 为避免多个线程操作同一地址，需要使用加锁等机制，进而影响分配速度。
什么是TLAB？
- 从内存模型而不是垃圾收集的角度，对Eden区域继续进行划分，JVM为每个线程分配了一个私有缓存区域，它包含在Eden空间内。
- 多线程同时分配内存时，使用TLAB可以避免一系列的非线程安全问题(多线程创建对象分配内存，每个线程独一份)，同时还能够提升内存分配的吞吐量(因为不存在线程安全问题，不用加锁)，因此我们可以将这种内存分配方式称之为快速分配策略。
- 据我所知所有OpenJDK衍生出来的JVM都提供了TLAB的设计。
TLAB的再说明
-
尽管不是所有的对象实例都能够在TLAB中成功分配内存(因为空间相对较小，仅占1%)，但JVM确实是将TLAB作为内存分配的首选。
-
在程序中，开发人员可以通过选项“-XX:UseTLAB”设置是否开启TLAB空间。
-
默认情况下，TLAB空间的内存非常小，仅占有整个Eden空间的1%，当然我们可以通过选项“**-XX:TLABWasteTargetPercent**”设置TLAB空间所占用Eden空间的百分比大小。
-
一旦对象在TLAB空间分配内存失败时，JVM就会尝试着通过使用加锁机制确保数据操作的原子性，从而直接在Eden空间中分配内存。
检查TLAB开启情况。
/* * 测试-XX:UseTABLE参数是否开启的情况：默认情况是开启的 * JVM没有设置任何参数 * */ public class TLABArgsTest { public static void main(String[] args) { System.out.println("我只是来打酱油的！！！"); try { Thread.sleep(1000000000L); } catch (InterruptedException e) { e.printStackTrace(); } } }
结果：默认是开启的，则JVM将TLAB作为内存分配的首选
对象分配过程：TLAB
这是学了TLAB知识之后的对象分配过程
现在再问你：堆空间的区域都是线程共享的吗？不是，TLAB是线程私有的，每个线程独一份。
9、小结堆空间的参数设置
我们只说常用的
/**
* 测试堆空间常用的jvm参数：
* -XX:+PrintFlagsInitial : 查看所有的参数的默认初始值
* -XX:+PrintFlagsFinal ：查看所有的参数的最终值（可能会存在修改，不再是初始值）
* 具体查看某个参数的指令： jps：查看当前运行中的进程 这个就是在控制台了
* jinfo -flag SurvivorRatio 进程id
*
* -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:HandlePromotionFailure：是否设置空间分配担保
*/
空间分配担保
1、在发生Minor GC之前，虚拟机会检查老年代最大可用的连续空间是否大于新生代所有对象的总空间。
- 如果大于，则此次Minor GC是安全的
- 如果小于(则不安全)，则虚拟机会查看**-XX:HandlePromotionFailure**设置值是否允担保失败。
- 如果HandlePromotionFailure=true，那么会继续检查老年代最大可用连续空间是否大于历次晋升到老年代的对象的平均大小。
- 如果大于，则尝试进行一次Minor GC，但这次Minor GC依然是有风险的；
- 如果小于，则进行一次Full GC。
- 如果HandlePromotionFailure=false，则进行一次Full GC。
- 如果HandlePromotionFailure=true，那么会继续检查老年代最大可用连续空间是否大于历次晋升到老年代的对象的平均大小。
历史版本
- 在JDK6 Update 24(JDK7)之后，HandlePromotionFailure(默认是true，不变了)参数不会再影响到虚拟机的空间分配担保策略，观察openJDK中的源码变化，虽然源码中还定义了HandlePromotionFailure参数，但是在代码中已经不会再使用它。
- JDK6 Update 24之后的规则变为只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小就会进行Minor GC，否则将进行Full GC。即 HandlePromotionFailure=true
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编译器能够分析出一个新的对象的引用的使用范围从而决定是否要将这个对象分配到堆上。
- 逃逸分析的基本行为就是分析对象动态作用域：
- 当一个对象在方法中被定义后，对象只在方法内部使用，则认为没有发生逃逸。 --- 此时使用栈上分配
- 当一个对象在方法中被定义后，它被外部方法所引用，则认为发生逃逸。例如作为调用参数传递到其他地方中。
逃逸分析举例：
1、没有发生逃逸的对象，则可以分配到栈（无线程安全问题）上，随着方法执行的结束，栈空间就被移除（也就无需GC）
public void my_method() { V v = new V(); // use v // .... v = null; }
2、下面代码中的 StringBuffer sb 发生了逃逸，不能在栈上分配
public static StringBuffer createStringBuffer(String s1, String s2) { StringBuffer sb = new StringBuffer(); sb.append(s1); sb.append(s2); return sb; }
3、如果想要StringBuffer sb不发生逃逸，可以这样写
public static String createStringBuffer(String s1, String s2) { StringBuffer sb = new StringBuffer(); sb.append(s1); sb.append(s2); return sb.toString(); }
实际当中到底有几种情况呢？
package com.atguigu.java2; /** * 逃逸分析 * * 如何快速的判断是否发生了逃逸分析，大家就看new的对象实体是否有可能在方法外被调用。 */ public class EscapeAnalysis { public EscapeAnalysis obj; /* 方法返回EscapeAnalysis对象，发生逃逸 */ public EscapeAnalysis getInstance(){ return obj == null? new EscapeAnalysis() : obj; // 不管obj是否为空，都有一个new的EscapeAnalysis对象可能被方法外调用 } /* 为成员属性赋值，发生逃逸 你给这个属性赋值，赋值后肯定是有可能在该方法外被调用 */ //思考：如果当前的obj引用声明为static的？仍然会发生逃逸。 public void setObj(){ this.obj = new EscapeAnalysis(); } /* 对象的作用域仅在当前方法中有效，没有发生逃逸， 内部创建，内部使用，没有返回 */ public void useEscapeAnalysis(){ EscapeAnalysis e = new EscapeAnalysis(); } /* 引用成员变量的值，发生逃逸 */ // 这个很多人很有可能会判断错，这道题很重要 /* * 外面判断是否有逃逸，看的是new，即创建的对象，和这里的局部变量e完全无关，这个e是分配在栈空间做引用的。 * 外面看到EscapeAnalysis e = getInstance();重点是观察getInstance()方法，其获得了一个非空对象 * 这个对象是return obj == null? new EscapeAnalysis() : obj;这里得来的 * 要么这个对象是obj引用的，那么可能被方法外的引用，因此逃逸。如果是创建的即new EscapeAnalysis()，这个也可能会逃逸(这个我是有疑问的) * */ public void useEscapeAnalysis1(){ EscapeAnalysis e = getInstance(); //getInstance().xxx()同样会发生逃逸 } }
逃逸分析参数设置：
-
在JDK 1.7 版本之后，HotSpot中默认就已经开启了逃逸分析
-
如果使用的是较早的版本，开发人员则可以通过：
- 选项“-XX:+DoEscapeAnalysis"显式开启逃逸分析
- 通过选项“-XX:+PrintEscapeAnalysis"查看逃逸分析的筛选结果
总结：
开发中能使用局部变量的，就不要使用在方法外定义。
逃逸分析：代码优化
使用逃逸分析，编译器可以对代码做如下优化：
- 栈上分配：将堆分配转化为栈分配。如果一个对象在子程序中被分配，要使指向该对象的指针永远不会发生逃逸，对象可能是栈上分配的候选，而不是堆上分配
- 同步省略：如果一个对象被发现只有一个线程被访问到，那么对于这个对象的操作可以不考虑同步。
- 分离对象或标量替换：有的对象可能不需要作为一个连续的内存结构存在也可以被访问到，那么对象的部分（或全部）可以不存储在内存，而是存储在CPU寄存器中。后面这个红色的话针对的就不仅是java语言了。翻译成Java语言是：那么对象的部分（或全部）可以不存才在堆空间中，而是存储在栈空间中。因为java虚拟机是基于栈的，而不是寄存器的。
栈上分配
- JIT编译器在编译期间根据逃逸分析的结果，发现如果一个对象并没有逃逸出方法的话，就可能被优化成栈上分配。分配完成后，继续在调用栈内执行，最后线程结束，栈空间被回收，局部变量对象也被回收。这样就无须进行垃圾回收了。
- 常见的栈上分配的场景：在逃逸分析中，已经说明了，分别是给成员变量赋值、方法返回值、实例引用传递(发生逃逸)。
栈上分配举例
这里的代码VM指令关闭了逃逸分析
package com.atguigu.java2; /** * 栈上分配测试 * -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 { } }
jvisualvm观察：看到1千万的User对象分配在内存空间上。没有分配到栈上。
现在我们将上面逃逸分析的"-"号改成"+"号，再次运行，当然删除也行，因为默认开启。
此时发现jvisualvm中User对象就不足1千万了。你可能会想，那为什么不是0呢？我也不知道。而且创建对象运行时间为8ms。上面是81ms。快了很多。
现在我们将VM参数-Xmx256m -Xms256m -XX:-DoEscapeAnalysis -XX:+PrintGCDetails
发现执行时间是57ms(发生GC)。如果改为 -XX:+DoEscapeAnalysis，是5ms(且没有发生GC)。
同步省略(同步消除)
-
程同步的代价是相当高的，同步的后果是降低并发性和性能(这个很好理解，因为同步的话相当于是串行的操作了)。
-
在动态编译同步块的时候，JIT编译器可以借助逃逸分析来判断同步块所使用的锁对象是否只能够被一个线程访问而没有被发布到其他线程。如果没有，那么JIT编译器在编译这个同步块的时候就会取消对这部分代码的同步。这样就能大大提高并发性和性能。这个取消同步的过程就叫同步省略，也叫锁消除。
同步消除举例
public void f() { Object hollis = new Object(); synchronized(hollis) { System.out.println(hollis); } }
代码中对hollis这个对象加锁，但是hollis对象的生命周期只在f()方法中，并不会被其他线程所访问到(因为近来的线程都是新的对象？？)，所以在JIT编译阶段就会自动被优化掉，优化成：
public void f() { Object hellis = new Object(); System.out.println(hellis); }
字节码分析
public class SynchronizedTest { public void f() { Object hollis = new Object(); synchronized(hollis) { System.out.println(hollis); } } }
字节码
0 new #2 <java/lang/Object> 3 dup 4 invokespecial #1 <java/lang/Object.<init>> 7 astore_1 8 aload_1 9 dup 10 astore_2 11 monitorenter 12 getstatic #3 <java/lang/System.out> 15 aload_1 16 invokevirtual #4 <java/io/PrintStream.println> 19 aload_2 20 monitorexit 21 goto 29 (+8) 24 astore_3 25 aload_2 26 monitorexit 27 aload_3 28 athrow 29 return
对于上面的代码会在JIT及时编译器处自动优化，但是字节码指令里面依然是有锁的。
分离对象或标量替换
标量（scalar）是指一个无法再分解成更小的数据的数据。Java中的原始数据类型就是标量。
相对的，那些还可以分解的数据叫做聚合量（Aggregate），Java中的对象就是聚合量，因为他可以分解成其他聚合量和标量。
在JIT阶段，如果经过逃逸分析，发现一个对象不会被外界访问的话，那么经过JIT优化，就会把这个对象拆解成若干个其中包含的若干个成员变量来代替。这个过程就是标量替换。
分离对象或标量替换代码举例
public static void main(String args[]) { alloc(); } private static void alloc() { Point point = new Point(1,2); System.out.println("point.x" + point.x + ";point.y" + point.y); } class Point { private int x; private int y; }
以上代码，经过标量替换后，就会变成
private static void alloc() { int x = 1; int y = 2; System.out.println("point.x = " + x + "; point.y=" + y); }
- 可以看到，Point这个聚合量经过逃逸分析后，发现他并没有逃逸，就被替换成两个聚合量了。这两个聚合量最终在栈帧的局部变量表中。
- 那么标量替换有什么好处呢？就是可以大大减少堆内存的占用。因为一旦不需要创建对象了，那么就不再需要分配堆内存了。
- 标量替换为栈上分配提供了很好的基础。
疑问？？其实我在想既然你没有逃逸分析，那创建对象不就是在栈上吗？哪还会占用内存空间(堆)。答案可能是：上面我们创建过1千万的对象，当开启逃逸分析，并且这1千万都没有逃逸。但是呢？最终发现堆上还是有几万的对象，并非全部到栈上了。而这个标量替换更加彻底。
再次举例
class Customer { String name; int id; Account acct; } class Account { double balance; }
对于Customer对象，如果发现没有逃逸，则会分解成String(当然String不是基本数据类型，严格上说不算标量，还可以分成char数组)、int标量；然后Account分成double的标量。
标量替换测试
/** * 标量替换测试 * -Xmx100m -Xms100m -XX:+DoEscapeAnalysis -XX:+PrintGC -XX:-EliminateAllocations * @author shkstart shkstart@126.com * @create 2020 12:01 */ 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"); } }
未开启标量替换
1、JVM 参数
-Xmx100m -Xms100m -XX:+DoEscapeAnalysis -XX:+PrintGC -XX:-EliminateAllocations 开启逃逸分析(默认就是开启的)，不开启标量替换
2、日志
[GC (Allocation Failure) 25600K->832K(98304K), 0.0009263 secs]
[GC (Allocation Failure) 26432K->736K(98304K), 0.0010619 secs]
[GC (Allocation Failure) 26336K->768K(98304K), 0.0008224 secs]
[GC (Allocation Failure) 26368K->800K(98304K), 0.0007287 secs]
[GC (Allocation Failure) 26400K->784K(98304K), 0.0009492 secs]
[GC (Allocation Failure) 26384K->768K(101376K), 0.0008945 secs]
[GC (Allocation Failure) 32512K->652K(101376K), 0.0008514 secs]
[GC (Allocation Failure) 32396K->652K(100352K), 0.0006246 secs]
花费的时间为： 71 ms
开启标量替换
1、JVM 参数
-Xmx100m -Xms100m -XX:+DoEscapeAnalysis -XX:+PrintGC -XX:+EliminateAllocations
2、日志：时间减少很多，且无GC
花费的时间为： 6 ms
其实我们看到这个开启了逃逸分析和标量替换，在内存(java中是堆)中还是有User对象的。
上述代码在主函数中调用了1亿次alloc()方法，进行对象创建由于User对象实例需要占据约16字节的空间，因此累计分配空间达到将近1.5GB。如果堆空间小于这个值，就必然会发生GC。使用如下参数运行上述代码：
-server -Xmx100m -Xms100m -XX:+DoEscapeAnalysis -XX:+PrintGC -XX:+EliminateAllocations
这里设置参数如下：
- 参数 -server：启动Server模式，因为在server模式下，才可以启用逃逸分析。我们上面运行时，没有加这个-server，这是为什么呢？
- 参数 -XX:+DoEscapeAnalysis：启用逃逸分析
- 参数 -Xmx10m：指定了堆空间最大为10MB
- 参数 -XX:+PrintGC：将打印GC日志。
- 参数 -XX:+EliminateAllocations：开启了标量替换（默认打开），允许将对象打散分配在栈上，比如对象拥有id和name两个字段，那么这两个字段将会被视为两个独立的局部变量进行分配
逃逸分析小结：逃逸分析并不成熟
- 关于逃逸分析的论文在1999年就已经发表了，但直到JDK1.6才有实现，而且这项技术到如今也并不是十分成熟的。
- 其根本原因就是无法保证逃逸分析的性能消耗一定能高于他的消耗。虽然经过逃逸分析可以做标量替换、栈上分配、和锁消除。但是逃逸分析自身也是需要进行一系列复杂的分析的，这其实也是一个相对耗时的过程。
- 一个极端的例子，就是经过逃逸分析之后，发现没有一个对象是不逃逸的。那这个逃逸分析的过程就白白浪费掉了。
- 虽然这项技术并不十分成熟，但是它也是即时编译器优化技术中一个十分重要的手段。
- 注意到有一些观点，认为通过逃逸分析，JVM会在栈上分配那些不会逃逸的对象，这在理论上是可行的，但是取决于JVM设计者的选择。据我所知，Oracle Hotspot JVM中并未这么做（刚刚演示的效果，是因为HotSpot实现了标量替换，哈哈，其实上面的试验骗了你），这一点在逃逸分析相关的文档里已经说明，所以可以明确在HotSpot虚拟机上，所有的对象实例都是创建在堆上。
- 目前很多书籍还是基于JDK7以前的版本，JDK已经发生了很大变化，intern字符串的缓存和静态变量曾经都被分配在永久代上，而永久代已经被元数据区取代。但是intern字符串缓存和静态变量并不是被转移到元数据区，而是直接在堆上分配，所以这一点同样符合前面一点的结论：对象实例都是分配在堆上。
堆是分配对象的唯一选择吗？
答：是，因为逃逸分析还不成熟。还没有使用。
本章小结
-
年轻代是对象的诞生、成长、消亡的区域，一个对象在这里产生、应用，最后被垃圾回收器收集、结束生命。
-
老年代放置长生命周期的对象，通常都是从Survivor区域筛选拷贝过来的Java对象。当然，也有特殊情况，我们知道普通的对象可能会被分配在TLAB上；如果对象较大，无法分配在 TLAB 上，则JVM会试图直接分配在Eden其他位置上；如果对象太大，完全无法在新生代找到足够长的连续空闲空间，JVM就会直接分配到老年代。
-
当GC只发生在年轻代中，回收年轻代对象的行为被称为Minor GC。当GC发生在老年代时则被称为Major GC或者Full GC。一般的，Minor GC的发生频率要比Major GC高很多，即老年代中垃圾回收发生的频率将大大低于年轻代。
