Java虚拟机调优实战 - 摩柯技术社区

Java 虚拟机调优基础概念

在深入探讨 Java 虚拟机（JVM）调优实战之前，我们需要先明确一些基础概念。JVM 是 Java 程序运行的核心，它负责加载字节码文件，并将字节码指令解释或编译成机器码在底层操作系统和硬件上执行。

1. 内存区域划分

JVM 的内存区域主要分为以下几个部分：

程序计数器（Program Counter Register）：这是一块较小的内存空间，它记录的是当前线程所执行的字节码的行号指示器。在多线程环境下，每个线程都有自己独立的程序计数器，因为线程切换后需要恢复到正确的执行位置。
Java 虚拟机栈（Java Virtual Machine Stack）：与线程紧密相关，每个线程在创建时都会创建一个虚拟机栈。它用于存储栈帧，栈帧中保存了方法的局部变量表、操作数栈、动态链接和方法返回地址等信息。当一个方法被调用时，就会在栈顶压入一个新的栈帧；方法执行完毕后，栈帧就会出栈。
本地方法栈（Native Method Stack）：与 Java 虚拟机栈类似，只不过它是为 JVM 执行本地方法（使用 C 或 C++ 等语言编写的方法）服务的。
Java 堆（Java Heap）：这是 JVM 内存管理的核心区域，几乎所有的对象实例都在这里分配内存。Java 堆是线程共享的，它被划分为新生代（Young Generation）和老年代（Old Generation）。新生代又进一步分为 Eden 区和两个 Survivor 区（通常称为 S0 和 S1）。大部分新创建的对象首先会被分配到 Eden 区，当 Eden 区空间不足时，会触发一次 Minor GC，存活的对象会被移动到 Survivor 区。在 Survivor 区经过多次 GC 后仍然存活的对象，会被晋升到老年代。
方法区（Method Area）：用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。在 JDK 8 及之后，方法区被元空间（Meta Space）所取代，元空间使用本地内存，而不是像之前那样在堆中分配。

2. 垃圾回收机制

垃圾回收（Garbage Collection，GC）是 JVM 自动管理内存的重要机制。其主要目标是回收不再被程序使用的对象所占用的内存空间，以避免内存泄漏和提高内存利用率。

垃圾对象的判定：
- 引用计数法：给对象添加一个引用计数器，每当有一个地方引用该对象时，计数器值就加 1；当引用失效时，计数器值就减 1。当计数器值为 0 时，就认为该对象可以被回收。但是这种方法存在循环引用的问题，比如两个对象互相引用，即使它们都不再被其他地方引用，计数器也不会为 0，导致无法回收。
- 可达性分析法：通过一系列称为 “GC Roots” 的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain）。当一个对象到 GC Roots 没有任何引用链相连时，则证明此对象是不可用的，可以被回收。在 Java 中，可作为 GC Roots 的对象包括虚拟机栈中局部变量表指向的对象、方法区中类静态属性引用的对象、方法区中常量引用的对象以及本地方法栈中 JNI（即 Native 方法）引用的对象等。
垃圾回收算法：
- 标记 - 清除算法（Mark - Sweep）：分为标记和清除两个阶段。首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。这种算法的主要问题是会产生大量不连续的内存碎片，空间碎片太多可能会导致在以后的内存分配过程中，无法找到足够大的连续内存而不得不提前触发垃圾回收。
- 复制算法（Copying）：将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。这种算法实现简单，运行高效，但是代价是将内存缩小为原来的一半。现代 JVM 中的新生代垃圾回收通常采用这种算法的优化版本，如将新生代分为 Eden 区和两个 Survivor 区，每次只使用 Eden 区和其中一个 Survivor 区，当 Eden 区满时，将存活对象复制到另一个 Survivor 区，这样可以保证一定的内存利用率。
- 标记 - 整理算法（Mark - Compact）：标记过程和标记 - 清除算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。这种算法解决了标记 - 清除算法产生内存碎片的问题，主要用于老年代的垃圾回收。

性能监控工具

在进行 JVM 调优之前，我们需要借助一些性能监控工具来了解 JVM 的运行状况，收集关键性能指标，以便找出性能瓶颈。

1. JDK 自带工具

jps（Java Virtual Machine Process Status Tool）：用于列出正在运行的 JVM 进程。它会显示进程 ID 和主类的名称。例如，在命令行中执行 jps，可能会得到如下输出：

1234 MainClass
5678 AnotherClass

这里的 1234 和 5678 就是对应的 JVM 进程 ID，MainClass 和 AnotherClass 是主类名。

