JVM垃圾回收机制与性能优化实战-代码聚汇网

JVM垃圾回收机制与性能优化实战

lloydsheng

1. JVM垃圾回收机制深度解析

作为Java开发者，JVM的垃圾回收机制是我们必须掌握的核心知识。在实际工作中，我经常遇到因为对GC理解不足导致的内存泄漏、性能下降等问题。今天我就结合自己多年的实战经验，带大家彻底搞懂JVM垃圾回收的方方面面。

JVM的垃圾回收机制就像是一个高效的"城市环卫系统"：它需要准确识别哪些内存是"垃圾"（不再使用的对象），然后及时清理释放空间，同时还要尽量减少对"市民"（应用程序线程）的干扰。这个系统设计得是否合理，直接关系到我们Java应用的性能和稳定性。

2. JVM堆内存结构与分配策略

2.1 堆内存的分代设计

JVM堆内存采用分代收集的思想，就像图书馆把书籍按新旧程度分类管理一样。在JDK1.7及之前，堆内存分为：

新生代（Young Generation）：存放新创建的对象，又细分为：
- Eden区：对象出生的地方
- Survivor区（S0和S1）：存放经过一次GC后存活的对象
老年代（Old Generation）：存放长期存活的对象
永久代（Permanent Generation）：存放类元数据等

从JDK1.8开始，永久代被元空间（Metaspace）取代，元空间使用本地内存而非JVM堆内存，这样可以避免永久代的内存溢出问题，同时也提高了元数据的处理效率。

实际经验：在生产环境中，我们经常通过-XX:MetaspaceSize和-XX:MaxMetaspaceSize参数来设置元空间大小，避免它无限增长消耗过多系统内存。

2.2 内存分配的核心原则

JVM的内存分配遵循三个黄金法则：

对象优先在Eden区分配：就像新生儿首先被安排在婴儿房一样，新对象默认在Eden区分配。当Eden区满时，会触发Minor GC。
大对象直接进入老年代：需要大量连续内存空间的对象（如大数组）会直接进入老年代，避免在新生代频繁复制。这个阈值可以通过-XX:PretenureSizeThreshold参数设置。
长期存活对象晋升老年代：对象在Survivor区每熬过一次Minor GC，年龄就增加1岁。当年龄达到阈值（默认15，可通过-XX:MaxTenuringThreshold调整）时，就会晋升到老年代。JVM还采用动态年龄计算：如果某一年龄的对象总大小超过Survivor区的一半，那么大于等于该年龄的对象就可以直接晋升。

java复制// 示例：大对象直接进入老年代
public class BigObjectExample {
    private static final int _1MB = 1024 * 1024;
    
    public static void main(String[] args) {
        byte[] bigObject = new byte[10 * _1MB];  // 超过PretenureSizeThreshold的大对象会直接进入老年代
    }
}

3. 垃圾回收的分类与触发条件

3.1 GC的分类

根据回收范围，GC可以分为两大类：

Partial GC（部分收集）：
- Minor GC/Young GC：只回收新生代
- Old GC：只回收老年代（只有CMS收集器支持）
- Mixed GC：回收新生代和部分老年代（只有G1收集器支持）
Full GC（整堆收集）：回收整个堆和方法区，通常会导致较长的停顿时间

3.2 GC的触发条件

不同的GC有不同的触发条件：

Minor GC触发条件：Eden区空间不足时触发
Full GC触发条件：
- 老年代空间不足
- 方法区（元空间）空间不足
- 调用System.gc()（不建议使用）
- Minor GC时空间分配担保失败

空间分配担保机制是JVM确保Minor GC安全的重要机制。在JDK6 Update24之后，只要老年代的连续空间大于新生代对象总大小或者历次晋升到老年代对象的平均大小，就会进行Minor GC，否则会先触发Full GC。

避坑指南：在实际应用中，我们经常会遇到因为空间分配担保导致的Full GC。可以通过适当增大老年代空间或调整-XX:MaxTenuringThreshold参数来优化。

4. 对象存活的判定方法

4.1 引用计数法

