分布式微服务系统架构第100集：JVM 底层原理，Java 中常见的JVM问题

加群联系作者vx：xiaoda0423

仓库地址：webvueblog.github.io/JavaPlusDoc...

1024bat.cn/

线程死锁分析示例

❗示例代码：

public class DeadlockExample {

    private static final Object LockA = new Object();
    private static final Object LockB = new Object();

    public static void main(String[] args) {
        Thread t1 = new Thread(() -> {
            synchronized (LockA) {
                System.out.println("Thread-1 locked A");
                sleep(100);
                synchronized (LockB) {
                    System.out.println("Thread-1 locked B");
                }
            }
        });

        Thread t2 = new Thread(() -> {
            synchronized (LockB) {
                System.out.println("Thread-2 locked B");
                sleep(100);
                synchronized (LockA) {
                    System.out.println("Thread-2 locked A");
                }
            }
        });

        t1.start();
        t2.start();
    }

    private static void sleep(long ms) {
        try {
            Thread.sleep(ms);
        } catch (InterruptedException ignored) {}
    }
}

💡说明：

• Thread-1 持有 LockA 等 LockB，Thread-2 持有 LockB 等 LockA，发生死锁。
• 可使用 jstack <pid> 观察死锁堆栈。

堆外内存泄漏（DirectBuffer 未释放）

❗示例代码：

import java.nio.ByteBuffer;
import java.util.ArrayList;
import java.util.List;

public class DirectMemoryLeak {

    public static void main(String[] args) {
        List<ByteBuffer> buffers = new ArrayList<>();
        while (true) {
            ByteBuffer buffer = ByteBuffer.allocateDirect(1024 * 1024); // 1MB
            buffers.add(buffer);  // 永久引用，无法回收
            System.out.println("Allocated 1MB DirectBuffer");
            sleep(100);
        }
    }

    private static void sleep(long ms) {
        try { Thread.sleep(ms); } catch (Exception ignored) {}
    }
}

💡说明：

• ByteBuffer.allocateDirect() 分配堆外内存。
• 没有主动释放，引用持有，导致 JVM 内存稳定，但直接内存溢出。

✅触发方式：

添加 JVM 参数 -XX:MaxDirectMemorySize=64m 限制堆外内存，快速复现。

模拟 GC 卡顿导致服务不可用

❗示例代码：

public class GCPauseSimulator {

    public static void main(String[] args) {
        List<byte[]> memoryHog = new ArrayList<>();
        while (true) {
            byte[] block = new byte[10 * 1024 * 1024]; // 10MB
            memoryHog.add(block);
            System.out.println("Allocated 10MB");
            sleep(200); // 控制速度让 GC 不断触发
        }
    }

    private static void sleep(long ms) {
        try { Thread.sleep(ms); } catch (Exception ignored) {}
    }
}

💡说明：

• 持续分配大对象，频繁 Full GC。
• 可使用 -Xms128m -Xmx128m 快速触发 GC。
• 服务响应会因 GC 卡顿严重下降。

服务运行一段时间后 OOM 示例（内存泄漏）

❗示例代码（模拟缓存/Session 不清理）：

import java.util.HashMap;
import java.util.Map;
import java.util.UUID;

public class MemoryLeakSimulator {

    private static final Map<String, String> cache = new HashMap<>();

    public static void main(String[] args) {
        while (true) {
            String key = UUID.randomUUID().toString();
            String value = UUID.randomUUID().toString();
            cache.put(key, value); // 永久增长
            System.out.println("Map size: " + cache.size());
            sleep(50);
        }
    }

    private static void sleep(long ms) {
        try { Thread.sleep(ms); } catch (Exception ignored) {}
    }
}

💡说明：

• 永久引用不断堆积内容，无淘汰策略。
• 触发 java.lang.OutOfMemoryError: Java heap space。

✅触发方式：

• JVM 参数：-Xms64m -Xmx64m -XX:+HeapDumpOnOutOfMemoryError。
• 使用 jmap 或 MAT 分析堆 dump。