jstat（Java Virtual Machine Statistics Monitoring Tool）：可以用于监视 JVM 各种运行状态信息，包括堆内存、垃圾回收、类加载等情况。例如，要查看某个进程（假设进程 ID 为 1234）的垃圾回收情况，可以执行 jstat -gc 1234 1000 10。其中，-gc 表示查看垃圾回收相关信息，1234 是进程 ID，1000 表示每 1000 毫秒输出一次数据，10 表示总共输出 10 次。输出结果类似如下：

 S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT
1024.0 1024.0  0.0    0.0    8192.0   1234.0   16384.0    3456.0   1280.0 1024.0 160.0 128.0     5    0.123     1    0.023    0.146

其中，S0C、S1C 分别表示 Survivor0 区和 Survivor1 区的容量，S0U、S1U 表示已使用的容量，EC、EU 表示 Eden 区的容量和已使用容量，OC、OU 表示老年代的容量和已使用容量，MC、MU 表示方法区（元空间）的容量和已使用容量，CCSC、CCSU 表示压缩类空间的容量和已使用容量，YGC 表示新生代垃圾回收次数，YGCT 表示新生代垃圾回收总耗时，FGC 表示老年代垃圾回收次数，FGCT 表示老年代垃圾回收总耗时，GCT 表示垃圾回收总耗时。

jmap（Java Memory Map）：用于生成堆转储快照（heap dump 文件），也可以查看堆内存的详细信息，如对象分布情况等。要生成堆转储快照，可以执行 jmap -dump:format=b,file=heapdump.hprof 1234，其中 1234 是进程 ID，heapdump.hprof 是生成的文件名。生成的文件可以使用工具如 VisualVM 或 Eclipse Memory Analyzer（MAT）进行分析。
jstack（Java Stack Trace）：用于生成当前 JVM 的线程快照，通过分析线程快照可以定位线程死锁、线程长时间停顿等问题。执行 jstack 1234 即可获取进程 ID 为 1234 的线程快照。

2. 第三方工具

VisualVM：这是一个功能强大的可视化工具，集成了多种 JVM 监控和分析功能。它可以连接到本地或远程的 JVM 进程，实时监控内存、CPU、线程等运行状况。通过 VisualVM，可以方便地查看堆内存使用情况、垃圾回收次数和耗时、线程状态等信息，还可以进行线程dump 和堆dump 操作，并对 dump 文件进行分析。
Eclipse Memory Analyzer（MAT）：专门用于分析堆转储快照文件。它可以帮助我们快速定位内存泄漏问题，找出占用大量内存的对象及其引用链。MAT 提供了丰富的分析工具和报表，如直方图（Histogram）用于展示不同类型对象的数量和占用内存大小，支配树（Dominator Tree）用于查看对象之间的支配关系等。

常见性能问题及调优策略

在 Java 应用程序的运行过程中，可能会遇到各种性能问题，下面我们来详细探讨一些常见的问题及其调优策略。

1. 内存溢出（OutOfMemoryError）

堆内存溢出（java.lang.OutOfMemoryError: Java heap space）：
- 原因：当应用程序创建的对象过多，导致堆内存无法容纳时，就会抛出这个错误。常见的情况包括对象创建频率过高、对象生命周期过长、内存泄漏（对象已经不再使用，但由于错误的引用关系导致无法被垃圾回收）等。
- 调优策略：
  - 增加堆内存大小：可以通过 -Xms 和 -Xmx 参数来设置堆内存的初始大小和最大大小。例如，-Xms2g -Xmx4g 表示初始堆内存为 2GB，最大堆内存为 4GB。增加堆内存大小可以在一定程度上缓解内存不足的问题，但并不是越大越好，因为过大的堆内存可能会导致垃圾回收时间变长。
  - 优化代码：检查代码中是否存在对象创建不合理的地方，比如在循环中频繁创建大量不必要的对象。尽量复用对象，减少对象的创建次数。例如，使用对象池技术，如数据库连接池、线程池等。对于不再使用的对象，及时释放引用，让垃圾回收器能够回收其占用的内存。
  - 调整垃圾回收器：根据应用程序的特点选择合适的垃圾回收器。不同的垃圾回收器在吞吐量、停顿时间等方面有不同的表现。例如，对于响应时间敏感的应用程序，可以选择 CMS（Concurrent Mark Sweep）垃圾回收器或 G1（Garbage - First）垃圾回收器；对于吞吐量优先的应用程序，可以选择 Parallel Scavenge 垃圾回收器。
- 代码示例：

import java.util.ArrayList;
import java.util.List;

public class HeapOOMExample {
    public static void main(String[] args) {
        List<byte[]> list = new ArrayList<>();
        while (true) {
            list.add(new byte[1024 * 1024]);// 每次创建 1MB 的数组
        }
    }
}