引用计数法是最简单的垃圾判定方法：每个对象有一个引用计数器，被引用时加1，引用失效时减1。当计数器为0时，对象就可以被回收。

优点：实现简单，判定效率高
缺点：无法解决循环引用问题

java复制// 循环引用示例
class Node {
    Node next;
}

public class ReferenceCounting {
    public static void main(String[] args) {
        Node a = new Node();
        Node b = new Node();
        a.next = b;
        b.next = a;  // 循环引用
        
        a = null;
        b = null;  // 虽然a和b都置为null，但因为循环引用，引用计数不为0
    }
}

由于这个致命缺陷，主流JVM都没有采用引用计数法。

4.2 可达性分析算法

可达性分析算法是JVM采用的垃圾判定方法。它的基本思路是通过一系列称为"GC Roots"的对象作为起点，从这些节点开始向下搜索，搜索所走过的路径称为引用链。当一个对象到GC Roots没有任何引用链相连时，就证明此对象是不可用的。

GC Roots包括：

虚拟机栈中引用的对象（局部变量）
方法区中类静态属性引用的对象
方法区中常量引用的对象
本地方法栈中JNI引用的对象
Java虚拟机内部的引用（如基本类型对应的Class对象）
被同步锁持有的对象

4.3 finalize()方法

即使对象在可达性分析中被判定为不可达，也并非"非死不可"。对象还有最后一次自救机会——finalize()方法。

对象被判定为不可达后，会先被第一次标记并进行筛选：如果对象没有覆盖finalize()方法，或者finalize()方法已经被JVM调用过，那么它就会被直接回收；否则，对象会被放入一个队列中，由JVM自动建立一个低优先级的Finalizer线程去执行它们的finalize()方法。

在finalize()方法中，对象可以通过重新与引用链上的任何一个对象建立关联来自救。但是，finalize()方法只会被JVM调用一次，而且不保证会被及时执行，因此不推荐依赖这个方法进行资源回收。

实战经验：在实际开发中，应该避免使用finalize()方法，而应该使用try-with-resources或者显式的close()方法来释放资源。

5. Java引用类型详解

从JDK1.2开始，Java将引用分为四种类型，强度依次减弱：

5.1 强引用（Strong Reference）

强引用是最常见的引用类型，如Object obj = new Object()。只要强引用存在，垃圾收集器就永远不会回收被引用的对象。

特点：

可以直接访问目标对象
强引用存在时，对象不会被回收
可能导致内存泄漏

5.2 软引用（Soft Reference）

软引用用来描述一些还有用但非必需的对象。在系统将要发生内存溢出异常前，会把这些对象列入回收范围进行第二次回收。如果这次回收还没有足够的内存，才会抛出内存溢出异常。

java复制SoftReference<byte[]> softRef = new SoftReference<>(new byte[1024*1024]);
// 使用softRef.get()获取对象，可能返回null

适用场景：实现内存敏感的高速缓存

5.3 弱引用（Weak Reference）

弱引用比软引用更弱一些。被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。

java复制WeakReference<byte[]> weakRef = new WeakReference<>(new byte[1024]);
// weakRef.get()可能随时返回null

适用场景：实现规范化映射（如WeakHashMap）

5.4 虚引用（Phantom Reference）

虚引用是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。虚引用的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。

java复制ReferenceQueue<Object> queue = new ReferenceQueue<>();
PhantomReference<Object> phantomRef = new PhantomReference<>(new Object(), queue);
// phantomRef.get()总是返回null

适用场景：跟踪对象被垃圾回收的活动

6. 废弃常量与无用类的回收

6.1 废弃常量的回收

运行时常量池中的常量（如字符串）如果没有任何对象引用它，就会被视为废弃常量，可以被回收。

从JDK1.7开始，字符串常量池被移到了堆中，这使得字符串的回收更加高效。JDK1.8之后，方法区的实现改为元空间，但运行时常量池仍然在方法区中。

6.2 无用类的回收

判定一个类为"无用类"需要同时满足以下三个条件：

该类的所有实例都已被回收
加载该类的ClassLoader已被回收
该类的Class对象没有被任何地方引用（无法通过反射访问该类）