启动参数详解：

-Xms128m

• 初始堆内存大小为 128MB。
• JVM 启动时立即分配的堆空间，不会随着程序运行动态增长。
• 小堆空间利于复现 OOM、频繁 GC 等问题。

---

-Xmx128m

• 最大堆内存大小为 128MB。
• 限制 JVM 使用的最大堆大小，超过即会抛出 OutOfMemoryError。

✅ -Xms 和 -Xmx 设置为相同值，可避免堆动态扩容带来的性能抖动。

---

-XX:MaxDirectMemorySize=64m

• 设置最大 DirectMemory（堆外内存）为 64MB。

• 对 ByteBuffer.allocateDirect() 分配的堆外内存生效。

• 超过这个限制时，会抛出：

  java.lang.OutOfMemoryError: Direct buffer memory

---

-XX:+HeapDumpOnOutOfMemoryError

• 当发生 OOM（OutOfMemoryError） 时，自动导出堆转储（Heap Dump）。
• 默认 dump 文件生成在当前工作目录，文件名类似于：
  java_pid12345.hprof

✅ 用于后续使用 MAT、VisualVM 等工具进行内存泄漏分析。

---

-XX:+PrintGCDetails

• 打印 GC 的详细信息，包括：

  • GC 类型（Young GC / Full GC）
  • 各内存区域的变化
  • 停顿时间
  • 吞吐率信息（Total time for which application threads were stopped）

---

-XX:+PrintGCDateStamps

• 在每次 GC 日志前，增加 时间戳（方便日志对齐分析）：

  2025-04-07T21:03:42.545+0800: [GC ...]

---

-XX:+PrintCommandLineFlags

• 在 JVM 启动时打印所有使用的命令行参数（包括默认值、显式值）：

  CommandLine flags: -XX:InitialHeapSize=134217728 -XX:MaxHeapSize=134217728 ...

---

-jar your-program.jar

• 启动你的 Java 应用，运行 your-program.jar，入口类从 JAR 的 MANIFEST.MF 中读取。

---

🧠 综合用途总结：

参数组合	作用
-Xms / -Xmx	控制堆大小，触发 OOM/GC
-XX:MaxDirectMemorySize	控制堆外内存限制
-XX:+HeapDumpOnOutOfMemoryError	自动生成 dump 文件，便于排查
-XX:+PrintGCDetails / +PrintGCDateStamps	打印 GC 日志，便于分析 GC 时间与频率
-XX:+PrintCommandLineFlags	启动时参数确认

对象的内存布局

在 HotSpot 虚拟机中，对象的内存布局分为以下 3 块区域：

• 对象头（Header）
• 实例数据（Instance Data）
• 对齐填充（Padding）

对象头

对象头记录了对象在运行过程中所需要使用的一些数据：

• 哈希码
• GC 分代年龄
• 锁状态标志
• 线程持有的锁
• 偏向线程 ID
• 偏向时间戳

对象头可能包含类型指针，通过该指针能确定对象属于哪个类。如果对象是一个数组，那么对象头还会包括数组长度。

实例数据

实例数据部分就是成员变量的值，其中包括父类成员变量和本类成员变量。

对齐填充

用于确保对象的总长度为 8 字节的整数倍。

HotSpot VM 的自动内存管理系统要求对象的大小必须是 8 字节的整数倍。而对象头部分正好是 8 字节的倍数（1 倍或 2 倍），因此，当对象实例数据部分没有对齐时，就需要通过对齐填充来补全。

对齐填充并不是必然存在，也没有特别的含义，它仅仅起着占位符的作用。

对象的创建过程

类加载检查

虚拟机在解析.class文件时，若遇到一条 new 指令，首先它会去检查常量池中是否有这个类的符号引用，并且检查这个符号引用所代表的类是否已被加载、解析和初始化过。如果没有，那么必须先执行相应的类加载过程。

为新生对象分配内存

