Java JVM基础知识与线上实践全总结

JVM（Java Virtual Machine，Java虚拟机）是Java语言跨平台特性的核心，负责将Java字节码解释或编译为底层机器指令，同时管理内存、垃圾回收、线程调度等核心功能。掌握JVM基础知识、GC算法演进、线上参数配置及问题排查，是Java后端开发工程师必备的核心能力。本文将系统梳理相关知识点，结合线上实践场景，为开发者提供全面的参考。

一、Java JVM基础知识

1.1 JVM整体架构

JVM架构主要分为三大模块：类加载子系统、运行时数据区、执行引擎，辅以垃圾回收系统，各模块协同工作完成字节码的执行与资源管理。

• 类加载子系统：负责将.class文件（字节码）加载到JVM中，核心流程包括加载、验证、准备、解析、初始化5个阶段。加载阶段通过类加载器（Bootstrap ClassLoader、Extension ClassLoader、Application ClassLoader）查找类资源；验证阶段确保字节码符合JVM规范，避免恶意代码；准备阶段为类变量分配内存并设置默认初始值；解析阶段将符号引用转换为直接引用；初始化阶段执行类构造器方法，完成类的初始化。

• 运行时数据区：JVM在运行时划分的内存区域，也是GC的核心作用区域，分为以下5部分：

  • 程序计数器（Program Counter Register）：线程私有，记录当前线程执行的字节码行号，无GC（不会OutOfMemoryError）。

  • 虚拟机栈（VM Stack）：线程私有，存储栈帧（方法执行时的上下文），包含局部变量表、操作数栈、动态链接、方法出口等，栈深度不足会抛出StackOverflowError，内存不足会抛出OutOfMemoryError。

  • 本地方法栈（Native Method Stack）：线程私有，为Native方法（非Java实现的方法）提供运行环境，与虚拟机栈功能类似，同样会抛出StackOverflowError和OutOfMemoryError。

  • 方法区（Method Area）：线程共享，存储类信息、常量、静态变量、即时编译后的代码等，JDK8后用元空间（Metaspace）替代永久代（PermGen），元空间使用本地内存，默认无上限（可通过参数限制），避免了永久代OOM问题。

  • 堆（Heap）：线程共享，JVM中最大的内存区域，用于存储对象实例和数组，是垃圾回收（GC）的主要区域。堆可分为年轻代（Young Generation）、老年代（Old Generation），部分垃圾收集器（如G1）会打破这种划分。

• 执行引擎：将加载到JVM中的字节码转换为机器指令执行，主要有两种执行方式：解释执行（逐行解释字节码，启动快、执行慢）和即时编译（JIT，将热点代码编译为机器码，执行快、启动慢），JVM会根据代码执行频率动态切换两种方式，平衡启动速度和执行效率。

• 垃圾回收系统（GC）：负责回收堆和方法区中不再使用的对象，释放内存资源，避免内存泄漏，核心是“判断对象是否存活”和“回收存活对象占用的内存”。

1.2 核心概念补充

• 对象存活判断：JVM采用“可达性分析算法”判断对象是否存活，以GC Roots为起点，遍历对象引用链，若对象无法通过任何GC Roots到达，则判定为可回收对象。GC Roots包括：虚拟机栈中局部变量表引用的对象、本地方法栈中Native方法引用的对象、方法区中静态变量和常量引用的对象、活跃线程引用的对象。

• 内存溢出（OOM）与内存泄漏：内存溢出是指JVM没有足够的内存分配给新对象；内存泄漏是指对象不再使用，但仍被GC Roots引用，无法被回收，长期积累会导致OOM。

• 分代回收思想：基于“对象存活时间不同”的特点，将堆分为年轻代和老年代，年轻代对象存活时间短、回收频繁，老年代对象存活时间长、回收频率低，不同代采用不同的GC算法，提升回收效率。

二、GC算法的演进

GC算法的核心目标是：高效回收可回收对象，减少GC停顿时间（STW，Stop The World），避免影响应用正常运行。随着JDK版本的迭代，GC算法不断优化，从早期的串行回收，逐步演进到并行、并发回收，兼顾回收效率和应用可用性。

2.1 基础GC算法（早期）

2.1.1 标记-清除算法（Mark-Sweep）

最基础的GC算法，分为两个阶段：

1. 标记阶段：遍历所有对象，标记出可回收对象（无法通过GC Roots到达的对象）。

2. 清除阶段：遍历堆内存，清除所有被标记的可回收对象，释放内存。

