【探究JVM六】这一次，彻底把JVM堆空间的结构搞懂！对象内存分配策略，堆空间的可视化探究，新生代老年代GC的触发机制一文看懂！
文章目录
- 1. 堆Heap
- 堆的核心-内存细分
- 堆空间大小设置
- 2. 新生代和老年代
- 对象内存分配
- 特殊情况讨论
- 3. 代码调试分析说明
- 分析说明
- 4. Minor GC、Major GC、Full GC
- 新生代Minor GC触发机制
- 老年代Major GC/Full GC触发机制
- Full GC触发机制
- 5. Java堆为什么要分代
- 线程的TLAB
- 一些说明
1. 堆Heap
一个进程对应一个JVM实例，一个JVM实例就对应一个运行时数据区Rutime Data Area（Runtime类是饿汉式单例）。一个进程对应多个线程，一个进程中的多个线程共享同一块堆空间，共享同一个方法区。
在方法结束后，堆中的对象不会立刻被移除，仅仅在执行引擎垃圾回收的时候才会被移除。
堆，是GC（ Garbage Collection，垃圾收集器）执行垃圾回收的重点区域。
【oracle官方文档】The Structure of the Java Virtual Machine
堆的核心-内存细分
现代垃圾回收器大部分都是基于分代手机理论设计，堆空间细分为：
约定：
新生区==>新生代==>年轻代
养老区==>老年区==>老年代
永久区==>永久代
JDK 7及之前：
新生代 + 老年代 + 永久代
JDK 8及之后：
新生代+ 老年代 + 元空间
元空间、永久代是方法区具体的落地实现
堆空间大小设置
堆用来存储Java对象实例，堆的大小在JVM启动时就已经设定好了。堆空间的大小可以通过两个参数来设置：（-X表示虚拟机参数）
-
-Xms(memory start)：堆区起始内存 -
-Xmx(memory max)：堆区最大内存
一旦堆区的内存超过-Xmx锁指定的最大内存时，会抛出OutOfMemoryError
通常会将-Xms和-Xmx两个参数配置相同的值，其目的是为了能够在GC后，不需要重新分隔计算堆区的大小，从而提高性能。
【默认情况下】
-
初始内存大小：物理内存的 1 / 64
-
最大内存大小：物理内存的 1 / 4
2. 新生代和老年代
其中新生代分为Eden区、Suvivor 0区、Survivor 1区（有时也叫From区、To区）
元空间、永久代是方法区具体的落地实现
堆空间占比分配：
对象内存分配
一个对象被分配内存、到创建、再到到消亡，它经历了怎样的过程呢？我们通过这张图，来做具体说明：
【概念明确】：
-
Eden - 伊甸园区
-
Survivor - 幸存者区（Survivor0 - S0、Survivor1 - S1）
-
垃圾对象 - 不再使用的对象，即没有指向的对象
-
存活的对象 - 不是垃圾的对象（还被使用）
-
Tenured/Old - 老年区
Survivor0 - S0、Survivor1 - S1也称
from区和to区。名称不是固定的，from是满的一个，to是空的一个。
假设首次Survivor0和Survivor1均为空
1. 首先new参生的对象会放到Eden
2. 当Eden区空间满了时，程序又需要创建对象。YGC/Minor GC（可达性分析算法）对Eden区的垃圾对象进行回收，将存活的对象放入到Survivor0区。每个对象的年龄计数器age + 1
3. 此时Eden为空，存活的对象放入到了S0中
4. 继续在Eden区创建新对象，Eden区再次装满，触发Minor GC
5. 再次将剩余存活的对象放入到Survivor区。此时，S0已满，放入到S1中
6. 判断S0区中的对象还是否被使用，如不使用则回收，使用则放入到S1中。age计数器+1
7. 此时Eden和S0为空，存活的对象均在S1中
此时S0称为to区，s1称为from区
8. Eden区中再次创建对象直至满为止，存活的对象放入S0中，同时判断S1中是否有可回收答垃圾对象
9. 当Survivor区中有对象的对象计数器age达到阈值15时，将其从Survivor中晋升到Old区
阈值设置参数：-XX:MaxTenuringThresho1d=进行设置
【总结】：
-
针对幸存者S0，S1区的总结：复制之后有交换，谁空谁是to
-
关于垃圾回收：频繁在新生区收集，很少在养老区收集，几乎不在永久区/元空间收集。
-
80%左右的对象在新生代中就被销毁了，朝生夕死
特殊情况讨论
Q1：Survivor区满了会触发YGC/Minor GC吗？
- 不会的。Survivor区满了不会触发YGC，但是它会被垃圾回收。当每次堆Eden进行YGC时，会对Suevivor也进行判断回收。只不过区别于Eden，这个过程是被动的。
Q2：当Survivor满了时怎么办？
- 如果Eden回收完后，此时Survivor为满时，就将Eden中的存活对象直接放入到Old区中。即使
age没有达到阈值，也有可能直接晋升到老年代（理解为跨级晋升）
Q3：对象有可能一创建就放到老年代吗？
- 有可能。在YGC之后，对于超大对象来说还是存放不下，直接放入到老年代
超大对象一般是超长的字符串、超大的数组等
Q4：超大对象老年代也放不下怎么办？
针对不动态调整内存空间机制的虚拟机
-
先对老年代进行Major GC，看是否能够存放，是则放入老年代
-
Major GC完之后还是放不下，抛出OOM
3. 代码调试分析说明
光靠概念是不行的，我们通过一段代码来详解一下上面的要点：
JVM分析工具是用的JDK自带的jvisualvm.exe和第三方的****
使用jvisualvm.exe工具查看java项目内存溢出
Java Profiler - JProfiler
【测试代码】
public class HeapInstanceTest2 {
byte[] data = new byte[new Random().nextInt(1024 * 200)];
public static void main(String[] args) {
ArrayList<HeapInstanceTest2> list = new ArrayList<HeapInstanceTest2> ();
while (true) {
list.add(new HeapInstanceTest2());
try {
Thread.sleep(20);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}
在当前类中声明byte类型的字节数组，大小是随机的，然后不断创建并放入到ArrayList中
由于是随机大小，有一些创建的对象可能比Survivr区的空间还大，如下图动图所示，就直接放入到了Old区，这也是符合我们上面的描述的
当Old也放满时，最终会产生OOM
分析说明
JProfiler查看内存图分区详情：
Eden：
Old：
-
我们可以看到，Eden区会有一个峰值，当它满了之后就会进行YGC，此时Eden再次到达峰底
-
S0和S1交替执行
一般程序出现OOM的原因就是老年代空间不足造成的
4. Minor GC、Major GC、Full GC
JVM在进行GC时，并非每次都对上面三个内存区域（新生代、老年代、方法区）一起回收的，大部分都指的是新生代。因为大多数情况下创建对象都是在新生代，对象是朝生夕死的，所以GC的频率会比较高。
针对HotSpot VM，GC按照回收区域会划分成两大类型：
-
部分收集Partial GC
-
全部收集Full GC
【部分收集】： 不是完整收集整个Java堆的垃圾，又分为
-
新生代收集（Minor GC或Yang GC，称谓不同）：只对新生代收集
-
老年代收集（Major GC / Old GC）：只对老年代收集
-
混合收集（Mixed GC）：收集整个新生代和部分老年代（G1 GC）
【全部收集】： 收集整个Java堆和方法区的垃圾收集
新生代Minor GC触发机制
-
当年轻代空间不足时，就会触发 Minor GC，这里的年轻代满指的是Eden代满， Survivor满不会引发GC。每次 Minor GC会清理年轻代的内存
-
因为Java对象大多都具备朝生夕灭的特性，所以 Minor GC非常频繁，一般回收速度也比较快
-
Minor GC会引发STW，暂停其它用户的线程，等垃圾回收结束，用户线程才恢复运行
Java中Stop-The-World机制简称STW，是在执行垃圾收集算法时，Java应用程序的其他所有线程都被挂起（除了垃圾收集帮助器之外）。Java中一种全局暂停现象，全局停顿，所有Java代码停止，native代码可以执行，但不能与JVM交互；这些现象多半是由于GC引起。
Minor GC时，制造垃圾的用户线程会暂停，等待VM Threads标记完垃圾对象并回收完，用户线程才能执行，即为STW
老年代Major GC/Full GC触发机制
指发生在老年代的GC，对象从老年代消失时，我们说Major GC或Full GC发生了
出现了 Major GC，经常会伴随至少一次的 Minor GC
但并非绝对的，在Parallel Scavenge收集器的收集策略里就有直接进行 Major GC的策略选择过程
在老年代空间不足时，会先尝试触发Minor GC。如果之后空间还不足，则触发Major GC
-
由于老年代空间较大，Major GC的速度一般会比 Minor GC慢10倍以上，STW的时间更长
-
如果 MaJor GC后，内存还不足，就报OOM
Full GC触发机制
触发Full GC执行的情况有如下五种：
-
调用
System.gc()时，系统建议执行Fu1GC，但是不必然执行 -
老年代空间不足
-
方法区空间不足
-
通过Minor GC后进入老年代的平均大小大于老年代的可用内存
-
对于超大对象，新生代放不下，则把该对象转存到老年代，且老年代的可用内存小于该对象大小，就会触发Full GC
Full GC是开发或调优中尽量要避免的，这样暂时时间会短一些
5. Java堆为什么要分代
绝大部分对象都是朝生夕死的。 新生代存放不停更新迭代的对象，老年代存放多次GC后任然存活的对象。
Java堆为什么要分代？不分代就不能工作了吗？
分代的原因是方便管理和维护，提高效率。就像一个年级可以放到一个班也能上课，但是人数太多不好管理，所以要分班。
分代的唯一理由就是优化GC性能。 如果没有分代，在GC的时候要找到哪些对象没用这样就会对堆的所有区域进行扫描。而很多对象都是朝生夕死的，如果分代的话，把新创建的对象放到某一地方，当GC的时候先把这块存储“朝生夕死”对象的区域进行回收，这样就会腾出很大的空间出来。
-
GC痛苦的事情是出现了很多大对象
-
更痛苦的事是很多的大对象是朝生夕死的
线程的TLAB
TLAB（Thread Local Allocation Buffer），从内存模型而不是垃圾收集的角度，对Eden区域继续进行划分，JVM为每个线程分配了一个私有缓存区域，它包含在Eden空间内
多线程同时分配内存时，使用TLAB可以避免一系列的非线程安全问题，同时还能够提升内存分配的吞吐量，因此我们可以将这种内存分配方式称之为快速分配策略
不是所有的对象实例都能够在TLAB中成功分配内存，一旦对象在TLAB空间分配内存失败时，JVM就会尝试通过使用加锁机制来确保数据的原子性，从而在Eden空间中分配内存
一些说明
堆是分配对象存储的唯一选择吗？
在《深入理解Java虚拟机》中关于Java堆内存有这样一段描述：
随着JIT编译期的发展与逃逸分析技术逐渐成熟，栈上分配、标量替换优化技术将会导
致一些微妙的变化，所有的对象都分配到堆上也渐渐变得不那么“绝对”了。
在Java虚拟机中，对象是在Java堆中分配内存的，这是一个普遍的常识。但是，有一
种特殊情况，那就是如果经过逃逸分析（Escape Analysis)后发现，一个对象并没有
逃逸出方法的话，那么就可能被优化成栈上分配。这样就无需在堆上分配内存，也无须
进行垃圾回收了。这也是最常见的堆外存储技术。
逃逸分析的基本行为就是分析对象动态作用域：
-
当一个对象在方法中被定义后，对象只在方法内部使用，则认为没有
发生逃逸 -
当一个对象在方法中被定义后，它被外部方法所引用，则认为发生逃
逸。例如作为调用参数传递到其他地方中
public void method() {
A a = new A();
//use a
a = null;
}
没有发生逃逸的对象，则可以分配到栈上，随着方法执行的结束，栈空间被移除
使用逃逸分析，编译器可对如下代码进行优化：
-
栈上分配
-
同步省略
-
分离对象或者标量替换
在堆上分配内存，也无须
进行垃圾回收了。这也是最常见的堆外存储技术。
逃逸分析的基本行为就是分析对象动态作用域：
-
当一个对象在方法中被定义后，对象只在方法内部使用，则认为没有
发生逃逸 -
当一个对象在方法中被定义后，它被外部方法所引用，则认为发生逃
逸。例如作为调用参数传递到其他地方中
public void method() {
A a = new A();
//use a
a = null;
}
没有发生逃逸的对象，则可以分配到栈上，随着方法执行的结束，栈空间被移除
使用逃逸分析，编译器可对如下代码进行优化：
-
栈上分配
-
同步省略
-
分离对象或者标量替换