对象所需内存的大小在类加载完成后便可完全确定，接下来从堆中划分一块对应大小的内存空间给新的对象。分配堆中内存有两种方式：

• 指针碰撞
  如果 Java 堆中内存绝对规整 （说明采用的是"复制算法 "或"标记整理法 "），空闲内存和已使用内存中间放着一个指针作为分界点指示器，那么分配内存时只需要把指针向空闲内存挪动一段与对象大小一样的距离，这种分配方式称为"指针碰撞"。
• 空闲列表
  如果 Java 堆中内存并不规整 ，已使用的内存和空闲内存交错（说明采用的是标记-清除法 ，有碎片），此时没法简单进行指针碰撞， VM 必须维护一个列表，记录其中哪些内存块空闲可用。分配之时从空闲列表中找到一块足够大的内存空间划分给对象实例。这种方式称为"空闲列表"。

初始化

分配完内存后，为对象中的成员变量赋上初始值，设置对象头信息，调用对象的构造函数方法进行初始化。

至此，整个对象的创建过程就完成了。

对象的访问方式

所有对象的存储空间都是在堆中分配的，但是这个对象的引用却是在堆栈中分配的。也就是说在建立一个对象时两个地方都分配内存，在堆中分配的内存实际建立这个对象，而在堆栈中分配的内存只是一个指向这个堆对象的指针（引用）而已。 那么根据引用存放的地址类型的不同，对象有不同的访问方式。

句柄访问方式

堆中需要有一块叫做"句柄池"的内存空间，句柄中包含了对象实例数据与类型数据各自的具体地址信息。

引用类型的变量存放的是该对象的句柄地址（reference）。访问对象时，首先需要通过引用类型的变量找到该对象的句柄，然后根据句柄中对象的地址找到对象。

直接指针访问方式

引用类型的变量直接存放对象的地址，从而不需要句柄池，通过引用能够直接访问对象。但对象所在的内存空间需要额外的策略存储对象所属的类信息的地址。

需要说明的是，HotSpot 采用第二种方式，即直接指针方式来访问对象，只需要一次寻址操作，所以在性能上比句柄访问方式快一倍。但像上面所说，它需要额外的策略来存储对象在方法区中类信息的地址。

可达性分析法

所有和 GC Roots 直接或间接关联的对象都是有效对象，和 GC Roots 没有关联的对象就是无效对象。

GC Roots 是指：

• Java 虚拟机栈（栈帧中的本地变量表）中引用的对象
• 本地方法栈中引用的对象
• 方法区中常量引用的对象
• 方法区中类静态属性引用的对象

GC Roots 并不包括堆中对象所引用的对象，这样就不会有循环引用的问题。

引用的种类

判定对象是否存活与"引用"有关。在 JDK 1.2 以前，Java 中的引用定义很传统，一个对象只有被引用或者没有被引用两种状态，我们希望能描述这一类对象：当内存空间还足够时，则保留在内存中；如果内存空间在进行垃圾收集后还是非常紧张，则可以抛弃这些对象。很多系统的缓存功能都符合这样的应用场景。

在 JDK 1.2 之后，Java 对引用的概念进行了扩充，将引用分为了以下四种。不同的引用类型，主要体现的是对象不同的可达性状态reachable和垃圾收集的影响。

强引用（Strong Reference）

类似 "Object obj = new Object()" 这类的引用，就是强引用，只要强引用存在，垃圾收集器永远不会回收被引用的对象。但是，如果我们错误地保持了强引用，比如：赋值给了 static 变量，那么对象在很长一段时间内不会被回收，会产生内存泄漏。

软引用（Soft Reference）

软引用是一种相对强引用弱化一些的引用，可以让对象豁免一些垃圾收集，只有当 JVM 认为内存不足时，才会去试图回收软引用指向的对象。JVM 会确保在抛出 OutOfMemoryError 之前，清理软引用指向的对象。软引用通常用来实现内存敏感的缓存，如果还有空闲内存，就可以暂时保留缓存，当内存不足时清理掉，这样就保证了使用缓存的同时，不会耗尽内存。