优点：实现简单，无需移动对象。
缺点：1. 标记和清除过程都需要STW，效率低；2. 清除后会产生大量内存碎片，后续分配大对象时可能因没有连续内存而提前触发GC。

2.1.2 复制算法（Copying）

为解决标记-清除算法的内存碎片问题而设计，核心是“将堆分为两个大小相等的区域（From区和To区）”，仅使用其中一个区域（From区）：

1. 标记阶段：标记From区中存活的对象。

2. 复制阶段：将From区中存活的对象复制到To区，按顺序排列，避免内存碎片。

3. 切换阶段：清空From区，将From区和To区角色互换，下一次GC继续使用From区。

优点：无内存碎片，回收效率高（仅复制存活对象）。
缺点：1. 内存利用率低（仅使用一半内存）；2. 复制大量对象时，STW时间较长。

适用场景：年轻代（对象存活时间短，存活对象少，复制成本低），目前年轻代默认采用复制算法（优化版：将年轻代分为Eden区和两个Survivor区，比例默认8:1:1，避免内存利用率过低）。

2.1.3 标记-整理算法（Mark-Compact）

结合标记-清除和复制算法的优点，解决老年代对象存活时间长、存活对象多的问题，分为三个阶段：

1. 标记阶段：遍历所有对象，标记出存活对象。

2. 整理阶段：将所有存活对象向堆的一端移动，按顺序排列。

3. 清除阶段：清除堆另一端的可回收对象，释放内存。

优点：无内存碎片，内存利用率高。
缺点：整理阶段需要移动对象，STW时间较长，效率低于复制算法。

适用场景：老年代（对象存活时间长，存活对象多，复制成本高，需避免内存碎片）。

2.2 进阶GC算法（分代回收）

分代回收算法本身不是一种独立的GC算法，而是结合“复制算法”和“标记-整理算法”，根据对象存活时间的不同，在年轻代和老年代采用不同的算法，提升整体GC效率。

核心流程：

1. 年轻代（Eden + 2个Survivor）：采用复制算法。对象优先分配到Eden区，Eden区满后触发Minor GC（年轻代GC），将Eden区和一个Survivor区（From）的存活对象复制到另一个Survivor区（To），清空Eden和From区；多次Minor GC后，存活对象年龄达到阈值（默认15），晋升到老年代。

2. 老年代：采用标记-整理算法。老年代内存满后触发Major GC（老年代GC），也叫Full GC，会同时回收年轻代和老年代的可回收对象，STW时间较长，对应用性能影响较大。

2.3 现代GC算法（JDK8及以后主流）

2.3.1 并行GC（Parallel GC）

JDK8默认的GC算法，属于分代回收算法的优化版，核心是“并行执行GC任务”，减少STW时间。

• 年轻代：Parallel Scavenge（并行清除），采用复制算法，多个GC线程并行执行标记和复制，提升回收效率。

• 老年代：Parallel Old，采用标记-整理算法，同样支持多线程并行执行，适合CPU核心数多、对吞吐量要求高的场景（如后台服务）。

优点：吞吐量高（GC时间占总运行时间比例低），适合大数据量、高并发场景。
缺点：Full GC时STW时间仍较长，不适合对响应时间要求高的场景（如接口服务）。

2.3.2 并发标记清除GC（CMS GC）

为解决Parallel GC的STW时间过长问题而设计，核心是“并发执行GC任务”，减少STW时间，属于分代回收算法。

核心流程（老年代）：

1. 初始标记：标记GC Roots直接引用的对象，STW时间短（毫秒级）。

2. 并发标记：与应用线程并行执行，遍历GC Roots引用链，标记可回收对象，无STW。

3. 重新标记：修正并发标记期间因应用线程运行导致的标记偏差，STW时间短。

4. 并发清除：与应用线程并行执行，清除可回收对象，无STW。

优点：Full GC时STW时间短，适合对响应时间要求高的场景（如接口服务、Web应用）。
缺点：1. 并发标记和清除过程会占用CPU资源，影响应用吞吐量；2. 会产生内存碎片；3. 无法处理浮动垃圾（并发清除期间产生的新垃圾，需下次GC回收）。

注意：JDK9中CMS GC被标记为废弃，JDK14中正式移除。

2.3.3 G1 GC（Garbage-First）

JDK9及以后默认的GC算法，兼顾吞吐量和响应时间，打破了分代回收的固定划分，核心是“区域化分代式”回收。

