1. 堆Heap

一个进程对应一个JVM实例，一个JVM实例就对应一个运行时数据区Rutime Data Area（Runtime类是饿汉式单例）。一个进程对应多个线程，一个进程中的多个线程共享同一块堆空间，共享同一个方法区。

在方法结束后，堆中的对象不会立刻被移除，仅仅在执行引擎垃圾回收的时候才会被移除。

堆，是GC（ Garbage Collection，垃圾收集器）执行垃圾回收的重点区域。

👉【oracle官方文档】The Structure of the Java Virtual Machine (opens new window)

堆的核心-内存细分

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

约定：

• 新生区==>新生代==>年轻代

• 养老区==>老年区==>老年代

• 永久区==>永久代

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项目内存溢出 (opens new window)

Java Profiler - JProfiler (opens new window)

【测试代码】

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触发机制

Major GC 、 Full GC很多情况下是混合使用的，需要具体分辨老年代还是整堆收集。

只有CMS才会有老年代单独收集的行为。 其余都可以理解为Full GC，都是对整堆收集，Major GC/Full GC可以理解为相同作用

指发生在老年代的GC，对象从老年代消失时，我们说Major GC或Full GC发生了

出现了 Major GC，经常会伴随至少一次的 Minor GC/YGC

但并非绝对的，在Parallel Scavenge收集器的收集策略里就有直接进行 Major GC的策略选择过程

在老年代空间不足时，会先尝试触发Minor GC。如果之后空间还不足，则触发Major GC

• 由于老年代空间较大，Major GC的速度一般会比 Minor GC慢10倍以上，STW的时间更长

• 如果 MaJor GC后，内存还不足，就报OOM

Full GC触发机制

触发Full GC执行的情况有如下五种：

1. 调用 System.gc()时，系统建议执行Full GC，但是不必然执行

2. 老年代空间不足

3. 方法区空间不足

4. 通过Minor GC后进入老年代的平均大小大于老年代的可用内存

5. 对于超大对象，新生代放不下，则把该对象转存到老年代，且老年代的可用内存小于该对象大小，就会触发Full GC

Full GC是开发或调优中尽量要避免的，这样暂时时间会短一些

5. Java堆为什么要分代

绝大部分对象都是朝生夕死的。 新生代存放不停更新迭代的对象，老年代存放多次GC后任然存活的对象。

Java堆为什么要分代？不分代就不能工作了吗？

分代的原因是方便管理和维护，提高效率。就像一个年级可以放到一个班也能上课，但是人数太多不好管理，所以要分班。

分代的唯一理由就是优化GC性能。 如果没有分代，在GC的时候要找到哪些对象没用这样就会对堆的所有区域进行扫描。而很多对象都是朝生夕死的，如果分代的话，把新创建的对象放到某一地方，当GC的时候先把这块存储“朝生夕死”对象的区域进行回收，这样就会腾出很大的空间出来。

• GC痛苦的事情是出现了很多大对象

• 更痛苦的事是很多的大对象是朝生夕死的

6. 【线程的TLAB-堆上保证线程安全】

堆空间一定是共享的吗？ ———并不是！TLEB在堆上，是线程私有的

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

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

使用逃逸分析，编译器可对如下代码进行优化：

• 栈上分配
• 同步省略
• 分离对象或者标量替换

堆外存储技术，包括TLEB是为了能够减少GC的频率，避免出现同步问题，提高程序的性能。