弱引用（Weak Reference）

弱引用的强度比软引用更弱 一些。当 JVM 进行垃圾回收时，无论内存是否充足，都会回收只被弱引用关联的对象。

虚引用（Phantom Reference）

虚引用也称幽灵引用或者幻影引用，它是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响。它仅仅是提供了一种确保对象被 finalize 以后，做某些事情的机制，比如，通常用来做所谓的 Post-Mortem 清理机制。

回收堆中无效对象

对于可达性分析中不可达的对象，也并不是没有存活的可能。

判定 finalize() 是否有必要执行

JVM 会判断此对象是否有必要执行 finalize() 方法，如果对象没有覆盖 finalize() 方法，或者 finalize() 方法已经被虚拟机调用过，那么视为"没有必要执行"。那么对象基本上就真的被回收了。

如果对象被判定为有必要执行 finalize() 方法，那么对象会被放入一个 F-Queue 队列中，虚拟机会以较低的优先级执行这些 finalize()方法，但不会确保所有的 finalize() 方法都会执行结束。如果 finalize() 方法出现耗时操作，虚拟机就直接停止指向该方法，将对象清除。

对象重生或死亡

如果在执行 finalize() 方法时，将 this 赋给了某一个引用，那么该对象就重生了。如果没有，那么就会被垃圾收集器清除。

任何一个对象的 finalize() 方法只会被系统自动调用一次，如果对象面临下一次回收，它的 finalize() 方法不会被再次执行，想继续在 finalize() 中自救就失效了。

回收方法区内存

方法区中存放生命周期较长的类信息、常量、静态变量，每次垃圾收集只有少量的垃圾被清除。方法区中主要清除两种垃圾：

• 废弃常量
• 无用的类

判定废弃常量

只要常量池中的常量不被任何变量或对象引用，那么这些常量就会被清除掉。比如，一个字符串 "bingo" 进入了常量池，但是当前系统没有任何一个 String 对象引用常量池中的 "bingo" 常量，也没有其它地方引用这个字面量，必要的话，"bingo"常量会被清理出常量池。

判定无用的类

判定一个类是否是"无用的类"，条件较为苛刻。

• 该类的所有对象都已经被清除
• 加载该类的 ClassLoader 已经被回收
• 该类的 java.lang.Class 对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

一个类被虚拟机加载进方法区，那么在堆中就会有一个代表该类的对象：java.lang.Class。这个对象在类被加载进方法区时创建，在方法区该类被删除时清除。

标记 的过程是：遍历所有的 GC Roots，然后将所有 GC Roots 可达的对象标记为存活的对象。

清除的过程将遍历堆中所有的对象，将没有标记的对象全部清除掉。与此同时，清除那些被标记过的对象的标记，以便下次的垃圾回收。

这种方法有两个不足：

• 效率问题：标记和清除两个过程的效率都不高。
• 空间问题：标记清除之后会产生大量不连续的内存碎片，碎片太多可能导致以后需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

为了解决效率问题，"复制"收集算法出现了。它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块内存用完，需要进行垃圾收集时，就将存活者的对象复制到另一块上面，然后将第一块内存全部清除。这种算法有优有劣：

• 优点：不会有内存碎片的问题。
• 缺点：内存缩小为原来的一半，浪费空间。

为了解决空间利用率问题，可以将内存分为三块： Eden、From Survivor、To Survivor，比例是 8:1:1，每次使用 Eden 和其中一块 Survivor。回收时，将 Eden 和 Survivor 中还存活的对象一次性复制到另外一块 Survivor 空间上，最后清理掉 Eden 和刚才使用的 Survivor 空间。这样只有 10% 的内存被浪费。

但是我们无法保证每次回收都只有不多于 10% 的对象存活，当 Survivor 空间不够，需要依赖其他内存（指老年代）进行分配担保。

分配担保