• 内存划分：将堆分为多个大小相等的区域（Region），每个Region可动态标记为Eden区、Survivor区、老年代区，无需固定大小和比例，灵活分配内存。

• 核心思想：优先回收垃圾最多的Region（Garbage-First），减少GC时间；采用“标记-复制”算法，无内存碎片；支持并发标记和并行回收，STW时间可预测（通过参数设置最大STW时间）。

• 核心流程：初始标记 → 并发标记 → 最终标记 → 筛选回收（并行执行，STW）。

优点：兼顾吞吐量和响应时间，无内存碎片，STW时间可控制，适合大内存、高并发场景（如服务器、微服务）。
缺点：内存区域划分和管理复杂，CPU占用较高。

2.3.4 ZGC、Shenandoah GC（新一代GC）

JDK11及以后推出的新一代GC算法，核心目标是“超低延迟”（STW时间控制在毫秒级以下），适合超大内存（如百GB、TB级）场景。

• ZGC：采用“着色指针”和“读屏障”技术，支持并发标记、并发重定位，STW时间不随堆大小增加而增加，适合超大内存场景（如金融、电商核心服务）。

• Shenandoah GC：与ZGC目标类似，采用“并发整理”算法，无需移动对象即可完成内存整理，STW时间短，适合对延迟敏感的超大内存应用。

三、线上JVM参数配置

线上JVM参数配置的核心目标是：优化内存分配、减少GC停顿、避免OOM、提升应用性能，需结合应用类型（如Web应用、后台服务）、内存大小、并发量等场景灵活调整。以下是常用参数及配置原则，以JDK8（Parallel GC）和JDK11+（G1 GC）为例。

3.1 核心内存参数（必配）

核心内存参数控制堆、元空间、栈的大小，是线上配置的基础，需根据服务器内存大小合理分配（建议堆内存不超过服务器物理内存的50%-70%，避免占用过多内存导致操作系统卡顿）。

参数	说明	示例（JDK8）	示例（JDK11+ G1）
-Xms	堆初始大小，与-Xmx设置一致，避免堆内存动态扩容导致性能波动	-Xms4g	-Xms4g
-Xmx	堆最大大小，控制堆内存上限，避免OOM	-Xmx4g	-Xmx4g
-XX:MetaspaceSize	元空间初始大小（JDK8+，替代永久代）	-XX:MetaspaceSize=256m	-XX:MetaspaceSize=256m
-XX:MaxMetaspaceSize	元空间最大大小，避免元空间无限增长导致OOM	-XX:MaxMetaspaceSize=512m	-XX:MaxMetaspaceSize=512m
-Xss	每个线程的虚拟机栈大小，根据线程数调整，避免StackOverflowError	-Xss1m	-Xss1m

3.2 GC相关参数（按GC算法分类）

3.2.1 Parallel GC（JDK8默认）

适合后台服务、吞吐量优先的场景，常用参数：

• -XX:+UseParallelGC：启用Parallel GC（年轻代）。

• -XX:+UseParallelOldGC：启用Parallel Old GC（老年代），与Parallel GC配合使用。

• -XX:ParallelGCThreads：GC线程数，建议设置为CPU核心数（或核心数-1），避免GC线程占用过多CPU。

• -XX:MaxGCPauseMillis：设置最大GC停顿时间（毫秒），JVM会自动调整堆大小和GC参数，尽可能满足该要求（优先级低于吞吐量）。

• -XX:GCTimeRatio：设置GC时间占总运行时间的比例（默认99），公式为1/(1+GCTimeRatio)，如99表示GC时间不超过1%，优先级高于MaxGCPauseMillis。

3.2.2 G1 GC（JDK9+默认）

适合Web应用、响应时间优先的场景，常用参数：

• -XX:+UseG1GC：启用G1 GC。

• -XX:G1HeapRegionSize：设置每个Region的大小（1M~32M），默认根据堆大小自动计算，建议设置为2的幂次方。

• -XX:MaxGCPauseMillis：设置最大GC停顿时间（默认200毫秒），G1会优先回收垃圾多的Region，确保停顿时间不超过该值。

• -XX:ParallelGCThreads：GC线程数，与CPU核心数匹配。

• -XX:ConcGCThreads：并发标记线程数，默认是ParallelGCThreads的1/4，可根据CPU负载调整。

• -XX:InitiatingHeapOccupancyPercent：触发并发标记的堆占用阈值（默认45%），堆占用达到该值时，启动并发标记，避免堆满触发Full GC。

3.2.3 日志相关参数（必配，用于问题排查）