运行上述代码，在没有足够堆内存的情况下，很快就会抛出 java.lang.OutOfMemoryError: Java heap space 错误。

方法区（元空间）内存溢出（java.lang.OutOfMemoryError: Metaspace）：
- 原因：在 JDK 8 及之后，方法区被元空间取代，元空间使用本地内存。当应用程序加载的类过多、动态生成的类过多（如使用 CGLib 等动态代理技术），或者类的元数据信息占用空间过大时，可能会导致元空间内存溢出。
- 调优策略：
  - 调整元空间大小：可以通过 -XX:MetaspaceSize 和 -XX:MaxMetaspaceSize 参数来设置元空间的初始大小和最大大小。例如，-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m。
  - 优化类加载机制：检查是否存在不必要的类加载，尽量避免动态生成过多的类。对于动态生成的类，及时释放相关的类加载器，以便元空间能够回收相关的元数据。
- 代码示例：

import net.sf.cglib.proxy.Enhancer;
import net.sf.cglib.proxy.MethodInterceptor;
import net.sf.cglib.proxy.MethodProxy;

import java.lang.reflect.Method;
import java.util.ArrayList;
import java.util.List;

public class MetaspaceOOMExample {
    public static void main(String[] args) {
        List<Object> list = new ArrayList<>();
        while (true) {
            Enhancer enhancer = new Enhancer();
            enhancer.setSuperclass(MetaspaceOOMExample.class);
            enhancer.setCallback(new MethodInterceptor() {
                @Override
                public Object intercept(Object o, Method method, Object[] objects, MethodProxy methodProxy) throws Throwable {
                    return methodProxy.invokeSuper(o, objects);
                }
            });
            Object obj = enhancer.create();
            list.add(obj);
        }
    }
}

上述代码使用 CGLib 动态生成类，如果持续运行，在元空间不足时会抛出 java.lang.OutOfMemoryError: Metaspace 错误。

2. 垃圾回收性能问题

垃圾回收时间过长：
- 原因：垃圾回收时间过长可能是由于堆内存过大、垃圾回收算法选择不当、应用程序对象分配和存活模式不合理等原因导致的。例如，当堆内存很大且存在大量长期存活的对象时，垃圾回收器在处理这些对象时可能需要花费较长时间。
- 调优策略：
  - 调整堆内存大小：根据应用程序的实际情况，合理调整堆内存的大小。如果堆内存过大，可以适当减小堆内存，以减少垃圾回收的工作量。但要注意，过小的堆内存可能会导致频繁的垃圾回收，也会影响性能。
  - 选择合适的垃圾回收器：不同的垃圾回收器适用于不同的应用场景。例如，CMS 垃圾回收器采用并发标记 - 清除算法，在垃圾回收过程中可以与应用程序并发执行，能有效减少停顿时间，但可能会产生内存碎片。G1 垃圾回收器则可以更好地处理大堆内存，将堆内存划分为多个 Region，采用分区回收的方式，能在一定程度上兼顾吞吐量和停顿时间。
  - 优化对象分配和存活模式：尽量让对象在新生代存活时间短，尽快被回收。可以通过调整新生代和老年代的比例（使用 -XX:NewRatio 参数）来控制对象晋升到老年代的速度。如果应用程序中有大量短期存活的对象，可以适当增大新生代的空间，减少 Minor GC 的频率。
- 代码示例：

public class GCTuningExample {
    public static void main(String[] args) {
        byte[] data = new byte[1024 * 1024 * 10];// 创建一个 10MB 的数组
        // 模拟对象在堆中的存活和回收
        for (int i = 0; i < 100000; i++) {
            byte[] smallData = new byte[1024];// 每次创建 1KB 的小对象
        }
    }
}

在上述代码中，如果新生代空间过小，这些 1KB 的小对象可能会频繁触发 Minor GC，导致垃圾回收时间增加。可以通过调整 -XX:NewRatio 等参数来优化。

频繁的垃圾回收：
- 原因：频繁的垃圾回收通常是由于对象创建过于频繁，导致堆内存很快被填满，从而频繁触发垃圾回收。这可能是因为代码中存在不合理的对象创建逻辑，或者堆内存设置过小。
- 调优策略：
  - 优化代码：检查代码中对象创建的逻辑，尽量复用对象，减少不必要的对象创建。例如，对于一些固定不变的对象，可以使用单例模式。
  - 调整堆内存大小：适当增加堆内存的大小，减少垃圾回收的频率。但要注意观察垃圾回收时间是否会因为堆内存增大而变长。
  - 分析对象的生命周期：了解应用程序中对象的存活时间和使用模式，合理调整新生代和老年代的大小比例，让对象在合适的区域进行回收。