为对象分配内存空间时，如果 Eden+Survivor 中空闲区域无法装下该对象，会触发 MinorGC 进行垃圾收集。但如果 Minor GC 过后依然有超过 10% 的对象存活，这样存活的对象直接通过分配担保机制进入老年代，然后再将新对象存入 Eden 区。

标记 ：它的第一个阶段与标记-清除算法 是一模一样的，均是遍历 GC Roots，然后将存活的对象标记。

整理 ：移动所有存活的对象，且按照内存地址次序依次排列，然后将末端内存地址以后的内存全部回收。因此，第二阶段才称为整理阶段。

这是一种老年代的垃圾收集算法。老年代的对象一般寿命比较长，因此每次垃圾回收会有大量对象存活，如果采用复制算法，每次需要复制大量存活的对象，效率很低。

分代收集算法

根据对象存活周期的不同，将内存划分为几块。一般是把 Java 堆分为新生代和老年代，针对各个年代的特点采用最适当的收集算法。

• 新生代：复制算法
• 老年代：标记-清除算法、标记-整理算法

HotSpot 虚拟机提供了多种垃圾收集器，每种收集器都有各自的特点，虽然我们要对各个收集器进行比较，但并非为了挑选出一个最好的收集器。我们选择的只是对具体应用最合适的收集器。

新生代垃圾收集器

Serial 垃圾收集器（单线程）

只开启一条 GC 线程进行垃圾回收，并且在垃圾收集过程中停止一切用户线程，即 Stop The World。

一般客户端应用所需内存较小，不会创建太多对象，而且堆内存不大，因此垃圾收集器回收时间短，即使在这段时间停止一切用户线程，也不会感觉明显卡顿。因此 Serial 垃圾收集器适合客户端使用。

由于 Serial 收集器只使用一条 GC 线程，避免了线程切换的开销，从而简单高效。

ParNew 是 Serial 的多线程版本。由多条 GC 线程并行地进行垃圾清理。但清理过程依然需要 Stop The World。

ParNew 追求"低停顿时间 ",与 Serial 唯一区别就是使用了多线程进行垃圾收集，在多 CPU 环境下性能比 Serial 会有一定程度的提升；但线程切换需要额外的开销，因此在单 CPU 环境中表现不如 Serial。

Parallel Scavenge 和 ParNew 一样，都是多线程、新生代垃圾收集器。但是两者有巨大的不同点：

• Parallel Scavenge：追求 CPU 吞吐量，能够在较短时间内完成指定任务，因此适合没有交互的后台计算。
• ParNew：追求降低用户停顿时间，适合交互式应用。

吞吐量 = 运行用户代码时间 / (运行用户代码时间 + 垃圾收集时间)

追求高吞吐量，可以通过减少 GC 执行实际工作的时间，然而，仅仅偶尔运行 GC 意味着每当 GC 运行时将有许多工作要做，因为在此期间积累在堆中的对象数量很高。单个 GC 需要花更多的时间来完成，从而导致更高的暂停时间。而考虑到低暂停时间，最好频繁运行 GC 以便更快速完成，反过来又导致吞吐量下降。

• 通过参数 -XX:GCTimeRadio 设置垃圾回收时间占总 CPU 时间的百分比。
• 通过参数 -XX:MaxGCPauseMillis 设置垃圾处理过程最久停顿时间。
• 通过命令 -XX:+UseAdaptiveSizePolicy 开启自适应策略。我们只要设置好堆的大小和 MaxGCPauseMillis 或 GCTimeRadio，收集器会自动调整新生代的大小、Eden 和 Survivor 的比例、对象进入老年代的年龄，以最大程度上接近我们设置的 MaxGCPauseMillis 或 GCTimeRadio。

老年代垃圾收集器

Serial Old 垃圾收集器（单线程）

Serial Old 收集器是 Serial 的老年代版本，都是单线程收集器，只启用一条 GC 线程，都适合客户端应用。它们唯一的区别就是：Serial Old 工作在老年代，使用"标记-整理"算法；Serial 工作在新生代，使用"复制"算法。