线上必须配置GC日志参数，便于后续排查GC问题，常用参数：

• -XX:+PrintGCDetails：打印详细GC日志（包含回收前后内存大小、GC时间等）。

• -XX:+PrintGCTimeStamps：打印GC发生的时间戳（相对于JVM启动时间）。

• -XX:+PrintGCDateStamps：打印GC发生的具体日期时间（便于定位问题时间点）。

• -Xloggc:/var/log/java/gc.log：指定GC日志输出路径，避免日志输出到控制台。

• -XX:+UseGCLogFileRotation：启用GC日志轮转，避免日志文件过大。

• -XX:NumberOfGCLogFiles=10：日志文件数量（默认1）。

• -XX:GCLogFileSize=100m：每个日志文件的大小（默认50m）。

3.3 线上配置示例

示例1：JDK8 + Parallel GC（4核8G服务器，后台服务）

java -jar -Xms4g -Xmx4g -Xss1m -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m -XX:+UseParallelGC -XX:+UseParallelOldGC -XX:ParallelGCThreads=4 -XX:MaxGCPauseMillis=200 -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/var/log/java/gc.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100m app.jar

示例2：JDK11 + G1 GC（8核16G服务器，Web应用）

java -jar -Xms8g -Xmx8g -Xss1m -XX:MetaspaceSize=512m -XX:MaxMetaspaceSize=1g -XX:+UseG1GC -XX:G1HeapRegionSize=4m -XX:MaxGCPauseMillis=100 -XX:ParallelGCThreads=8 -XX:ConcGCThreads=2 -XX:InitiatingHeapOccupancyPercent=45 -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/var/log/java/gc.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100m app.jar

3.4 配置原则

• 堆内存：-Xms与-Xmx保持一致，避免动态扩容；堆大小不超过服务器物理内存的70%，预留内存给操作系统和其他进程。

• 元空间：根据应用依赖的类数量调整，一般设置为256m~1g，避免设置过大浪费内存。

• GC线程：与CPU核心数匹配，避免过多线程竞争CPU，导致应用性能下降。

• 日志：必须配置GC日志，便于后续问题排查，同时启用日志轮转，避免日志文件过大。

• 调优：线上配置需经过测试，根据GC日志和应用性能监控，逐步调整参数，避免盲目配置。

四、线上GC问题排查分析（含GC日志分析）

线上GC问题主要表现为：GC频繁、GC停顿时间过长、OOM（内存溢出），核心排查思路是“收集日志 → 分析日志 → 定位问题 → 调整参数/优化代码”，其中GC日志是排查的核心依据。

4.1 排查前准备（收集关键信息）

• GC日志：通过之前配置的-Xloggc参数获取，确保日志完整（包含GC类型、回收前后内存、时间等）。

• JVM参数：收集应用启动时的JVM参数（确认堆大小、GC算法、日志配置等）。

• 应用监控数据：通过Prometheus、Grafana、JVisualVM等工具，收集应用的CPU、内存、线程、GC次数、GC停顿时间等数据。

• 线程快照（jstack）：当应用卡顿、GC频繁时，通过jstack命令获取线程快照，排查是否有死锁、线程阻塞等问题。

• 内存快照（jmap）：当出现OOM时，通过jmap命令获取内存快照（heap dump），分析内存泄漏的对象。

4.2 GC日志分析方法（核心）

GC日志包含Minor GC（年轻代GC）、Major GC（老年代GC）、Full GC（全量GC）的详细信息，不同GC算法的日志格式略有差异，但核心信息一致，以下以Parallel GC和G1 GC为例，讲解日志分析要点。

4.2.1 Parallel GC日志示例及分析

text

2026-03-24T10:00:00.123+0800: 123.456: [GC (Allocation Failure) [PSYoungGen: 327680K->5120K(384000K)] 427680K->105120K(1024000K), 0.0080000 secs] [Times: user=0.02 sys=0.01, real=0.01 secs]
2026-03-24T10:05:00.456+0800: 423.789: [Full GC (Ergonomics) [PSYoungGen: 384000K->0K(384000K)] [ParOldGen: 640000K->620000K(640000K)] 1024000K->620000K(1024000K), [Metaspace: 256000K->256000K(512000K)], 0.1200000 secs] [Times: user=0.36 sys=0.03, real=0.12 secs]

日志核心信息解读：

1. 时间戳：2026-03-24T10:00:00.123+0800（GC发生的具体时间）；123.456（JVM启动后的时间，单位：秒）。