实战案例分析

下面通过一个具体的实战案例来展示如何进行 JVM 调优。

1. 案例背景

我们有一个基于 Spring Boot 的 Web 应用程序，用于处理大量的用户请求，进行数据查询和处理。随着用户量的增加，应用程序开始出现响应时间变长、偶尔出现内存溢出等问题。

2. 性能分析

使用性能监控工具：首先，使用 VisualVM 连接到运行中的应用程序进程，实时监控内存、CPU 和线程的运行状况。通过 VisualVM 发现，堆内存使用量持续上升，经常接近最大堆内存限制，并且垃圾回收频率较高，尤其是 Minor GC。同时，CPU 使用率也一直维持在较高水平。
生成堆转储快照和线程快照：使用 jmap 生成堆转储快照文件，使用 jstack 生成线程快照。通过 MAT 分析堆转储快照，发现有一个自定义的缓存类中保存了大量长时间未使用的对象，这些对象占用了大量的堆内存，导致内存泄漏。通过分析线程快照，发现有部分线程因为等待数据库连接而长时间处于 BLOCKED 状态，这也是导致响应时间变长的原因之一。

3. 调优措施

修复内存泄漏问题：在代码中找到缓存类，优化缓存策略，及时清理不再使用的对象。例如，为缓存设置过期时间，当对象过期时自动从缓存中移除。

import java.util.HashMap;
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.TimeUnit;

public class Cache {
    private static final Map<String, CacheEntry> cache = new ConcurrentHashMap<>();
    private static final long EXPIRE_TIME = TimeUnit.MINUTES.toMillis(10);

    public static void put(String key, Object value) {
        long currentTime = System.currentTimeMillis();
        cache.put(key, new CacheEntry(currentTime, value));
    }

    public static Object get(String key) {
        CacheEntry entry = cache.get(key);
        if (entry == null || System.currentTimeMillis() - entry.timestamp > EXPIRE_TIME) {
            cache.remove(key);
            return null;
        }
        return entry.value;
    }

    private static class CacheEntry {
        long timestamp;
        Object value;

        CacheEntry(long timestamp, Object value) {
            this.timestamp = timestamp;
            this.value = value;
        }
    }
}

调整数据库连接池：增加数据库连接池的最大连接数，避免线程长时间等待数据库连接。例如，在 Spring Boot 应用程序的配置文件中，修改数据源的配置：

spring:
  datasource:
    hikari:
      maximum - pool - size: 50

优化垃圾回收器：根据应用程序的特点，将垃圾回收器从默认的 Parallel Scavenge + Parallel Old 调整为 G1。在启动命令中添加参数 -XX:+UseG1GC。G1 垃圾回收器在处理大堆内存和减少停顿时间方面有较好的表现，更适合该应用程序的需求。
调整堆内存大小：通过分析性能数据，适当增加堆内存的大小。设置 -Xms4g -Xmx8g，增加初始堆内存和最大堆内存，以减少垃圾回收的频率。同时，调整新生代和老年代的比例，设置 -XX:NewRatio=2，即新生代占堆内存的 1/3，老年代占 2/3。这样可以根据应用程序中对象的存活模式，更好地管理内存。

4. 调优效果验证

经过上述调优措施后，再次使用 VisualVM 监控应用程序的性能。发现堆内存使用量更加稳定，垃圾回收频率明显降低，尤其是 Minor GC 的频率大幅下降。CPU 使用率也有所降低，应用程序的响应时间显著缩短，不再出现内存溢出的问题，整体性能得到了有效提升。

总结与展望

JVM 调优是一个复杂而又关键的任务，需要深入理解 JVM 的内部机制、垃圾回收算法以及应用程序的业务特点。通过合理使用性能监控工具，准确分析性能问题，采取针对性的调优策略，可以显著提升 Java 应用程序的性能和稳定性。在未来，随着硬件技术的不断发展和应用场景的日益复杂，JVM 调优也将面临新的挑战和机遇。例如，随着大数据和人工智能等领域的发展，对 JVM 处理大规模数据和复杂计算的能力提出了更高的要求。我们需要不断学习和探索新的调优技术和方法，以适应这些变化，确保 Java 应用程序始终保持高效运行。同时，JVM 本身也在不断演进，新的垃圾回收算法和内存管理机制可能会不断涌现，这也要求我们持续关注 JVM 的发展动态，及时将新的技术应用到实际项目中。总之，JVM 调优是一个持续优化的过程，需要我们在实践中不断积累经验，以达到最佳的性能表现。