Parallel Old 垃圾收集器（多线程）

Parallel Old 收集器是 Parallel Scavenge 的老年代版本，追求 CPU 吞吐量。

CMS 垃圾收集器

CMS（Concurrent Mark Sweep，并发标记清除）收集器是以获取最短回收停顿时间为目标的收集器（追求低停顿），它在垃圾收集时使得用户线程和 GC 线程并发执行，因此在垃圾收集过程中用户也不会感到明显的卡顿。

• 初始标记：Stop The World，仅使用一条初始标记线程对所有与 GC Roots 直接关联的对象进行标记。
• 并发标记：使用多条标记线程，与用户线程并发执行。此过程进行可达性分析，标记出所有废弃对象。速度很慢。
• 重新标记：Stop The World，使用多条标记线程并发执行，将刚才并发标记过程中新出现的废弃对象标记出来。
• 并发清除：只使用一条 GC 线程，与用户线程并发执行，清除刚才标记的对象。这个过程非常耗时。

并发标记与并发清除过程耗时最长，且可以与用户线程一起工作，因此，总体上说 ，CMS 收集器的内存回收过程是与用户线程一起并发执行的。

CMS 的缺点：

• 吞吐量低
• 无法处理浮动垃圾
• 使用"标记-清除"算法产生碎片空间，导致频繁 Full GC

对于产生碎片空间的问题，可以通过开启 -XX:+UseCMSCompactAtFullCollection，在每次 Full GC 完成后都会进行一次内存压缩整理，将零散在各处的对象整理到一块。设置参数 -XX:CMSFullGCsBeforeCompaction 告诉 CMS，经过了 N 次 Full GC 之后再进行一次内存整理。

G1 是一款面向服务端应用的垃圾收集器，它没有新生代和老年代的概念，而是将堆划分为一块块独立的 Region。当要进行垃圾收集时，首先估计每个 Region 中垃圾的数量，每次都从垃圾回收价值最大的 Region 开始回收，因此可以获得最大的回收效率。

从整体上看， G1 是基于"标记-整理"算法实现的收集器，从局部（两个 Region 之间）上看是基于"复制"算法实现的，这意味着运行期间不会产生内存空间碎片。

这里抛个问题 👇

一个对象和它内部所引用的对象可能不在同一个 Region 中，那么当垃圾回收时，是否需要扫描整个堆内存才能完整地进行一次可达性分析？

并不！每个 Region 都有一个 Remembered Set，用于记录本区域中所有对象引用的对象所在的区域，进行可达性分析时，只要在 GC Roots 中再加上 Remembered Set 即可防止对整个堆内存进行遍历。

如果不计算维护 Remembered Set 的操作，G1 收集器的工作过程分为以下几个步骤：

• 初始标记：Stop The World，仅使用一条初始标记线程对所有与 GC Roots 直接关联的对象进行标记。
• 并发标记：使用一条标记线程与用户线程并发执行。此过程进行可达性分析，速度很慢。
• 最终标记：Stop The World，使用多条标记线程并发执行。
• 筛选回收：回收废弃对象，此时也要 Stop The World，并使用多条筛选回收线程并发执行。

内存分配与回收策略

对象的内存分配，就是在堆上分配（也可能经过 JIT 编译后被拆散为标量类型并间接在栈上分配），对象主要分配在新生代的 Eden 区上，少数情况下可能直接分配在老年代，分配规则不固定，取决于当前使用的垃圾收集器组合以及相关的参数配置。

以下列举几条最普遍的内存分配规则，供大家学习。

对象优先在 Eden 分配

大多数情况下，对象在新生代 Eden 区中分配。当 Eden 区没有足够空间进行分配时，虚拟机将发起一次 Minor GC。

👇Minor GC vs Major GC /Full GC：