2. GC类型：

   • GC (Allocation Failure)：Minor GC，触发原因是年轻代分配内存失败（Eden区满）。

   • Full GC (Ergonomics)：Full GC，触发原因是JVM自动优化（Ergonomics），也可能是老年代满、元空间满等。

3. 内存变化：

   • PSYoungGen: 327680K->5120K(384000K)：年轻代回收前320M，回收后5M，年轻代总大小375M。

   • 427680K->105120K(1024000K)：堆内存回收前417.5M，回收后102.656M，堆总大小1000M。

   • ParOldGen: 640000K->620000K(640000K)：老年代回收前625M，回收后605.468M，老年代总大小625M。

   • Metaspace: 256000K->256000K(512000K)：元空间无回收，使用250M，总大小500M。

4. GC时间：

   • real=0.01 secs：实际GC时间（STW时间），0.01秒，影响较小。

   • user=0.02 sys=0.01：GC线程占用的CPU时间（user是用户态时间，sys是内核态时间）。

4.2.2 G1 GC日志示例及分析

text

2026-03-24T10:10:00.789+0800: 723.123: [GC pause (G1 Evacuation Pause) (young), 0.0050000 secs]
   [Parallel Time: 4.0 ms, GC Workers: 8]
      [GC Worker Start (ms): 723123.1, 723123.1, 723123.1, 723123.1, 723123.1, 723123.1, 723123.1, 723123.1]
      [Ext Root Scanning (ms): 1.2, 1.1, 1.0, 1.1, 1.0, 1.1, 1.0, 1.1]
      [Update RS (ms): 0.5, 0.4, 0.5, 0.4, 0.5, 0.4, 0.5, 0.4]
      [Processed Buffers: 10, 8, 9, 8, 9, 8, 9, 8]
      [Scan RS (ms): 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3]
      [Code Root Scanning (ms): 0.1, 0.1, 0.1, 0.1, 0.1, 0.1, 0.1, 0.1]
      [Object Copy (ms): 1.8, 1.9, 1.9, 1.8, 1.9, 1.8, 1.9, 1.8]
      [Termination (ms): 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
   [GC Worker Other (ms): 0.1, 0.1, 0.1, 0.1, 0.1, 0.1, 0.1, 0.1]
   [GC Worker Total (ms): 3.9, 3.8, 3.8, 3.7, 3.8, 3.7, 3.8, 3.7]
   [GC Worker End (ms): 723127.0, 723126.9, 723126.9, 723126.8, 723126.9, 723126.8, 723126.9, 723126.8]
   [Heap Before GC: 8192.0M->Heap After GC: 4096.0M(16384.0M)]
   [Young Gen Before GC: 4096.0M->Young Gen After GC: 2048.0M(8192.0M)]
   [Old Gen Before GC: 4096.0M->Old Gen After GC: 2048.0M(8192.0M)]
 [Times: user=0.03 sys=0.01, real=0.01 secs]

G1 GC日志核心信息解读：

1. GC类型：GC pause (G1 Evacuation Pause) (young)：年轻代GC（Evacuation Pause，复制存活对象）。

2. GC线程：GC Workers: 8（8个GC线程并行执行）。

3. 各阶段时间：Ext Root Scanning（根扫描）、Object Copy（对象复制）等阶段的时间，可定位GC耗时瓶颈。

4. 内存变化：Heap Before GC（堆回收前）、Heap After GC（堆回收后）、Young Gen（年轻代）、Old Gen（老年代）的内存变化。

5. GC时间：real=0.01 secs（STW时间），G1 GC的停顿时间通常较短，若超过MaxGCPauseMillis，需调整参数。

4.2.3 日志分析工具

手动分析GC日志效率低，可借助工具快速分析，常用工具：

• GCViewer：开源工具，可可视化展示GC日志，包括GC次数、GC时间、内存变化等，支持导出图表。

• GCEasy：在线工具（https://gceasy.io/），上传GC日志，自动生成分析报告，包含GC统计、瓶颈分析、优化建议。

• JVisualVM：JDK自带工具，可加载GC日志，实时查看GC情况，同时支持线程监控、内存快照分析。

• Arthas：阿里开源工具，可在线查看GC情况（gc命令）、线程快照、内存使用情况，无需重启应用，适合线上排查。

4.3 常见GC问题及排查方案

4.3.1 问题1：Minor GC频繁

表现：Minor GC每秒发生多次，每次GC时间较短，但累计GC时间占比高，影响应用吞吐量。

排查步骤：

1. 查看GC日志：确认Minor GC触发原因（Allocation Failure），查看年轻代内存变化，判断是否年轻代过小。

2. 分析应用：是否有大量短期对象频繁创建（如循环创建对象、接口请求中频繁new对象），导致Eden区快速占满。

解决方案：

• 增大年轻代大小：调整-Xmn参数（年轻代初始大小和最大大小），或调整Eden与Survivor的比例（-XX:SurvivorRatio，默认8:1:1）。

• 优化代码：减少短期对象的创建，使用对象池（如连接池、线程池）复用对象，避免频繁new对象。

• 调整GC线程数：确保GC线程数与CPU核心数匹配，提升Minor GC效率。

4.3.2 问题2：Full GC频繁/Full GC时间过长

表现：Full GC每分钟发生多次，或每次Full GC时间超过1秒，导致应用卡顿、响应时间变长。

排查步骤：

1. 查看GC日志：确认Full GC触发原因（老年代满、元空间满、System.gc()调用、GC ergonomics等）。

2. 分析内存使用：通过jmap获取内存快照，查看老年代中存活对象的类型和数量，判断是否有内存泄漏，或对象晋升到老年代过快。

3. 查看线程快照：通过jstack查看是否有线程阻塞、死锁，导致对象无法被回收。

解决方案：

• 增大老年代大小：调整-Xmx参数（堆最大大小），或调整年轻代与老年代的比例（分代回收算法）。

• 排查内存泄漏：通过内存快照分析，找到长期被引用、无法回收的对象（如静态集合未清理、缓存未设置过期时间），优化代码释放引用。

• 调整对象晋升阈值：通过-XX:MaxTenuringThreshold调整对象晋升到老年代的年龄（默认15），避免短期对象过早晋升。

• 更换GC算法：若使用Parallel GC，可切换为G1 GC，减少Full GC停顿时间；若内存较大，可使用ZGC/Shenandoah GC。

• 禁止System.gc()：通过-XX:+DisableExplicitGC禁止应用调用System.gc()（避免手动触发Full GC）。

4.3.3 问题3：OOM（内存溢出）

表现：应用崩溃，日志中出现OutOfMemoryError，常见类型：Java heap space（堆溢出）、Metaspace（元空间溢出）、StackOverflowError（栈溢出）。

排查步骤：

1. 确认OOM类型：根据日志中的错误信息，判断是堆溢出、元空间溢出还是栈溢出。

2. 收集内存快照：OOM发生时，通过-XX:+HeapDumpOnOutOfMemoryError参数，自动生成内存快照（heap dump），或通过jmap命令手动生成。

3. 分析内存快照：使用JVisualVM、MAT（Memory Analyzer Tool）等工具，分析内存快照，找到内存泄漏的对象或占用内存过大的对象。

解决方案：

• Java heap space（堆溢出）：增大-Xmx参数；排查内存泄漏，优化代码释放引用；减少大对象的创建（如大数组、大字符串）。

• Metaspace（元空间溢出）：增大-XX:MaxMetaspaceSize参数；排查是否加载了过多的类（如动态生成类、依赖过多的jar包）。

• StackOverflowError（栈溢出）：增大-Xss参数；排查是否有递归调用过深（如无限递归），优化代码减少递归深度。

4.4 排查总结

线上GC问题排查的核心是“以GC日志为核心，结合监控数据和快照分析”，步骤可总结为：

1. 定位问题：通过应用监控（卡顿、响应慢、崩溃），确定是GC相关问题。

2. 收集信息：获取GC日志、JVM参数、线程快照、内存快照。

3. 分析日志：使用工具或手动分析GC日志，确定GC类型、触发原因、停顿时间、内存变化。

4. 定位根因：结合快照分析，找到内存泄漏、对象创建过多、参数不合理等问题根源。

5. 优化解决：调整JVM参数、优化代码、更换GC算法，测试验证优化效果。

五、总结

JVM基础知识是理解GC机制和参数配置的前提，GC算法的演进体现了“高效、低延迟”的核心需求，线上参数配置需结合应用场景灵活调整，而GC问题排查则需要熟练掌握日志分析和工具使用技巧。

对于Java后端开发者而言，掌握JVM相关知识，不仅能解决线上常见的GC问题、避免OOM，还能优化应用性能，提升系统的稳定性和可用性。实际应用中，需结合具体场景（如应用类型、内存大小、并发量），不断测试、调优，才能找到最适合的JVM配置方案。

（注：文档部分内容可能由 AI 生成）