即使满足以上条件，JVM也不一定会回收无用类，因为这涉及到类卸载的复杂问题。在大量使用动态代理、反射等技术的应用中，需要特别注意类加载和卸载的问题，避免元空间内存泄漏。

性能调优技巧：在频繁生成动态类的场景（如使用CGLib）中，可以通过-XX:+CMSClassUnloadingEnabled参数开启类卸载功能，避免元空间内存泄漏。

7. 垃圾收集算法详解

7.1 标记-清除算法

标记-清除算法是最基础的垃圾收集算法，分为两个阶段：

标记阶段：标记出所有需要回收的对象
清除阶段：统一回收所有被标记的对象

优点：实现简单
缺点：

效率问题：标记和清除两个过程的效率都不高
空间问题：会产生大量不连续的内存碎片

7.2 复制算法

复制算法将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。

优点：

实现简单，运行高效
不会产生内存碎片

缺点：

可用内存缩小为原来的一半
当对象存活率较高时，需要进行较多的复制操作

优化：在新生代中，由于98%的对象都是"朝生夕死"的，所以并不需要按照1:1的比例来划分内存空间。HotSpot虚拟机默认的Eden和Survivor的大小比例是8:1:1。

7.3 标记-整理算法

标记-整理算法也分为两个阶段：

标记阶段：与标记-清除算法相同
整理阶段：让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存

优点：

不会产生内存碎片
适合老年代这种存活对象多的场景

缺点：

移动存活对象需要更新引用，效率较低

7.4 分代收集算法

现代商业虚拟机大多采用分代收集算法，它根据对象存活周期的不同将内存划分为几块，然后根据各个年代的特点采用最适当的收集算法。

新生代：采用复制算法，因为每次回收都有大量对象死去
老年代：采用标记-清除或标记-整理算法，因为对象存活率高

8. HotSpot垃圾收集器实战解析

HotSpot虚拟机提供了多种垃圾收集器，每种都有其特点和适用场景。下面我们详细分析几种主要的收集器。

8.1 Serial收集器

Serial收集器是最基本、历史最悠久的收集器，它是一个单线程的收集器，在进行垃圾收集时，必须暂停其他所有工作线程（"Stop The World"）。

特点：

新生代使用复制算法
老年代使用标记-整理算法
简单高效，没有线程交互开销

适用场景：Client模式下的虚拟机，或内存较小的嵌入式系统

8.2 ParNew收集器

ParNew收集器实质上是Serial收集器的多线程版本，除了使用多线程进行垃圾收集外，其余行为与Serial收集器完全一样。

特点：

新生代收集器
多线程并行收集
能与CMS收集器配合工作

适用场景：Server模式下的虚拟机首选的新生代收集器

8.3 Parallel Scavenge收集器

Parallel Scavenge收集器是一个新生代收集器，它使用复制算法，并且是多线程并行的。它的特点是关注吞吐量（运行用户代码时间/(运行用户代码时间+垃圾收集时间)）。

特点：

吞吐量优先
支持自适应调节策略
JDK1.8默认的新生代收集器

适用场景：适合后台运算而不需要太多交互的任务

8.4 CMS收集器

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。它基于标记-清除算法实现。

工作过程：

初始标记（STW）：标记GC Roots能直接关联到的对象
并发标记：进行GC Roots Tracing
重新标记（STW）：修正并发标记期间因用户程序继续运作而导致标记产生变动的那部分对象的标记记录
并发清除

优点：并发收集，低停顿
缺点：

对CPU资源敏感
无法处理浮动垃圾
会产生内存碎片

注意：CMS收集器在JDK14中已被移除，建议使用G1或ZGC作为替代。

8.5 G1收集器

G1（Garbage-First）收集器是面向服务端应用的垃圾收集器，从JDK9开始成为默认的垃圾收集器。

特点：

并行与并发：能充分利用多核CPU环境
分代收集：仍然保留分代概念
空间整合：整体上看是标记-整理算法，局部看是复制算法
可预测的停顿：可以设置期望的停顿时间目标