• Minor GC：回收新生代（包括 Eden 和 Survivor 区域），因为 Java 对象大多都具备朝生夕灭的特性，所以 Minor GC 非常频繁，一般回收速度也比较快。
• Major GC / Full GC：回收老年代，出现了 Major GC，经常会伴随至少一次的 Minor GC，但这并非绝对。Major GC 的速度一般会比 Minor GC 慢 10 倍 以上。

在 JVM 规范中，Major GC 和 Full GC 都没有一个正式的定义，所以有人也简单地认为 Major GC 清理老年代，而 Full GC 清理整个内存堆。

大对象直接进入老年代

大对象是指需要大量连续内存空间的 Java 对象，如很长的字符串或数据。

一个大对象能够存入 Eden 区的概率比较小，发生分配担保的概率比较大，而分配担保需要涉及大量的复制，就会造成效率低下。

虚拟机提供了一个 -XX:PretenureSizeThreshold 参数，令大于这个设置值的对象直接在老年代分配，这样做的目的是避免在 Eden 区及两个 Survivor 区之间发生大量的内存复制。（还记得吗，新生代采用复制算法回收垃圾）

长期存活的对象将进入老年代

JVM 给每个对象定义了一个对象年龄计数器。当新生代发生一次 Minor GC 后，存活下来的对象年龄 +1，当年龄超过一定值时，就将超过该值的所有对象转移到老年代中去。

使用 -XXMaxTenuringThreshold 设置新生代的最大年龄，只要超过该参数的新生代对象都会被转移到老年代中去。

动态对象年龄判定

如果当前新生代的 Survivor 中，相同年龄所有对象大小的总和大于 Survivor 空间的一半，年龄 >= 该年龄的对象就可以直接进入老年代，无须等到 MaxTenuringThreshold 中要求的年龄。

空间分配担保

JDK 6 Update 24 之前的规则是这样的：

在发生 Minor GC 之前，虚拟机会先检查老年代最大可用的连续空间是否大于新生代所有对象总空间 ， 如果这个条件成立，Minor GC 可以确保是安全的； 如果不成立，则虚拟机会查看 HandlePromotionFailure 值是否设置为允许担保失败， 如果是，那么会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小， 如果大于，将尝试进行一次 Minor GC，尽管这次 Minor GC 是有风险的； 如果小于，或者 HandlePromotionFailure 设置不允许冒险，那此时也要改为进行一次 Full GC。

JDK 6 Update 24 之后的规则变为：

只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小，就会进行 Minor GC，否则将进行 Full GC。

通过清除老年代中的废弃数据来扩大老年代空闲空间，以便给新生代作担保。

这个过程就是分配担保。

---

👇 总结一下有哪些情况可能会触发 JVM 进行 Full GC。

1. System.gc() 方法的调用 此方法的调用是建议 JVM 进行 Full GC，注意这只是建议而非一定 ，但在很多情况下它会触发 Full GC，从而增加 Full GC 的频率。通常情况下我们只需要让虚拟机自己去管理内存即可，我们可以通过 -XX:+ DisableExplicitGC 来禁止调用 System.gc()。
2. 老年代空间不足 老年代空间不足会触发 Full GC 操作，若进行该操作后空间依然不足，则会抛出如下错误：java.lang.OutOfMemoryError: Java heap space
3. 永久代空间不足 JVM 规范中运行时数据区域中的方法区，在 HotSpot 虚拟机中也称为永久代（Permanet Generation），存放一些类信息、常量、静态变量等数据，当系统要加载的类、反射的类和调用的方法较多时，永久代可能会被占满，会触发 Full GC。如果经过 Full GC 仍然回收不了，那么 JVM 会抛出如下错误信息：java.lang.OutOfMemoryError: PermGen space
4. CMS GC 时出现 promotion failed 和 concurrent mode failure promotion failed，就是上文所说的担保失败，而 concurrent mode failure 是在执行 CMS GC 的过程中同时有对象要放入老年代，而此时老年代空间不足造成的。
5. 统计得到的 Minor GC 晋升到旧生代的平均大小大于老年代的剩余空间。