大兴安岭地区网站建设_网站建设公司_营销型网站_seo优化

JVM性能调优与监控实战完整指南

一、JVM内存模型深度解析

1.1 JVM内存结构概述

Java虚拟机（JVM）作为Java程序的运行环境，承担着内存管理、垃圾回收、字节码执行等核心职责。在JVM的众多职责中，内存管理无疑是最重要的一环。合理的内存划分和管理，直接影响到应用程序的性能表现。

当我们谈论JVM性能调优时，首先需要深入理解JVM是如何组织和管理内存的。JVM在执行Java程序时，会将系统分配给它的内存划分为多个不同的数据区域，每个区域有着明确的用途、创建时间和销毁时间。这种设计不是随意为之，而是经过精心考虑的结果，目的是为了更高效地管理内存、更快速地分配对象、更安全地执行垃圾回收。

理解这些内存区域的划分方式、各自的职责、以及它们之间的协作关系，是进行JVM性能调优的基础。只有深入了解了内存的组织结构，我们才能在遇到内存问题时快速定位原因，才能在进行参数调优时做到有的放矢。

从宏观角度来看，JVM内存可以分为两大类：线程共享区域和线程私有区域。线程共享区域包括堆内存和方法区，这些区域在JVM启动时创建，所有线程都可以访问这些区域的数据。线程私有区域包括程序计数器、虚拟机栈和本地方法栈，这些区域的生命周期与线程相同，随线程的创建而创建，随线程的结束而销毁。

根据Java虚拟机规范，JVM内存主要分为以下几个区域：

JVM内存结构 ├── 堆内存（Heap）- 线程共享 │ ├── 年轻代（Young Generation） │ │ ├── Eden区 │ │ ├── Survivor0区（From） │ │ └── Survivor1区（To） │ └── 老年代（Old Generation） ├── 方法区（Method Area）- 线程共享 │ ├── 运行时常量池 │ ├── 类型信息 │ └── 字段和方法信息 ├── 虚拟机栈（VM Stack）- 线程私有 ├── 本地方法栈（Native Method Stack）- 线程私有 ├── 程序计数器（Program Counter Register）- 线程私有 └── 直接内存（Direct Memory）- 不属于JVM规范

1.2 堆内存详解

堆内存是JVM内存管理中最核心、也是最复杂的一块区域。从大小上来说，堆通常是JVM管理的最大一块内存空间，在现代应用中，堆内存的大小通常从几百兆到几十GB不等。从重要性上来说，堆是垃圾回收器工作的主战场，几乎所有的对象实例以及数组都在堆上分配内存。可以说，堆内存的设计和管理水平，直接决定了JVM的性能表现。

为什么堆内存如此重要？这要从Java的内存分配机制说起。在Java中，我们通过new关键字创建对象时，这些对象的内存主要分配在堆上。与栈内存不同，堆内存不会随着方法的结束而自动回收，这些对象会一直存在于内存中，直到垃圾回收器判断它们不再被使用时才会被回收。这种特性使得堆内存的管理变得复杂，需要专门的垃圾回收机制来处理。

堆内存的一个核心设计理念是"分代管理"。这个设计源于一个被大量实际应用验证的经验规律：绝大多数对象的生命周期都很短，它们被创建后很快就会变得不可达，可以被回收；只有很少一部分对象会长期存活。这个规律被称为"弱分代假说"（Weak Generational Hypothesis）。基于这个假说，JVM将堆内存划分为不同的"代"，对不同年龄的对象采用不同的回收策略，从而大大提高了垃圾回收的效率。

1.2.1 年轻代（Young Generation）

年轻代是所有新创建对象的"出生地"。当我们在代码中创建一个对象时，这个对象通常会首先被分配到年轻代的Eden区。年轻代的设计体现了"朝生夕死"的对象特点——大部分对象在这里被创建，也在这里被回收。

从容量规划角度来看，年轻代的大小通常占整个堆内存的1/3左右。这个比例不是固定的，而是可以根据应用的特点进行调整。如果你的应用创建了大量生命周期很短的对象（比如Web应用中的Request、Response对象），那么可以适当增大年轻代的比例；反之，如果应用中对象的生命周期普遍较长，则可以减小年轻代的比例。

年轻代内部又进一步细分为三个区域：Eden区和两个Survivor区。这种设计看似复杂，实际上是为了实现高效的垃圾回收算法。让我们详细了解这三个区域：

Eden区（伊甸园区）

Eden区是年轻代中最大的一块区域，默认占据年轻代的80%空间。之所以叫Eden（伊甸园），寓意是所有对象的"出生地"。几乎所有新创建的对象都会首先被分配到这里，这是对象生命周期的起点。

Eden区采用的是一种非常高效的内存分配策略，叫做"指针碰撞"（Bump the Pointer）。简单来说，JVM维护一个指针，指向Eden区已使用内存和未使用内存的分界点。当需要分配新对象时，只需要检查剩余空间是否足够，如果足够，就将指针向前移动相应的大小即可。这种分配方式非常快速，几乎与在栈上分配内存的速度相当。

当Eden区的空间被用完时，就会触发一次Minor GC（也叫Young GC）。这时候，JVM会暂停应用程序的运行（Stop The World），检查Eden区中的所有对象，找出那些仍然被引用的"存活对象"，将它们复制到Survivor区，然后清空整个Eden区。整个过程通常非常快，因为Eden区中的大部分对象都已经"死亡"，需要复制的对象很少。

Survivor区（幸存者区）

Survivor区的设计是年轻代回收机制中最巧妙的部分。它由两个大小完全相等的区域组成，通常称为S0和S1，或者From区和To区。每个Survivor区默认占年轻代的10%空间。

为什么需要两个Survivor区？这个设计源于一个重要的考虑：如何避免内存碎片。如果只有一个Survivor区，那么在多次GC后，这个区域会充满各种大小不一的对象，它们之间会产生很多不连续的空闲空间。这些碎片化的空间很难被有效利用，可能导致明明有足够的总空闲空间，却无法分配一个稍大的对象。

两个Survivor区的工作机制是这样的：在任何时刻，两个Survivor区中只有一个是"活跃"的（From区），另一个保持完全空闲（To区）。当发生Minor GC时，Eden区和From区中的存活对象会被一起复制到To区。复制完成后，Eden区和From区被完全清空，然后From区和To区的角色互换——原来的To区变成新的From区，原来的From区变成新的To区。这种"乒乓"式的切换机制，确保了使用中的Survivor区始终是紧凑的、没有碎片的。

这种复制算法有个额外的好处：它天然地实现了内存整理。每次GC后，所有存活对象都被整齐地排列在To区的前端，没有任何碎片。这使得后续的对象分配仍然可以使用快速的指针碰撞方式。

对象在年轻代的生命周期：一个对象的成长之路

理解对象在年轻代的完整生命周期，对于理解JVM的内存管理至关重要。让我们跟随一个对象从创建到晋升的整个过程：

首先，当应用程序创建一个新对象时，这个对象会被分配到Eden区。此时，这个对象的"年龄"（Age）被标记为0。对象的年龄是JVM用来跟踪对象经历了多少次GC的一个计数器。

随着程序的运行，越来越多的对象被创建，Eden区逐渐被填满。当Eden区无法再分配新对象时，JVM触发第一次Minor GC。垃圾回收器会扫描Eden区的所有对象，识别哪些对象仍然被程序引用（存活对象），哪些对象已经没有被引用（垃圾对象）。存活对象会被复制到Survivor0区，同时它们的年龄增加到1。垃圾对象则被清除，Eden区恢复为空。

程序继续运行，新的对象继续在Eden区分配。当Eden区再次填满时，触发第二次Minor GC。这次不仅要扫描Eden区，还要扫描Survivor0区。Eden区和Survivor0区中的存活对象会一起被复制到Survivor1区，它们的年龄再次加1（对于Eden区的新对象，年龄变为1；对于Survivor0区的对象，年龄变为2）。然后Eden区和Survivor0区被清空。

这个过程会反复进行。每次Minor GC时，Eden区和使用中的Survivor区（From区）的存活对象都会被复制到空闲的Survivor区（To区），对象年龄加1，然后两个Survivor区角色互换。

那么，对象什么时候会离开年轻代，进入老年代呢？默认情况下，当对象的年龄达到15时，就会被"晋升"（Promotion）到老年代。为什么是15？因为对象头中用于存储年龄的位段只有4位，最大只能表示15。当然，这个阈值是可以通过参数调整的。

值得注意的是，对象并不一定要等到年龄达到15才能晋升。如果Survivor区空间不足，装不下所有存活对象，那么一些对象会提前晋升到老年代，即使它们的年龄还很小。这被称为"过早晋升"（Premature Promotion），是一种不理想的情况，因为这些对象可能很快就会死亡，但却进入了老年代，增加了老年代GC的负担。

1.2.2 老年代（Old Generation）

老年代是堆内存中用于存放"长者"的区域，这里的对象都是经过多次GC考验、依然存活的"老对象"。从空间分配来看，老年代通常占据堆内存的2/3左右，这个比例反映了一个事实：虽然大部分对象都很短命，但那些长寿对象所占用的总内存量却不小。

老年代的管理策略与年轻代有着本质的不同。在年轻代，对象密度较低（大部分是垃圾），适合用复制算法快速清理。但在老年代，对象密度很高（大部分都存活），如果还用复制算法，就需要复制大量对象，效率很低。因此，老年代通常采用"标记-清除"或"标记-整理"算法，这些算法不需要大量复制对象，但执行时间较长。

老年代的GC事件，通常称为Major GC或Full GC（严格来说两者有细微差别，但在实际中常被混用），其特点是：频率低、耗时长、影响大。一次Full GC可能需要几秒甚至更长时间，在此期间应用程序会完全停顿。因此，性能调优的一个重要目标就是减少Full GC的频率。

对象进入老年代的条件：不只是年龄

很多人以为对象进入老年代只有一个条件：年龄达到阈值。实际上，JVM设计了多种机制来决定对象何时晋升，这些机制共同作用，确保内存的高效利用。让我们逐一分析：

1. 年龄达到晋升阈值（Age Threshold）

这是最常见的晋升方式。对象每经历一次Minor GC，年龄就加1。当年龄达到设定的阈值（默认15，可通过-XX:MaxTenuringThreshold调整），对象就会晋升到老年代。这个机制的逻辑很简单：一个对象如果经历了这么多次GC还没死，那它很可能是个长寿对象，应该放到老年代去。

2. 大对象直接分配（Large Object Direct Allocation）

某些特别大的对象（通常是大数组），会直接绕过年轻代，在创建时就被分配到老年代。这个设计的考虑是：大对象在年轻代会占用大量空间，而年轻代的复制算法需要复制存活对象，复制大对象的成本很高。与其在年轻代折腾，不如直接放到老年代。

这个"特别大"的阈值可以通过-XX:PretenureSizeThreshold参数设置。不过需要注意，这个参数只对Serial和ParNew收集器有效，对Parallel Scavenge无效。在实际应用中，应该尽量避免创建大对象，如果必须创建，也要考虑对象池等复用机制。

3. 动态年龄判定（Dynamic Age Determination）

这是一个很聪明的机制。JVM并不会死板地等待对象年龄达到15才晋升。如果在Survivor区中，相同年龄的所有对象大小的总和大于Survivor空间的一半，那么年龄大于或等于该年龄的对象就可以直接晋升到老年代，无需等到MaxTenuringThreshold设定的年龄。

为什么要这样设计？假设有一批对象都是在同一时刻创建的（比如处理一批请求），它们会一起在Survivor区中停留。如果这批对象的数量很大，占据了Survivor区的大半空间，那么继续让它们留在Survivor区就没有意义了，还不如早点让它们晋升，腾出Survivor区的空间给更年轻的对象。

4. 空间分配担保（Allocation Guarantee）

这是一种"应急"晋升机制。当发生Minor GC时，如果Survivor区空间不足以容纳所有存活对象，那些放不下的对象就会直接晋升到老年代，不管它们的年龄是多少。这种情况通常说明Survivor区设置得太小了，是一个需要关注的调优点。

老年代GC的特点：慢而重

老年代的垃圾回收与年轻代有着本质的不同，主要体现在以下几个方面：

首先是触发时机。老年代GC通常在老年代空间不足时触发，这可能是因为对象晋升导致的，也可能是直接在老年代分配大对象导致的。还有一种情况是，在Minor GC之前，JVM会做一个检查：如果预测这次Minor GC后需要晋升的对象大小大于老年代剩余空间，就会先触发一次Full GC。

其次是回收算法。老年代不能使用年轻代的复制算法，因为老年代中大部分对象都是存活的，复制的成本太高。老年代通常使用标记-清除或标记-整理算法，这些算法需要标记所有存活对象，然后清除或整理内存，过程比年轻代的GC复杂得多。

最后是性能影响。一次Full GC可能需要几百毫秒到几秒的时间，在此期间应用程序完全停顿（Stop The World）。对于在线服务来说，几秒的停顿意味着成百上千个请求超时，这是无法接受的。因此，性能调优的一个核心目标就是减少Full GC的频率，或者选用能够并发执行、停顿时间短的垃圾回收器。

1.3 方法区（元空间）：类信息的存储库

方法区是JVM规范中定义的一个逻辑概念，用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码缓存等数据。虽然规范称其为"方法区"，但它存储的内容远不止方法，更准确地说，它是类的元数据的存储区域。

方法区的重要性常常被忽视，但它在JVM中扮演着至关重要的角色。当我们编写一个Java类时，包含了类的结构信息：有哪些字段、哪些方法、类的继承关系、实现了哪些接口等等。这些信息在类加载时会被解析并存储到方法区中。可以说，方法区存储的是Java程序的"骨架"，而堆中存储的则是这个骨架的"血肉"（对象实例）。

从永久代到元空间：一次重要的演进

方法区的实现在JVM的演进过程中经历了一次重大变革，理解这次变革有助于我们更好地理解和调优JVM。

在JDK 7及以前的版本中，HotSpot虚拟机使用"永久代"（Permanent Generation，简称PermGen）来实现方法区。永久代使用的是JVM堆内存，这意味着永久代的大小受到堆内存的限制。这种实现带来了一些问题：

首先，永久代的大小很难估算。不同的应用加载的类的数量差异很大，框架多、使用反射多、动态代理多的应用可能需要很大的永久代空间。如果永久代设置得太小，容易发生"java.lang.OutOfMemoryError: PermGen space"错误；如果设置得太大，又会挤占堆内存空间。

其次，永久代的垃圾回收效率低。类的卸载条件非常苛刻，需要满足类的所有实例都被回收、类加载器被回收、Class对象没有被引用等条件。在实际应用中，类的卸载很少发生，这意味着永久代的空间基本上是"只增不减"的。

为了解决这些问题，从JDK 8开始，HotSpot虚拟机完全移除了永久代，改用"元空间"（Metaspace）来实现方法区。这是一次革命性的变化，主要体现在：

元空间使用的是本地内存（Native Memory），而不是JVM堆内存。这意味着元空间的大小不再受到-Xmx参数的限制，而是受到机器物理内存的限制。默认情况下，元空间可以动态扩展，理论上可以使用所有可用的系统内存（当然，这通常不是好事，所以还是应该设置上限）。

这个变化带来了几个好处：首先，不再需要精确估算方法区的大小，减少了OOM的风险。其次，堆内存的规划变得更简单，不需要在堆内存和永久代之间权衡。最后，元空间的垃圾回收更加高效，因为它与堆的GC独立进行。

但这个变化也带来了新的挑战：如果不设置元空间的上限，类加载过多或者发生类加载器泄漏时，可能会耗尽系统内存，影响整个机器的稳定性。因此，在生产环境中，通常建议显式设置-XX:MaxMetaspaceSize参数。

方法区存储内容：

方法区 ├── 类型信息（类名、父类、接口、修饰符等） ├── 方法信息（方法名、返回类型、参数、字节码等） ├── 字段信息（字段名、类型、修饰符） ├── 运行时常量池 │ ├── 字面量（字符串常量、final常量等） │ └── 符号引用（类、方法、字段的符号引用） └── 静态变量

1.4 虚拟机栈：方法执行的舞台

虚拟机栈是线程私有的内存区域，它的生命周期与线程相同。当创建一个新线程时，JVM会为这个线程分配一个虚拟机栈；当线程结束时，它的虚拟机栈也随之销毁。虚拟机栈描述的是Java方法执行的内存模型：每个方法在执行时都会创建一个栈帧（Stack Frame），用于存储该方法运行时需要的各种信息。

理解虚拟机栈对于理解Java程序的执行机制非常重要。当我们调用一个方法时，实际上是将一个新的栈帧压入栈顶；当方法执行完毕（无论是正常返回还是抛出异常），对应的栈帧就会从栈顶弹出。这种"后进先出"（LIFO）的结构天然地支持了方法调用的嵌套关系。

栈帧中存储了什么呢？主要包括局部变量表、操作数栈、动态链接和方法返回地址等信息。局部变量表存储了方法的参数和方法内定义的局部变量；操作数栈用于执行字节码指令时的操作数临时存储；动态链接用于将符号引用转换为直接引用；方法返回地址则记录了方法执行完成后要返回到哪里继续执行。

虚拟机栈的大小是有限的，如果线程请求的栈深度大于虚拟机所允许的深度，就会抛出StackOverflowError。这最常见于递归调用没有正确设置终止条件的情况。虚拟机栈也可以动态扩展，但如果扩展时无法申请到足够的内存，就会抛出OutOfMemoryError。

在性能调优时，虚拟机栈的大小通常不是关注的重点，除非应用程序有以下特点：使用了大量的递归、方法调用层次很深、或者创建了大量的线程。这时候就需要通过-Xss参数来调整每个线程的栈大小。

栈帧结构：

栈帧（Stack Frame） ├── 局部变量表 │ └── 存储方法参数和局部变量 ├── 操作数栈 │ └── 用于存放方法执行过程中产生的中间结果 ├── 动态链接 │ └── 指向运行时常量池中该栈帧所属方法的引用 ├── 方法返回地址 │ └── 方法正常退出或异常退出的定义 └── 附加信息

相关异常：

• StackOverflowError：线程请求的栈深度大于虚拟机所允许的深度（如递归调用过深）
• OutOfMemoryError：虚拟机栈动态扩展时无法申请到足够的内存

栈内存大小设置：

-Xss256k# 设置每个线程的栈大小为256KB

1.5 直接内存

直接内存不是JVM运行时数据区的一部分，但在NIO操作中被频繁使用。

特点：

• 通过DirectByteBuffer对象分配和管理
• 不受JVM堆内存限制，但受物理内存限制
• 避免了Java堆和Native堆之间的数据复制，提高性能
• 不会被垃圾回收直接管理，但通过Reference机制回收

参数设置：

-XX:MaxDirectMemorySize=512M# 设置直接内存最大值

1.6 对象的内存分配流程

理解对象的内存分配流程，对于性能调优至关重要：

对象创建 ↓ 是否为大对象？ ├─ 是 → 直接分配到老年代 └─ 否 → 尝试在Eden区分配 ↓ Eden区是否有足够空间？ ├─ 是 → 分配成功 └─ 否 → 触发Minor GC ↓ 清理Eden区和Survivor From区 ↓ 存活对象移到Survivor To区 ↓ 对象年龄+1 ↓ 年龄是否达到阈值？ ├─ 是 → 晋升到老年代 └─ 否 → 留在Survivor区 ↓ Survivor区是否放得下？ ├─ 是 → 分配成功 └─ 否 → 直接进入老年代 ↓ 老年代是否有空间？ ├─ 是 → 分配成功 └─ 否 → 触发Full GC ↓ GC后是否有空间？ ├─ 是 → 分配成功 └─ 否 → OutOfMemoryError

二、垃圾回收器原理与选择

2.1 垃圾回收算法基础

垃圾回收（Garbage Collection，GC）是JVM自动内存管理的核心机制。在Java中，程序员不需要手动释放内存（不像C/C++需要free或delete），这项工作由垃圾回收器自动完成。但"自动"不意味着"随意"，垃圾回收器遵循着一套精心设计的算法，这些算法决定了如何识别垃圾、何时回收垃圾、如何回收垃圾。

在深入了解各种垃圾回收器之前，我们需要先理解垃圾回收的基础算法。这些算法是所有垃圾回收器的理论基础，不同的回收器本质上是这些基础算法的不同组合和优化。掌握了这些基础算法，就能理解为什么不同的回收器适用于不同的场景，也能在遇到GC问题时更好地分析和解决。

2.1.1 标记-清除算法（Mark-Sweep）：最基础的回收算法

标记-清除算法是最基础、最早出现的垃圾回收算法，由John McCarthy在1960年发明，用于Lisp语言。虽然它有明显的缺点，但这个算法的思想影响深远，后续的很多算法都是在它的基础上改进而来。

这个算法的名字已经很好地描述了它的工作过程：分为"标记"和"清除"两个阶段。

标记阶段的深入理解

标记阶段的核心任务是找出所有仍然"存活"的对象。但是，JVM如何判断一个对象是否还存活呢？采用的是"可达性分析"算法。这个算法的基本思路是：从一系列称为"GC Roots"的对象开始，向下搜索，形成一个引用链。如果一个对象到GC Roots没有任何引用链相连（用图论的话说，就是从GC Roots到这个对象不可达），那么这个对象就是垃圾，可以被回收。

那么，哪些对象可以作为GC Roots呢？主要包括：虚拟机栈中引用的对象（方法的局部变量）、方法区中类静态属性引用的对象、方法区中常量引用的对象、本地方法栈中JNI引用的对象、以及JVM内部的引用等。这些对象被认为是"根对象"，从它们出发可以追踪到所有仍在使用的对象。

标记过程需要遍历整个对象图，这是一个相对耗时的过程。而且，为了保证标记的准确性，在标记期间必须暂停所有应用线程（Stop The World），否则对象的引用关系可能会在标记过程中发生变化，导致误判。

清除阶段的工作方式

标记完成后，所有对象就被分为了两类：被标记的（存活对象）和未被标记的（垃圾对象）。清除阶段的任务就是回收未被标记对象占用的内存。

需要注意的是，“清除"并不是真的将内存清零，而是将可回收对象所占用的内存加入到"空闲列表”（Free List）中。当后续需要分配内存时，就从空闲列表中寻找合适大小的空闲块。

算法的优缺点分析

标记-清除算法的优点是概念简单、实现相对容易。它不需要移动对象，这在某些场景下是有利的（比如对象移动会导致引用关系更新的开销）。

但它的缺点也很明显，主要有两个：

第一个缺点是效率问题。标记和清除两个过程的效率都不高，特别是当堆中对象很多时，需要标记和清除的对象数量巨大。而且这两个阶段都需要遍历整个内存空间。

第二个缺点，也是更致命的，是会产生大量的内存碎片。清除后，内存空间中会出现大量不连续的小块空闲空间。这些碎片化的空间很难被利用，可能会出现明明总的空闲内存足够，却无法分配一个稍大的对象的情况。内存碎片会导致不得不提前进行垃圾回收，甚至可能触发Full GC，严重影响性能。

正因为这些缺点，标记-清除算法通常不会单独使用，而是与其他算法组合使用。比如，CMS收集器就是基于标记-清除算法的，但它通过并发标记等技术来减少停顿时间，并定期进行内存整理来解决碎片问题。

示意图：

标记前： [对象A][对象B][对象C][对象D][对象E] ↓ ↓ ↓ ↓ ↓ 存活 垃圾 存活 垃圾 存活 标记后： [对象A][ ][对象C][ ][对象E] ✓ ✓ ✓ 清除后产生碎片，可能无法分配大对象

2.1.2 标记-复制算法（Mark-Copy）：为年轻代而生的算法

标记-复制算法（也常被简称为复制算法）是1969年由Fenichel提出的，它巧妙地解决了标记-清除算法的内存碎片问题。这个算法的核心思想是：将内存分为两块，每次只使用其中一块，GC时将存活对象复制到另一块区域，然后清空当前区域。

算法的工作机制

让我们详细看看这个算法是如何工作的。假设我们将内存分为A区和B区两块大小相等的区域。开始时，所有对象都分配在A区，B区保持空闲。当A区满了之后，触发垃圾回收：

首先，进行标记，找出A区中所有存活的对象。然后，不是就地清除垃圾，而是将这些存活对象按顺序复制到B区。复制完成后，A区中的所有内存（包括存活对象和垃圾对象）都可以一次性清空。下一次分配时，就在B区分配。当B区满了，再次GC时，就将B区的存活对象复制回A区，如此循环往复。

这个算法有个非常聪明的地方：复制时，存活对象是按顺序紧密排列的，自然就没有碎片。而且，清空内存区域时，不需要逐个回收对象，而是整块清空，效率极高。

内存分配的简化

复制算法还带来了一个额外的好处：简化了内存分配策略。在使用标记-清除算法时，内存中到处都是碎片，分配内存需要在空闲列表中搜索合适大小的空闲块，这个过程比较复杂。

而在复制算法中，由于所有对象都是紧密排列的，内存分配就变得非常简单，只需要使用一个指针记录已使用内存的边界，分配新对象时只需要将指针向前移动相应的大小即可。这种方式被称为"指针碰撞"（Bump the Pointer），速度非常快，几乎与在栈上分配内存一样快。

算法的适用场景

复制算法在理论上很完美，但它有一个显而易见的缺点：内存利用率只有50%。一半的内存永远处于空闲状态，这在内存资源宝贵的情况下是无法接受的。

但是，如果我们换个角度思考：在对象大量死亡、只有少量存活的场景下，复制算法就变得非常高效了。需要复制的对象很少，而且通过复制就自动解决了碎片问题。而且，实际上不需要将内存对半分——如果知道对象的存活率很低，就可以让使用区更大、空闲区更小。

这正是年轻代的特点！研究表明，年轻代中的对象有98%在第一次GC时就会死亡。既然绝大多数对象都会死亡，那么复制算法就是最合适的选择。

现代JVM正是基于这个观察，在年轻代采用了改进的复制算法。不是简单地把内存对半分，而是分为一个较大的Eden区和两个较小的Survivor区，比例为8:1:1。每次使用Eden区和其中一个Survivor区，GC时将存活对象复制到另一个Survivor区。这样，内存利用率就提高到了90%，只有10%的空间是空闲的。

而且，即使在极端情况下存活对象过多、Survivor区放不下，也有老年代作为"担保"，多出来的对象可以直接晋升到老年代。这个机制叫做"分配担保"（Handle Promotion），确保复制算法在任何情况下都能正常工作。

示意图：

GC前（使用From区）： From区: [A][B][C][D][E] To区: [空闲] GC后（复制存活对象到To区）： From区: [已清空] To区: [A][C][E] 下次GC时From和To互换

2.1.3 标记-整理算法（Mark-Compact）：老年代的最佳选择

标记-整理算法（也称标记-压缩算法）可以看作是标记-清除算法的改进版本。它保留了标记阶段，但将清除阶段改为整理阶段，从而解决了内存碎片问题，同时又避免了复制算法的内存浪费问题。

算法的工作流程

标记-整理算法的执行过程可以分为三个步骤：

第一步是标记阶段，与标记-清除算法完全相同，从GC Roots开始遍历对象图，标记所有可达的存活对象。

第二步是整理阶段，这是与标记-清除算法的关键区别。整理阶段会将所有存活对象向内存的一端移动，让它们紧密地排列在一起。这个过程类似于整理书架，把所有的书都挤到一边，让空闲空间集中到另一边。

第三步是清理阶段，直接清理掉边界外的所有内存。由于所有存活对象都被移到了一端，边界另一端的所有内存都是垃圾，可以一次性清理掉。

为什么需要移动对象？

你可能会问：移动对象不是很麻烦吗？需要更新所有指向这些对象的引用，这不是很耗时吗？确实，移动对象是有代价的，但这个代价是值得的。

首先，移动对象后，内存变得紧凑，没有任何碎片。这意味着后续的内存分配可以使用简单快速的指针碰撞方式，不需要维护复杂的空闲列表，也不需要搜索合适大小的空闲块。

其次，虽然移动对象需要更新引用，但现代JVM有很多技术来优化这个过程，比如使用句柄（Handle）、转发指针（Forwarding Pointer）等，使得引用更新的开销可以接受。

最重要的是，避免内存碎片带来的长期收益远大于移动对象的一次性开销。内存碎片会导致频繁GC、降低内存利用率、甚至引发OutOfMemoryError，这些问题的代价要比移动对象大得多。

老年代为什么选择标记-整理？

标记-整理算法特别适合老年代，原因在于老年代的对象特点：

首先，老年代中大部分对象都是长期存活的，对象的存活率很高（通常超过90%）。在这种情况下，如果使用复制算法，需要复制大量对象，而且需要预留同样大小的空间用于复制，内存利用率太低。使用标记-整理算法，虽然也需要移动对象，但不需要额外的空间，内存利用率高。

其次，老年代的GC频率较低。虽然标记-整理算法移动对象需要一定时间，但由于老年代GC不频繁，这个开销可以接受。相比之下，如果老年代使用标记-清除算法，产生的内存碎片会长期存在，持续影响性能。

最后，老年代的对象通常比较大。大对象对内存碎片更敏感，因为需要连续的大块空闲空间才能分配。使用标记-整理算法，确保了总有连续的大块空闲空间可用。

因此，大多数针对老年代的垃圾回收器，如Serial Old、Parallel Old、G1（在Mixed GC阶段）等，都采用了标记-整理算法或其变种。

示意图：

标记前： [A][B][C][D][E][F][G] ↓ ↓ ↓ ↓ ↓ ↓ ↓ 存活 死 存活 死 存活 死 存活 整理后： [A][C][E][G][ ] ↓ ↓ ↓ ↓ 清空 连续的存活对象 可用空间

2.2 垃圾回收器详解

2.2.1 Serial收集器

特点：

• 单线程收集器
• 进行GC时必须暂停所有工作线程（Stop The World）
• 简单高效，适合单CPU环境
• Client模式下默认的年轻代收集器

适用场景：

• 单核CPU或CPU核心数少的环境
• 桌面应用程序
• 堆内存较小的应用（几十MB到一两百MB）

启用参数：

-XX:+UseSerialGC# 年轻代和老年代都使用串行收集器

GC日志示例：

[GC (Allocation Failure) [DefNew: 4416K->512K(4928K), 0.0042640 secs] 4416K->1520K(15872K), 0.0043140 secs]

工作流程：

应用线程运行 ↓ 发生GC ↓ Stop The World（所有应用线程暂停） ↓ Serial收集器工作（单线程） ↓ GC完成 ↓ 恢复应用线程

2.2.2 Parallel收集器（吞吐量优先）

特点：

• 多线程并行收集
• 关注吞吐量（CPU用于运行用户代码的时间与CPU总消耗时间的比值）
• JDK 8默认的收集器
• 也称为"吞吐量优先"收集器

Parallel Scavenge（年轻代）：

• 使用复制算法
• 多线程并行收集
• 可控制吞吐量

Parallel Old（老年代）：

• 使用标记-整理算法
• 多线程并行收集

适用场景：

• 后台计算任务
• 不需要太多交互的任务
• 对吞吐量要求高，对停顿时间要求不严格

启用参数：

-XX:+UseParallelGC# 年轻代使用Parallel Scavenge-XX:+UseParallelOldGC# 老年代使用Parallel Old-XX:ParallelGCThreads=4# 设置并行GC线程数-XX:MaxGCPauseMillis=100# 设置最大GC停顿时间（毫秒）-XX:GCTimeRatio=99# 设置吞吐量大小（默认99，即1%的时间用于GC）-XX:+UseAdaptiveSizePolicy# 自动调节年轻代大小、Eden和Survivor比例等

性能对比：

假设堆内存1GB，4核CPU： Serial收集器： - GC线程：1个 - GC时间：100ms - 总停顿：100ms Parallel收集器： - GC线程：4个 - GC时间：30ms（理论值，实际约40ms） - 总停顿：40ms - 吞吐量提升约60%

2.2.3 CMS收集器（Concurrent Mark Sweep）

CMS是一款以获取最短停顿时间为目标的收集器，非常适合互联网应用和B/S架构的服务端应用。

特点：

• 并发收集、低停顿
• 基于标记-清除算法
• 只作用于老年代
• 大部分工作可以与应用线程并发执行

工作流程（四个阶段）：

1. 初始标记（Initial Mark）- STW

   • 仅标记GC Roots直接关联的对象
   • 速度很快，停顿时间短

2. 并发标记（Concurrent Mark）

   • 从GC Roots直接关联对象开始遍历整个对象图
   • 与应用线程并发执行
   • 耗时最长，但不需要停顿

3. 重新标记（Remark）- STW

   • 修正并发标记期间因用户程序继续运行而导致标记变动的对象
   • 停顿时间比初始标记稍长，但远比并发标记短

4. 并发清除（Concurrent Sweep）

   • 清除标记为垃圾的对象
   • 与应用线程并发执行

时间线示意：

时间 → |---初始标记(STW)---|======并发标记======|---重新标记(STW)---|======并发清除======| 应用停顿 应用继续运行 应用停顿 应用继续运行 (很短) (最耗时) (较短) (耗时)

启用参数：

-XX:+UseConcMarkSweepGC# 使用CMS收集器-XX:CMSInitiatingOccupancyFraction=70# 老年代使用70%时触发CMS（默认68%）-XX:+UseCMSInitiatingOccupancyOnly# 只使用设定的回收阈值-XX:ConcGCThreads=4# 并发GC线程数-XX:+CMSParallelRemarkEnabled# 降低重新标记停顿时间-XX:+CMSScavengeBeforeRemark# 重新标记前先进行一次年轻代GC-XX:+UseCMSCompactAtFullCollection# Full GC后进行碎片整理-XX:CMSFullGCsBeforeCompaction=5# 多少次Full GC后进行碎片整理

优点：

• 并发收集，停顿时间短
• 适合对响应时间敏感的应用
• 用户体验好

缺点：

1. 对CPU资源敏感

   • 并发阶段会占用部分CPU资源
   • 默认启动的回收线程数：(CPU核心数 + 3) / 4
   • 在CPU核心少时，影响应用性能

2. 无法处理"浮动垃圾"

   • 并发标记和并发清除阶段，用户线程仍在运行，会产生新的垃圾
   • 这部分垃圾只能等到下次GC清理
   • 需要预留足够内存给用户线程使用

3. 产生内存碎片

   • 基于标记-清除算法，会产生大量碎片
   • 可能导致老年代还有很多空间，但无法分配大对象
   • 不得不提前触发Full GC

适用场景：

• 互联网网站、B/S架构服务端
• 对响应时间要求高的应用
• 堆内存较大（4GB-20GB）
• 多核CPU服务器

2.2.4 G1收集器（Garbage First）：面向未来的垃圾回收器

G1（Garbage First）收集器是垃圾回收技术的一个里程碑。它从JDK 7开始引入，经过多年的优化和改进，在JDK 9中成为默认的垃圾回收器。G1的设计目标雄心勃勃：既要保证高吞吐量，又要实现可预测的低延迟，还要能够处理大堆内存（几十GB甚至上百GB）。这些目标在传统的垃圾回收器中往往是矛盾的，但G1通过一系列创新的设计，在很大程度上实现了这些目标的平衡。

G1的设计理念：全新的内存模型

G1最大的创新在于彻底改变了堆内存的布局方式。传统的垃圾回收器（如CMS）将堆内存划分为固定的年轻代和老年代，这两个区域在物理上是连续的。而G1引入了全新的Region（区域）概念，将整个堆内存划分为多个大小相等的独立区域。

每个Region的大小通常在1MB到32MB之间（必须是2的幂次），默认情况下，G1会将堆划分为约2048个Region。这些Region在逻辑上可以分为Eden区、Survivor区、Old区和Humongous区（用于存放大对象），但在物理上它们是不连续的，可以分散在堆的任何位置。

这种设计有什么好处呢？最大的好处是灵活性。在传统的分代收集器中，年轻代和老年代的大小比例是相对固定的，调整起来比较麻烦。而在G1中，一个Region可以灵活地在不同角色之间转换。今天它是Eden区，经过一次GC后可能变成空闲Region，下次可能被用作Old区。这种动态分配使得G1能够根据应用的实际情况自动调整各个代的大小。

可预测的停顿时间：G1的核心优势

G1最吸引人的特性是可以设置期望的GC停顿时间目标。通过-XX:MaxGCPauseMillis参数，你可以告诉G1：“我希望每次GC的停顿时间不超过200毫秒”。G1会尽力（注意，不是保证）达到这个目标。

G1是如何做到的呢？关键在于它可以选择性地回收Region。G1会跟踪每个Region中的垃圾比例，并估算回收每个Region所需的时间。在GC时，G1不会回收所有的Region，而是优先选择"收益最高"的Region进行回收——即那些垃圾比例高、回收时间短的Region。这就是"Garbage First"名字的由来：优先回收垃圾最多的区域。

通过这种机制，G1可以在有限的时间内（停顿时间目标）回收尽可能多的垃圾。如果停顿时间目标设置得比较紧，G1可能只回收几个Region；如果目标比较宽松，G1就可以回收更多Region，获得更高的回收效率。

G1的回收过程：年轻代GC与混合GC

G1的垃圾回收分为两种类型：年轻代GC（Young GC）和混合GC（Mixed GC）。

年轻代GC与传统收集器类似，当所有Eden Region被占满时触发。G1会回收所有的Eden Region和Survivor Region，将存活对象复制到新的Survivor Region或晋升到Old Region。年轻代GC是完全Stop The World的，但由于年轻代对象死亡率高，这个过程通常很快。

混合GC是G1独有的特性。当堆内存使用率达到一定阈值时（默认45%，可通过-XX:InitiatingHeapOccupancyPercent设置），G1会启动一个并发标记周期，标记整个堆中的存活对象。标记完成后，G1就知道了每个Region的垃圾比例。接下来的若干次GC，就不只是回收年轻代，还会选择一些垃圾比例高的Old Region一起回收，这就是混合GC。

混合GC的好处是可以渐进式地回收老年代，避免传统的Full GC那种"一次性回收所有老年代"的长时间停顿。通过多次混合GC，分批回收老年代，每次停顿时间都可控。

G1堆内存布局（每个格子代表一个Region）： [E][E][E][S][O][O][O][H] [E][E][S][O][O][O][H][O] [E][E][E][O][O][O][O][O] [E][S][O][O][O][H][O][O] E = Eden区 S = Survivor区 O = Old区（老年代） H = Humongous区（大对象，超过Region 50%的对象）

特点：

1. Region化内存布局

   • 不再区分年轻代和老年代的物理空间
   • 每个Region大小1MB-32MB（必须是2的幂次）
   • 大对象直接分配到Humongous区

2. 可预测的停顿时间

   • 可以设置期望停顿时间（-XX:MaxGCPauseMillis）
   • G1会根据历史数据预测每个Region的回收价值
   • 优先回收价值最大的Region

3. 并发与并行

   • 并行：多个GC线程同时工作（停顿期间）
   • 并发：GC线程与应用线程同时工作

工作流程：

1. 年轻代GC（Young GC）

   • 当Eden区用完时触发
   • 采用复制算法
   • 完全STW，但速度很快
   • 存活对象复制到Survivor或晋升到Old区

2. 混合GC（Mixed GC）

   • 当堆内存使用达到一定阈值时触发
   • 同时回收年轻代和部分老年代Region

3. Full GC

   • 当Mixed GC无法跟上内存分配速度时触发
   • 单线程执行，停顿时间长
   • 应尽量避免Full GC

G1 GC详细阶段：

1. 年轻代GC（Young GC）- STW - 清空Eden区 - 复制存活对象到Survivor或Old区 - 暂停时间可控 2. 并发标记周期（当老年代使用率达到阈值） a. 初始标记（Initial Mark）- STW - 标记GC Roots直接关联的对象 - 通常伴随Young GC一起进行 b. 根区域扫描（Root Region Scan） - 扫描Survivor区对老年代的引用 - 必须在下次Young GC前完成 c. 并发标记（Concurrent Mark） - 标记整个堆的存活对象 - 与应用线程并发执行 - 可被Young GC中断 d. 重新标记（Remark）- STW - 完成标记工作 - 使用SATB（Snapshot At The Beginning）算法 e. 清理（Cleanup）- 部分STW - 统计每个Region的存活对象 - 回收完全空闲的Region - 重置RSet（Remembered Set） 3. 混合GC（Mixed GC） - 选择收益最大的若干Region进行回收 - 包括所有年轻代Region和部分老年代Region

启用参数：

# 基础参数-XX:+UseG1GC# 使用G1收集器-XX:MaxGCPauseMillis=200# 设置期望的最大GC停顿时间（毫秒），默认200ms-XX:G1HeapRegionSize=16m# 设置Region大小，范围1MB-32MB# 并发标记相关-XX:InitiatingHeapOccupancyPercent=45# 堆使用率达到45%时启动并发标记，默认45-XX:ConcGCThreads=4# 并发GC线程数# Mixed GC相关-XX:G1MixedGCCountTarget=8# 一次并发标记后，最多执行8次Mixed GC-XX:G1OldCSetRegionThresholdPercent=10# Mixed GC时，老年代Region回收的最大比例-XX:G1MixedGCLiveThresholdPercent=85# Region中存活对象超过85%，不会被选入CSet# 大对象相关-XX:G1HeapWastePercent=5# 允许的浪费堆空间百分比，默认5%

性能调优建议：

1. 不要设置年轻代大小

   • G1会自动调整年轻代大小以满足停顿时间目标
   • 手动设置会影响G1的自适应能力

2. 合理设置停顿时间目标

   • 不要设置过小的值（如50ms），可能导致频繁GC
   • 推荐值：200ms-500ms
   • 设置过小可能导致达不到目标，反而降低吞吐量

3. 观察是否发生Full GC

   # 如果频繁Full GC，可以：- 增加堆内存 - 调整InitiatingHeapOccupancyPercent，提前触发并发标记 - 增加并发标记线程数

适用场景：

• 堆内存较大（6GB以上，推荐8GB-64GB）
• 需要可预测的停顿时间
• 服务端应用
• 替代CMS的首选方案

G1 vs CMS对比：

2.2.5 ZGC收集器（Z Garbage Collector）

ZGC是JDK 11引入的一款低延迟垃圾收集器，目标是让GC停顿时间不超过10ms。

特点：

• 停顿时间极短（<10ms）
• 支持TB级别的堆内存
• 吞吐量下降不超过15%
• 使用染色指针（Colored Pointer）和读屏障（Load Barrier）技术

核心技术：

1. 染色指针（Colored Pointer）

   • 在64位指针中存储对象的状态信息
   • 不需要额外的空间存储标记信息

2. 读屏障（Load Barrier）

   • 在对象访问时插入一小段代码
   • 实现并发移动对象

启用参数：

-XX:+UseZGC# 使用ZGC-XX:ZCollectionInterval=120# GC间隔时间（秒）-XX:ZAllocationSpikeTolerance=2# 内存分配尖峰容忍度

适用场景：

• 大内存服务器（16GB以上）
• 对延迟极度敏感的应用
• 金融交易系统
• 实时数据处理

局限性：

• 需要JDK 11+
• 目前只支持Linux x64平台（JDK 14开始支持Windows和macOS）
• 相比G1，吞吐量有所下降

2.3 如何选择垃圾回收器

选择合适的垃圾回收器需要考虑多个因素：

选择决策树： 应用类型？ ├─ 单核/桌面应用 │ └─ Serial / Serial Old │ ├─ 多核，对吞吐量要求高，可接受较长停顿 │ └─ Parallel Scavenge + Parallel Old │ ├─ 多核，对响应时间敏感，堆内存<8GB │ └─ CMS（ParNew + CMS） │ ├─ 多核，需要可预测停顿，堆内存6GB-64GB │ └─ G1 │ └─ 大内存，对延迟极度敏感，堆内存>16GB └─ ZGC

具体场景推荐：

JDK版本与默认收集器：

• JDK 8：Parallel Scavenge + Parallel Old
• JDK 9-13：G1
• JDK 14+：G1（推荐使用ZGC for低延迟场景）

三、JVM参数调优实战

3.1 JVM参数分类

JVM参数主要分为三类：

JVM参数分类 ├── 标准参数（-开头） │ ├── -version 查看JVM版本 │ ├── -help 查看帮助 │ ├── -cp/-classpath 设置类路径 │ └── 所有JVM都支持，稳定不变 │ ├── X参数（-X开头，非标准参数） │ ├── -Xms 初始堆大小 │ ├── -Xmx 最大堆大小 │ ├── -Xmn 年轻代大小 │ ├── -Xss 线程栈大小 │ └── 所有JVM都支持，但可能有差异 │ └── XX参数（-XX:开头，不稳定参数） ├── Boolean类型：-XX:+[参数名] 启用 │ -XX:-[参数名] 禁用 │ 示例：-XX:+UseG1GC │ └── KV类型：-XX:[参数名]=[值] 示例：-XX:MaxGCPauseMillis=200

3.2 堆内存参数详解

3.2.1 基础堆内存参数

# 堆内存大小设置-Xms4g# 初始堆大小4GB-Xmx4g# 最大堆大小4GB（建议与Xms相同，避免动态扩容）-Xmn1g# 年轻代大小1GB（一般为堆的1/3到1/4）# 为什么Xms和Xmx要设置相同？# 1. 避免运行时堆扩容，扩容会导致Full GC# 2. 减少内存碎片# 3. 性能更稳定可预测

内存大小单位：

k 或 K# KB (kilobytes)m 或 M# MB (megabytes)g 或 G# GB (gigabytes)# 示例-Xms512m# 512MB-Xmx4G# 4GB-Xmn1024m# 1GB

3.2.2 年轻代参数

# 方式1：直接指定年轻代大小-Xmn2g# 年轻代大小2GB# 方式2：通过比例设置（不推荐）-XX:NewRatio=2# 年轻代与老年代的比例 = 1:2# 即年轻代占堆的1/3# Eden和Survivor比例-XX:SurvivorRatio=8# Eden : Survivor0 : Survivor1 = 8:1:1# 默认值就是8# 示例：堆4GB，年轻代1GB，SurvivorRatio=8# 则内存分布为：# Eden: 800MB (1GB * 8/10)# S0: 100MB (1GB * 1/10)# S1: 100MB (1GB * 1/10)# Old: 3GB

年轻代大小如何设置？

# 经验法则：# 1. 年轻代一般设置为堆的1/4到1/3# 2. 年轻代太小：Minor GC频繁，对象过早进入老年代# 3. 年轻代太大：Minor GC时间长，老年代空间不足# 不同应用类型推荐：# 短生命周期对象多（Web应用）：年轻代可适当大一些（1/3）# 长生命周期对象多（缓存应用）：年轻代可适当小一些（1/4）

3.2.3 老年代参数

# 对象晋升年龄阈值-XX:MaxTenuringThreshold=15# 对象在Survivor区经过15次GC后晋升到老年代# 默认值：15（CMS为6）# 范围：0-15# 大对象直接进入老年代的阈值-XX:PretenureSizeThreshold=3m# 大于3MB的对象直接分配到老年代# 默认为0，即不设限制# 仅对Serial和ParNew有效# 晋升担保参数-XX:+HandlePromotionFailure# 允许担保失败（JDK 6 Update 24之后默认开启）

3.3 垃圾回收参数详解

3.3.1 通用GC参数

# GC日志参数（JDK 8）-XX:+PrintGC# 打印GC简要信息-XX:+PrintGCDetails# 打印GC详细信息-XX:+PrintGCTimeStamps# 打印GC时间戳（相对JVM启动时间）-XX:+PrintGCDateStamps# 打印GC日期时间戳-XX:+PrintHeapAtGC# GC前后打印堆信息-Xloggc:/path/to/gc.log# GC日志输出到文件# GC日志参数（JDK 9+，统一日志）-Xlog:gc# 基本GC日志-Xlog:gc*# 详细GC日志-Xlog:gc:file=/path/to/gc.log# 输出到文件-Xlog:gc*:file=/path/to/gc.log:time,uptime,level,tags# 完整格式# GC日志文件管理-XX:+UseGCLogFileRotation# 启用GC日志滚动-XX:NumberOfGCLogFiles=10# GC日志文件数量-XX:GCLogFileSize=100M# 每个GC日志文件大小# 其他有用参数-XX:+PrintGCApplicationStoppedTime# 打印应用停顿时间-XX:+PrintGCApplicationConcurrentTime# 打印应用运行时间-XX:+PrintTenuringDistribution# 打印对象年龄分布-XX:+PrintReferenceGC# 打印引用处理信息

3.3.2 Parallel收集器参数

# 启用Parallel收集器-XX:+UseParallelGC# 年轻代使用Parallel Scavenge-XX:+UseParallelOldGC# 老年代使用Parallel Old# JDK 8中设置其中一个，另一个自动启用# 并行GC线程数-XX:ParallelGCThreads=8# 设置并行GC线程数# 默认值：CPU核心数（核心数<=8）# 默认值：3 + (5 * CPU核心数 / 8)（核心数>8）# 性能目标设置-XX:MaxGCPauseMillis=200# 最大GC停顿时间目标（毫秒）# JVM会尝试调整堆大小和其他参数来达到目标# 不是硬性保证-XX:GCTimeRatio=99# 设置吞吐量大小# 公式：吞吐量 = 1 - 1/(1+GCTimeRatio)# 99表示：1%的时间用于GC，99%用于应用# 默认值：99# 自适应调节策略-XX:+UseAdaptiveSizePolicy# 启用自适应策略（默认开启）# JVM自动调整年轻代大小、Eden/Survivor比例、# 晋升阈值等参数以达到性能目标-XX:-UseAdaptiveSizePolicy# 禁用自适应策略# 示例：吞吐量优先配置（后台批处理）-Xms8g -Xmx8g -XX:+UseParallelGC -XX:ParallelGCThreads=8-XX:GCTimeRatio=99-XX:+UseAdaptiveSizePolicy

3.3.3 CMS收集器参数

# 启用CMS-XX:+UseConcMarkSweepGC# 老年代使用CMS-XX:+UseParNewGC# 年轻代使用ParNew（CMS自动启用）# 触发CMS GC的时机-XX:CMSInitiatingOccupancyFraction=70# 老年代使用70%时触发CMS# 默认：68%（JDK 6+）# 设置过高：可能来不及回收导致Concurrent Mode Failure# 设置过低：GC过于频繁，浪费CPU-XX:+UseCMSInitiatingOccupancyOnly# 只使用设定的阈值触发CMS# 不使用JVM的动态计算# 并发线程数-XX:ConcGCThreads=4# CMS并发线程数# 默认：(ParallelGCThreads + 3) / 4-XX:ParallelGCThreads=8# 并行GC线程数（用于STW阶段）# 优化重新标记阶段-XX:+CMSParallelRemarkEnabled# 启用并行重新标记（默认开启）-XX:+CMSScavengeBeforeRemark# 重新标记前先进行一次Minor GC# 减少年轻代对象对老年代的引用，缩短重新标记时间# 内存碎片处理-XX:+UseCMSCompactAtFullCollection# Full GC时进行碎片整理（默认开启）# 但整理会STW，时间较长-XX:CMSFullGCsBeforeCompaction=5# 多少次Full GC后进行一次碎片整理# 默认：0（每次Full GC都整理）# 设置为5：每5次Full GC后整理一次# 类卸载-XX:+CMSClassUnloadingEnabled# 允许CMS回收方法区（永久代/元空间）# JDK 8默认开启# 增量模式（已废弃，不推荐）-XX:+CMSIncrementalMode# CMS增量模式（JDK 9已移除）# 失败处理# 如果CMS运行期间无法满足内存分配需求，会出现"Concurrent Mode Failure"# 此时会退化为Serial Old进行Full GC，停顿时间很长# 解决方案：# 1. 降低CMSInitiatingOccupancyFraction，提前触发CMS# 2. 增加堆内存# 3. 优化代码，减少对象创建# 示例：低延迟配置（Web应用）-Xms6g -Xmx6g -Xmn2g -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70-XX:+UseCMSInitiatingOccupancyOnly -XX:+CMSScavengeBeforeRemark -XX:+CMSParallelRemarkEnabled -XX:ParallelGCThreads=8-XX:ConcGCThreads=2

3.3.4 G1收集器参数

# 启用G1-XX:+UseG1GC# 使用G1收集器（JDK 9+默认）# Region大小-XX:G1HeapRegionSize=16m# 设置Region大小（1MB-32MB，必须是2的幂）# 默认：堆大小 / 2048# 目标是有2048个Region# 停顿时间目标-XX:MaxGCPauseMillis=200# 期望的最大GC停顿时间（毫秒）# 默认：200ms# 这是一个软目标，不是硬性保证# 不要设置过小，否则降低吞吐量# 并发标记相关-XX:InitiatingHeapOccupancyPercent=45# 堆使用率达到45%时启动并发标记周期# 默认：45# IHOP越小，越早触发并发标记，越不容易Full GC-XX:ConcGCThreads=4# 并发标记的线程数# 默认：ParallelGCThreads / 4-XX:ParallelGCThreads=8# 并行GC线程数（STW阶段）# 默认：CPU核心数（核心<=8）# Mixed GC相关-XX:G1MixedGCCountTarget=8# 一次并发标记周期后，目标执行的Mixed GC次数# 默认：8# 增加此值可以减少每次Mixed GC的停顿时间-XX:G1HeapWastePercent=5# 允许的堆空间浪费百分比# 默认：5# 当可回收空间小于这个值时，不启动Mixed GC-XX:G1MixedGCLiveThresholdPercent=85# Region中存活对象超过85%，不会被选入CSet# 默认：85# 避免回收价值不高的Region-XX:G1OldCSetRegionThresholdPercent=10# Mixed GC时，老年代Region数量最大占比# 默认：10# 大对象相关-XX:G1ReservePercent=10# 保留的堆空间百分比，防止晋升失败# 默认：10# 记忆集（Remembered Set）相关-XX:G1RSetUpdatingPauseTimePercent=10# 允许用于更新RSet的停顿时间百分比# 默认：10# StringDeduplication（字符串去重）-XX:+UseStringDeduplication# 启用字符串去重-XX:StringDeduplicationAgeThreshold=3# 字符串达到此年龄后进行去重检查# 示例1：标准Web应用配置-Xms8g -Xmx8g -XX:+UseG1GC -XX:MaxGCPauseMillis=200-XX:InitiatingHeapOccupancyPercent=45-XX:ParallelGCThreads=8-XX:ConcGCThreads=2# 示例2：大堆内存配置（16GB+）-Xms16g -Xmx16g -XX:+UseG1GC -XX:G1HeapRegionSize=32m -XX:MaxGCPauseMillis=200-XX:InitiatingHeapOccupancyPercent=40-XX:G1ReservePercent=15# 示例3：低延迟配置-Xms8g -Xmx8g -XX:+UseG1GC -XX:MaxGCPauseMillis=100-XX:InitiatingHeapOccupancyPercent=35-XX:G1ReservePercent=15-XX:ParallelGCThreads=8-XX:ConcGCThreads=4

G1调优建议：

1. 不要手动设置年轻代大小（-Xmn、-XX:NewRatio）

   • G1会自动调整以满足停顿时间目标

2. 不要设置过于激进的停顿时间目标

   • 设置过小会频繁GC，降低吞吐量
   • 推荐200ms起步

3. 观察GC日志，关注Full GC

   • Full GC说明调优不当
   • 可以降低IHOP，提前触发并发标记

4. 大对象优化

   • 避免创建超过Region 50%的对象
   • 考虑拆分大对象

3.3.5 ZGC收集器参数

# 启用ZGC-XX:+UseZGC# 使用ZGC（需要JDK 11+）# 并发线程数-XX:ConcGCThreads=4# 并发GC线程数# 默认：CPU核心数 / 8# GC触发时机-XX:ZCollectionInterval=0# GC间隔时间（秒）# 默认：0（不基于时间触发）-XX:ZAllocationSpikeTolerance=2# 内存分配尖峰容忍度# 默认：2# 示例：ZGC配置（大内存、低延迟）-Xms32g -Xmx32g -XX:+UseZGC -XX:ConcGCThreads=8-Xlog:gc*:file=/path/to/gc.log

3.4 元空间参数

# 元空间大小（JDK 8+）-XX:MetaspaceSize=256m# 初始元空间大小# 默认：约21MB（平台相关）# 达到此值会触发Full GC-XX:MaxMetaspaceSize=512m# 最大元空间大小# 默认：无限制（只受系统内存限制）# 建议设置上限，防止内存泄漏-XX:MinMetaspaceFreeRatio=40# 最小空闲比例-XX:MaxMetaspaceFreeRatio=70# 最大空闲比例# 用于控制元空间的扩容和缩容# 永久代大小（JDK 7及以前）-XX:PermSize=256m# 初始永久代大小-XX:MaxPermSize=512m# 最大永久代大小

元空间调优建议：

# 问题：频繁Full GC，日志显示Metadata GC Threshold# 原因：元空间不足，频繁触发Full GC# 解决：增大MetaspaceSize# 典型配置-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m# 大型应用（Spring Boot、微服务）-XX:MetaspaceSize=512m -XX:MaxMetaspaceSize=1024m# 动态类加载多的应用（Groovy、反射多）-XX:MetaspaceSize=1g -XX:MaxMetaspaceSize=2g

3.5 线程栈参数

# 线程栈大小-Xss512k# 每个线程的栈大小为512KB# 默认：1MB（Linux/Windows）# 512KB（macOS）# 栈大小影响：# 1. 栈太小：StackOverflowError（递归调用深度受限）# 2. 栈太大：浪费内存，能创建的线程数变少# 线程数计算公式：# 最大线程数 ≈ (系统内存 - Xmx - MaxMetaspaceSize) / Xss

线程栈大小建议：

3.6 性能监控与诊断参数

# OOM时自动dump堆-XX:+HeapDumpOnOutOfMemoryError# OOM时自动生成堆转储文件-XX:HeapDumpPath=/path/to/dumps/# 堆转储文件保存路径# JMX监控-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9999-Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false# 启用JFR（Java Flight Recorder）-XX:+UnlockCommercialFeatures# JDK 8需要（JDK 11+不需要）-XX:+FlightRecorder -XX:StartFlightRecording=duration=60s,filename=/path/to/recording.jfr# 性能相关-XX:+AlwaysPreTouch# 启动时预先分配物理内存# 避免运行时因分配内存导致延迟# 适合对延迟敏感的应用-XX:+UseLargePages# 使用大页内存（需要系统支持）# 减少TLB miss，提升性能

3.7 实战场景参数配置

场景1：电商Web应用（4核8GB服务器）

# 特点：# - 高并发，对响应时间敏感# - 对象生命周期短# - 需要低延迟java -jar application.jar\-Xms4g\-Xmx4g\-Xmn1g\-Xss512k\-XX:MetaspaceSize=256m\-XX:MaxMetaspaceSize=512m\-XX:+UseG1GC\-XX:MaxGCPauseMillis=200\-XX:ParallelGCThreads=4\-XX:ConcGCThreads=1\-XX:InitiatingHeapOccupancyPercent=45\-XX:+HeapDumpOnOutOfMemoryError\-XX:HeapDumpPath=/logs/heapdump/\-Xlog:gc*:file=/logs/gc.log:time,uptime,level,tags

场景2：大数据处理应用（16核32GB服务器）

# 特点：# - 吞吐量优先# - 对停顿时间不敏感# - 批处理任务java -jar batch-processor.jar\-Xms28g\-Xmx28g\-Xmn8g\-Xss256k\-XX:MetaspaceSize=512m\-XX:MaxMetaspaceSize=1g\-XX:+UseParallelGC\-XX:ParallelGCThreads=16\-XX:GCTimeRatio=99\-XX:+UseAdaptiveSizePolicy\-XX:+HeapDumpOnOutOfMemoryError\-XX:HeapDumpPath=/logs/heapdump/\-Xlog:gc*:file=/logs/gc.log:time,level,tags

场景3：微服务应用（2核4GB容器）

# 特点：# - 资源受限# - 容器化部署# - 需要快速启动java -jar microservice.jar\-Xms2g\-Xmx2g\-Xss256k\-XX:MetaspaceSize=128m\-XX:MaxMetaspaceSize=256m\-XX:+UseG1GC\-XX:MaxGCPauseMillis=200\-XX:+UseContainerSupport\-XX:InitialRAMPercentage=50.0\-XX:MaxRAMPercentage=80.0\-XX:+HeapDumpOnOutOfMemoryError\-XX:HeapDumpPath=/logs/heapdump.hprof\-Xlog:gc:file=/logs/gc.log

场景4：金融交易系统（32核64GB服务器）

# 特点：# - 极低延迟要求（<10ms）# - 大内存# - 高并发java -jar trading-system.jar\-Xms48g\-Xmx48g\-Xss512k\-XX:MetaspaceSize=512m\-XX:MaxMetaspaceSize=1g\-XX:+UseZGC\-XX:ConcGCThreads=8\-XX:+AlwaysPreTouch\-XX:+UseLargePages\-XX:+HeapDumpOnOutOfMemoryError\-XX:HeapDumpPath=/logs/heapdump/\-Xlog:gc*:file=/logs/gc.log:time,uptime,level,tags

四、JVM监控工具详解

4.1 命令行工具：JVM问题排查的瑞士军刀

JDK自带了一套功能强大的命令行工具，它们是每个Java开发者和运维人员必须掌握的利器。这些工具虽然看起来不起眼，没有华丽的图形界面，但在实际的生产环境问题排查中，它们往往是最快速、最有效的选择。特别是在很多生产环境中，出于安全考虑，无法使用图形界面工具，这时候这些命令行工具就成了唯一的选择。

这些工具的另一个优势是轻量级。它们不需要在目标JVM中安装任何agent，不需要修改应用程序，只需要连接到目标进程就可以获取信息。这意味着你可以在不影响应用运行的情况下进行监控和诊断，这对生产环境来说至关重要。

让我们逐一了解这些工具，不仅要知道它们的基本用法，更要理解在什么场景下使用它们最合适，如何解读它们的输出信息，以及在实际问题排查中如何组合使用这些工具。

4.1.1 jps - 查看Java进程：问题排查的第一步

jps（Java Virtual Machine Process Status Tool）是JVM进程状态工具，它的作用类似于Linux的ps命令，但专门用于列出Java进程。这个工具看似简单，但却是所有JVM问题排查的第一步——你首先需要知道要排查哪个Java进程。

在生产环境中，可能同时运行着多个Java应用，比如多个微服务、多个后台任务等。jps可以帮助你快速定位到目标进程的PID，然后才能使用jstat、jmap等工具进行进一步的诊断。

# 基本用法jps# 显示Java进程ID和主类名jps -l# 显示完整的类名或jar路径jps -m# 显示传递给main方法的参数jps -v# 显示JVM参数# 输出示例$ jps -l12345com.example.Application12346org.apache.catalina.startup.Bootstrap12347org.elasticsearch.bootstrap.Elasticsearch $ jps -v12345Application -Xms4g -Xmx4g -XX:+UseG1GC

4.1.2 jstat - 查看JVM统计信息：性能监控的核心工具

jstat（JVM Statistics Monitoring Tool）是我个人认为JDK自带工具中最实用、使用频率最高的一个。它可以实时显示JVM的各种运行数据，包括类加载信息、垃圾收集统计、编译统计等，是性能分析和问题排查的核心工具。

jstat的强大之处在于它可以持续监控JVM的状态变化。与jmap等"一次性"工具不同，jstat可以按指定的时间间隔反复采集数据，让你看到JVM状态的动态变化。比如，你可以观察Eden区是如何逐渐被填满的，Minor GC的频率如何，老年代的使用率是否在持续上升等等。这些动态信息对于理解应用的运行特征、发现潜在问题至关重要。

在实际工作中，当接到"应用响应变慢"、"内存使用率高"等问题报告时，我通常第一时间就是用jstat查看GC情况。很多性能问题的根源都可以通过jstat快速定位：是频繁的Minor GC导致的吗？还是发生了Full GC？老年代使用率是否异常？这些问题的答案往往能指引后续的排查方向。

# 基本语法jstat -<option><pid><interval><count># option选项：# -gc 垃圾收集统计# -gcutil 垃圾收集统计（百分比）# -gccause 垃圾收集统计 + 最近GC原因# -gcnew 年轻代统计# -gcold 老年代统计# -class 类加载统计# -compiler JIT编译统计# 查看GC情况（每1秒输出一次，共10次）jstat -gc12345100010# 输出示例：S0C S1C S0U S1U EC EU OC OU MC MU YGC YGCT FGC FGCT GCT102401024010240819204567820480010240051200480001561.23450.5671.801# 字段说明：S0C: Survivor0容量(KB)S1C: Survivor1容量(KB)S0U: Survivor0使用量(KB)S1U: Survivor1使用量(KB)EC: Eden区容量(KB)EU: Eden区使用量(KB)OC: 老年代容量(KB)OU: 老年代使用量(KB)MC: 元空间容量(KB)MU: 元空间使用量(KB)YGC: Young GC次数 YGCT: Young GC总耗时(秒)FGC: Full GC次数 FGCT: Full GC总耗时(秒)GCT: 所有GC总耗时(秒)

更详细的统计（百分比）：

jstat -gcutil123451000# 输出示例：S0 S1 E O M CCS YGC YGCT FGC FGCT GCT10.00.055.850.093.788.21561.23450.5671.801# 字段说明：S0: Survivor0使用率(%)S1: Survivor1使用率(%)E: Eden区使用率(%)O: 老年代使用率(%)M: 元空间使用率(%)CCS: 压缩类空间使用率(%)YGC: Young GC次数 YGCT: Young GC总耗时(秒)FGC: Full GC次数 FGCT: Full GC总耗时(秒)GCT: 所有GC总耗时(秒)

查看GC原因：

jstat -gccause123451000# 输出示例：S0 S1 E O M CCS YGC YGCT FGC FGCT GCT LGCC GCC0.010.055.850.093.788.21571.24550.5671.812Allocation Failure No GC# LGCC: 最近一次GC的原因（Last GC Cause）# GCC: 当前GC的原因（Current GC Cause）

实战技巧：

# 1. 持续监控，输出到文件jstat -gcutil123451000>gc_monitor.log&# 2. 快速判断是否有Full GCjstat -gccause12345100010|grep-i"full"# 3. 监控老年代增长速度watch-n1'jstat -gc 12345 | tail -1'# 4. 计算GC频率和平均时间# Young GC平均时间 = YGCT / YGC# Full GC平均时间 = FGCT / FGC

4.1.3 jmap - 内存映像工具

jmap用于生成堆转储快照（heap dump）和查看内存信息。

# 1. 生成堆转储文件jmap -dump:format=b,file=/tmp/heap.hprof12345# live选项：只dump存活对象jmap -dump:live,format=b,file=/tmp/heap_live.hprof12345# 2. 查看堆内存使用情况jmap -heap12345# 输出示例：Attaching to process ID12345, please wait... Heap Configuration: MinHeapFreeRatio=40MaxHeapFreeRatio=70MaxHeapSize=4294967296(4096.0MB)NewSize=1073741824(1024.0MB)MaxNewSize=1073741824(1024.0MB)OldSize=3221225472(3072.0MB)NewRatio=2SurvivorRatio=8MetaspaceSize=268435456(256.0MB)MaxMetaspaceSize=536870912(512.0MB)G1HeapRegionSize=16777216(16.0MB)Heap Usage: G1 Heap: regions=256capacity=4294967296(4096.0MB)used=2147483648(2048.0MB)free=2147483648(2048.0MB)50.0% used# 3. 查看对象统计（按内存占用排序）jmap -histo12345|head-20# 输出示例：num#instances #bytes class name----------------------------------------------1:123456987654320[C2:98765456789012java.lang.String3:45678234567890byte[]4:1234598765432java.util.HashMap$Node# 4. 查看存活对象（触发Full GC）jmap -histo:live12345|head-20# 5. 查看类加载器统计jmap -clstats12345

实战场景：

# 场景1：分析内存泄漏# 1. 生成两个heap dump，间隔一段时间jmap -dump:live,format=b,file=/tmp/heap1.hprof12345# 等待10分钟jmap -dump:live,format=b,file=/tmp/heap2.hprof12345# 2. 使用MAT工具对比两个文件，找出持续增长的对象# 场景2：排查OOM# 当应用即将OOM时，手动dumpjmap -dump:format=b,file=/tmp/oom_heap.hprof12345# 场景3：快速查看内存占用最多的对象jmap -histo:live12345|head-20# 注意事项：# 1. jmap -dump会触发Full GC，生产环境慎用# 2. dump文件很大，确保有足够磁盘空间# 3. dump过程中应用会暂停（STW）

4.1.4 jstack - 线程堆栈工具

jstack用于生成线程快照（thread dump），分析线程状态、死锁等问题。

# 1. 生成线程dumpjstack12345>/tmp/thread_dump.txt# 2. 检测死锁jstack -l12345# 3. 强制dump（进程无响应时）jstack -F12345# 线程dump输出示例："http-nio-8080-exec-10"#123 daemon prio=5 os_prio=0 tid=0x00007f8b2c001000 nid=0x1a2b waiting on condition [0x00007f8abc123000]java.lang.Thread.State: WAITING(parking)at sun.misc.Unsafe.park(Native Method)at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)at com.example.Service.process(Service.java:123)# 线程状态说明：RUNNABLE: 运行中 BLOCKED: 阻塞（等待锁） WAITING: 等待（wait、park） TIMED_WAITING: 超时等待（sleep、wait with timeout） TERMINATED: 已终止

实战场景：

# 场景1：排查CPU 100%# 1. 找到进程IDjps -l# 2. 找到占用CPU高的线程top-H -p12345# 假设线程ID为 6827（十进制）# 3. 转换为十六进制printf"%x\n"6827# 输出：1aab# 4. 在thread dump中查找 nid=0x1aab 的线程jstack12345|grep-A20"nid=0x1aab"# 场景2：检测死锁jstack -l12345|grep-i"deadlock"-A20# 场景3：分析线程状态分布jstack12345|grep"java.lang.Thread.State"|sort|uniq-c# 输出示例：# 15 RUNNABLE# 120 WAITING# 10 TIMED_WAITING# 5 BLOCKED# 场景4：找出长时间等待的线程jstack12345|grep-A5"WAITING"

4.1.5 jinfo - 配置信息工具

# 1. 查看所有JVM参数jinfo12345# 2. 查看系统属性jinfo -sysprops12345# 3. 查看JVM flagsjinfo -flags12345# 输出示例：Non-default VM flags: -XX:ConcGCThreads=2-XX:G1HeapRegionSize=16777216-XX:InitialHeapSize=4294967296-XX:MaxHeapSize=4294967296-XX:+UseG1GC# 4. 查看特定参数值jinfo -flag MaxHeapSize12345# 输出：-XX:MaxHeapSize=4294967296# 5. 动态修改参数（仅支持manageable标记的参数）jinfo -flag +PrintGC12345# 开启GC日志jinfo -flag -PrintGC12345# 关闭GC日志jinfo -flagPrintGCDetails=true12345# 查看可动态修改的参数java -XX:+PrintFlagsFinal -version|grepmanageable

4.2 可视化工具

4.2.1 JConsole

JConsole是JDK自带的图形化监控工具，可以监控内存、线程、类、CPU等信息。

启动方式：

# 1. 直接启动（连接本地进程）jconsole# 2. 远程连接（需要配置JMX）jconsole<hostname>:9999# JMX配置：-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9999-Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false

主要功能：

1. 概述：CPU使用率、堆内存、线程数、类加载数
2. 内存：堆内存、非堆内存使用情况，可以手动执行GC
3. 线程：线程列表、线程状态、死锁检测
4. 类：已加载类数量、已卸载类数量
5. VM摘要：JVM参数、系统属性
6. MBean：查看和修改MBean属性

适用场景：

• 快速查看JVM运行状态
• 开发测试环境监控
• 简单的性能分析

4.2.2 VisualVM

VisualVM是功能更强大的可视化监控工具，支持插件扩展。

启动方式：

# JDK 8及以前自带jvisualvm# JDK 9+需要单独下载# https://visualvm.github.io/

主要功能：

1. 监视

   • CPU使用率
   • 堆内存、元空间使用情况
   • 类加载数量
   • 线程数量

2. 线程

   • 线程状态时间线
   • 死锁检测
   • 线程dump

3. 抽样器

   • CPU抽样：找出占用CPU最多的方法
   • 内存抽样：找出内存分配最多的类

4. Profiler（性能分析）

   • CPU profiling：方法级性能分析
   • 内存profiling：对象分配分析
   • 需要安装插件

5. 堆Dump分析

   • 加载heap dump文件
   • 对象实例查看
   • OQL查询（对象查询语言）
   • 计算保留大小

实战技巧：

# 1. 分析CPU热点# 监视 → Profiler → CPU → 运行应用 → 查看热点方法# 2. 分析内存分配# 监视 → Profiler → 内存 → 运行应用 → 查看分配最多的类# 3. 对比堆快照# 手动GC → 生成快照1 → 运行一段时间 → 手动GC → 生成快照2 → 对比# 4. OQL查询示例# 在heap dump中执行OQLselect* from java.lang.String s where s.value.length>1000selectheap.objects('java.util.HashMap')

推荐插件：

• VisualGC：可视化GC过程
• BTrace：动态跟踪
• TDA（Thread Dump Analyzer）：线程dump分析

4.2.3 JProfiler（商业工具）

JProfiler是功能最强大的Java性能分析工具，但需要商业授权。

主要功能：

1. 实时内存监控

   • 所有对象的内存占用
   • 垃圾回收活动
   • 内存泄漏检测

2. CPU分析

   • 调用树
   • 热点方法
   • 方法调用图

3. 线程分析

   • 线程状态时间线
   • 线程历史记录
   • 死锁检测

4. 数据库分析

   • JDBC调用
   • SQL语句
   • 数据库性能瓶颈

5. HTTP分析

   • URL调用统计
   • 响应时间分析

适用场景：

• 复杂的性能问题
• 生产级性能调优
• 需要详细分析报告

4.2.4 Arthas（阿里开源）

Arthas是阿里开源的Java诊断工具，无需修改代码即可诊断线上问题。

安装和启动：

# 1. 下载arthascurl-O https://arthas.aliyun.com/arthas-boot.jar# 2. 启动arthasjava -jar arthas-boot.jar# 3. 选择要诊断的Java进程# 会列出所有Java进程，输入编号即可# 4. 也可以直接指定PIDjava -jar arthas-boot.jar12345

常用命令：

# 1. dashboard - 实时数据面板dashboard# 显示：# - 线程信息# - 内存信息# - GC信息# - 运行环境信息# 2. thread - 查看线程信息thread# 查看所有线程thread1# 查看1号线程thread -n3# 查看CPU使用率最高的3个线程thread -b# 查找阻塞的线程（死锁）thread --state WAITING# 查看WAITING状态的线程# 3. jvm - 查看JVM信息jvm# 4. memory - 查看内存信息memory# 5. heapdump - 生成heap dumpheapdump /tmp/heap.hprof# 6. watch - 监控方法执行watchcom.example.Service process'{params, returnObj, throwExp}'-x2# 7. trace - 追踪方法调用链trace com.example.Service process# 输出示例：`---ts=2024-01-0110:00:00;thread_name=http-nio-8080-exec-1;id=1a;is_daemon=true;priority=5;`---[12.345ms]com.example.Service:process()+---[2.123ms]com.example.Repository:query()+---[8.456ms]com.example.Service:processData()`---[1.234ms]com.example.Service:saveResult()# 8. stack - 查看方法调用堆栈stack com.example.Service process# 9. tt - 时间隧道（记录方法调用）tt -t com.example.Service process# 开始记录tt -l# 查看记录列表tt -i1000-p# 重放索引为1000的调用# 10. monitor - 方法执行监控monitor -c5com.example.Service process# 每5秒统计一次：调用次数、成功次数、失败次数、平均耗时# 11. jad - 反编译jad com.example.Service# 12. sc - 查找类sc -d *Service*# 13. sm - 查找方法sm com.example.Service process*# 14. ognl - 执行OGNL表达式ognl'@com.example.Config@DEBUG_MODE'# 15. profiler - 性能采样（需要async-profiler支持）profiler start# 开始采样profiler status# 查看状态profiler stop# 停止并生成火焰图

实战场景：

# 场景1：快速定位慢接口trace com.example.Controller handleRequest -n1--skipJDKMethodfalse# 场景2：查看方法入参和返回值watchcom.example.Service process'{params[0], returnObj}'-x3-n5# 场景3：查找CPU占用高的线程thread -n5# 场景4：动态修改日志级别（通过OGNL）ognl'@com.example.Logger@setLevel("DEBUG")'# 场景5：查看Spring Beansc *Controller* vmtool --action getInstances --className org.springframework.context.ApplicationContext

4.3 生产环境监控方案

4.3.1 Prometheus + Grafana + JMX Exporter

架构：

Java应用（JMX Exporter） → Prometheus（采集和存储） → Grafana（可视化）

1. 配置JMX Exporter

# 下载jmx_prometheus_javaagentwgethttps://repo1.maven.org/maven2/io/prometheus/jmx/jmx_prometheus_javaagent/0.19.0/jmx_prometheus_javaagent-0.19.0.jar# 创建配置文件 jmx_exporter_config.ymlcat>jmx_exporter_config.yml<<EOF lowercaseOutputName: true lowercaseOutputLabelNames: true rules: - pattern: ".*" EOF# 启动Java应用时添加参数java -javaagent:./jmx_prometheus_javaagent-0.19.0.jar=8088:jmx_exporter_config.yml\-jar application.jar

2. 配置Prometheus

# prometheus.ymlglobal:scrape_interval:15sscrape_configs:-job_name:'java-app'static_configs:-targets:['localhost:8088']labels:application:'my-app'environment:'production'

3. Grafana Dashboard

导入Grafana模板：

• JVM (Micrometer)：Dashboard ID 4701
• JVM (JMX)：Dashboard ID 8563

监控指标：

# 堆内存使用率(jvm_memory_used_bytes{area="heap"}/ jvm_memory_max_bytes{area="heap"}) * 100# GC耗时rate(jvm_gc_pause_seconds_sum[5m])# GC频率rate(jvm_gc_pause_seconds_count[5m])# 线程数jvm_threads_live_threads# CPU使用率process_cpu_usage * 100

4.3.2 Micrometer + Spring Boot Actuator

1. 添加依赖

<dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-actuator</artifactId></dependency><dependency><groupId>io.micrometer</groupId><artifactId>micrometer-registry-prometheus</artifactId></dependency>

2. 配置application.yml

management:endpoints:web:exposure:include:health,info,metrics,prometheusmetrics:export:prometheus:enabled:truetags:application:${spring.application.name}environment:${spring.profiles.active}

3. 访问监控端点

# Prometheus格式的metricscurlhttp://localhost:8080/actuator/prometheus# JSON格式的metricscurlhttp://localhost:8080/actuator/metrics/jvm.memory.used

自定义监控指标：

@RestControllerpublicclassMetricsController{privatefinalCounterrequestCounter;privatefinalTimerrequestTimer;publicMetricsController(MeterRegistryregistry){this.requestCounter=Counter.builder("api.requests.total").description("Total API requests").tag("endpoint","/api/data").register(registry);this.requestTimer=Timer.builder("api.requests.duration").description("API request duration").tag("endpoint","/api/data").register(registry);}@GetMapping("/api/data")publicStringgetData(){requestCounter.increment();returnrequestTimer.record(()->{// 业务逻辑return"data";});}}

五、性能问题诊断与解决

5.1 内存溢出（OOM）问题：最常见也最棘手的问题

OutOfMemoryError（OOM）是Java应用中最常见、也最让人头疼的问题之一。当JVM无法再分配对象所需的内存，且垃圾回收器也无法回收出更多内存时，就会抛出OOM错误。OOM的出现通常意味着应用存在严重的内存问题，如果不及时解决，可能导致应用崩溃、服务不可用。

OOM问题的排查往往比较复杂，因为它可能发生在不同的内存区域，每种类型的OOM都有不同的原因和解决方案。作为一个有过多次OOM排查经验的人，我深知快速定位OOM原因的重要性。通常，生产环境的OOM问题都很紧急，需要在最短时间内找到根因并解决。因此，了解不同类型的OOM、掌握排查方法和工具，是每个Java开发者必备的技能。

让我们从最常见的堆内存溢出开始，逐一分析各种类型的OOM问题。

5.1.1 堆内存溢出（java.lang.OutOfMemoryError: Java heap space）

这是最常见的OOM类型，通常占所有OOM问题的80%以上。当看到"java.lang.OutOfMemoryError: Java heap space"这个错误时，意味着JVM堆内存空间不足，无法再分配新的对象。

深入理解堆内存溢出的本质

堆内存溢出的本质是：对象创建的速度超过了垃圾回收的速度，或者说需要的内存空间超过了可用的内存空间。但这个描述还是太笼统了，我们需要更细致地分析可能的原因。

第一种情况是内存真的不够用。这种情况下，应用确实需要更多的内存，可能是业务量增长了，需要处理的数据量变大了，或者堆内存的初始设置就偏小。这种情况的解决方案比较直接：增加堆内存。

第二种情况是内存泄漏。这是更常见、也更难排查的情况。所谓内存泄漏，是指程序中某些对象已经不再使用，但由于仍然被引用，导致垃圾回收器无法回收它们。随着时间推移，这些"僵尸对象"越积越多，最终耗尽了内存。内存泄漏是一种典型的"慢性病"，应用可能运行几小时甚至几天才会出现OOM，这使得问题的重现和排查都比较困难。

第三种情况是短时间内创建了大量对象。比如一次性从数据库查询了百万条记录，或者在循环中不断创建大对象。这种情况虽然不是严格意义上的泄漏，但会导致瞬时的内存压力，触发频繁的GC甚至OOM。

第四种情况是缓存使用不当。很多应用会使用缓存来提升性能，但如果缓存没有设置大小上限或过期策略，就会不断增长，最终导致OOM。我见过不少案例，开发者使用了HashMap或ArrayList作为缓存，忘记清理，随着运行时间增长，缓存中积累了大量数据，最终耗尽内存。

诊断步骤：

# 1. 配置OOM时自动dump-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/logs/heapdump/# 2. 使用MAT工具分析heap dump# 下载Eclipse MAT: https://www.eclipse.org/mat/# 3. 打开heap dump文件，查看：# - Leak Suspects：内存泄漏嫌疑点# - Dominator Tree：支配树（找出占用内存最多的对象）# - Histogram：对象实例统计# 4. 使用OQL查询# 示例：查找所有ArrayList实例select* from java.util.ArrayList# 示例：查找size大于1000的ArrayListselect* from java.util.ArrayList a where a.size>1000

解决方案：

// 方案1：增加堆内存-Xms8g-Xmx8g// 方案2：修复内存泄漏// 典型内存泄漏场景：// ❌ 错误示例1：静态集合持有大量对象publicclassCacheManager{privatestaticList<User>userCache=newArrayList<>();// 永不释放publicvoidaddUser(Useruser){userCache.add(user);// 对象永不被回收}}// ✅ 正确做法：使用弱引用或设置缓存上限publicclassCacheManager{privatestaticMap<String,WeakReference<User>>userCache=newWeakHashMap<>();// 或使用Guava Cache with过期策略privatestaticLoadingCache<String,User>cache=CacheBuilder.newBuilder().maximumSize(10000).expireAfterWrite(10,TimeUnit.MINUTES).build(newCacheLoader<String,User>(){publicUserload(Stringkey){returnloadUserFromDb(key);}});}// ❌ 错误示例2：资源未关闭publicvoidreadFile(Stringpath){BufferedReaderreader=newBufferedReader(newFileReader(path));// 如果抛出异常，reader永不关闭，导致内存泄漏Stringline=reader.readLine();}// ✅ 正确做法：使用try-with-resourcespublicvoidreadFile(Stringpath)throwsIOException{try(BufferedReaderreader=newBufferedReader(newFileReader(path))){Stringline=reader.readLine();}}// ❌ 错误示例3：大集合一次性加载publicList<Order>getAllOrders(){returnorderRepository.findAll();// 可能有百万条数据}// ✅ 正确做法：分页查询publicPage<Order>getOrders(intpage,intsize){returnorderRepository.findAll(PageRequest.of(page,size));}// 或使用流式查询@Query("SELECT o FROM Order o")Stream<Order>streamAll();try(Stream<Order>stream=orderRepository.streamAll()){stream.forEach(order->processOrder(order));}

5.1.2 元空间溢出（java.lang.OutOfMemoryError: Metaspace）

问题表现：

java.lang.OutOfMemoryError: Metaspace

原因分析：

1. 加载的类过多（动态代理、Groovy脚本等）
2. 类加载器泄漏
3. 元空间设置过小
4. CGLIB等字节码增强工具生成大量类

诊断步骤：

# 1. 查看元空间使用情况jstat -gc123451000# 2. 查看类加载情况jstat -class123451000# 输出：Loaded Bytes Unloaded Bytes Time50000100M10002M15.5# 3. dump内存并分析类加载器jmap -clstats12345# 4. 查看加载了哪些类jcmd12345GC.class_stats

解决方案：

# 方案1：增大元空间-XX:MetaspaceSize=512m -XX:MaxMetaspaceSize=1g# 方案2：启用类卸载-XX:+CMSClassUnloadingEnabled# CMS# G1默认启用类卸载# 方案3：减少动态类生成

// 典型场景：CGLIB代理导致类过多// ❌ 错误示例：每次都创建新的代理类publicObjectgetProxy(){Enhancerenhancer=newEnhancer();enhancer.setSuperclass(UserService.class);enhancer.setCallback(newMethodInterceptor(){publicObjectintercept(Objectobj,Methodmethod,Object[]args,MethodProxyproxy)throwsThrowable{returnproxy.invokeSuper(obj,args);}});returnenhancer.create();// 每次都生成新的类}// ✅ 正确做法：缓存代理类privatestaticfinalMap<Class<?>,Object>proxyCache=newConcurrentHashMap<>();publicObjectgetProxy(Class<?>clazz){returnproxyCache.computeIfAbsent(clazz,k->{Enhancerenhancer=newEnhancer();enhancer.setSuperclass(k);enhancer.setCallback(interceptor);returnenhancer.create();});}

5.1.3 直接内存溢出（java.lang.OutOfMemoryError: Direct buffer memory）

问题表现：

java.lang.OutOfMemoryError: Direct buffer memory

原因分析：

1. NIO使用DirectByteBuffer过多
2. Netty等框架使用直接内存
3. 直接内存设置过小

解决方案：

# 增大直接内存-XX:MaxDirectMemorySize=2g# 监控直接内存使用jconsole或VisualVM查看java.nio.BufferPool# 注意：# 直接内存不受-Xmx限制# 总内存使用 = 堆内存 + 元空间 + 直接内存 + 线程栈 + ...# 需要预留足够的系统内存

5.2 CPU 100%问题

诊断步骤：

# 1. 找到Java进程jps -l# 或psaux|grepjava# 2. 查看进程的线程CPU使用情况top-H -p12345# 记录CPU占用高的线程PID，例如：15623# 3. 将线程PID转换为十六进制printf"%x\n"15623# 输出：3d07# 4. 生成线程dumpjstack12345>/tmp/thread_dump.txt# 5. 在thread dump中搜索对应的nidgrep-A20"nid=0x3d07"/tmp/thread_dump.txt# 输出示例："business-thread-10"#123 daemon prio=5 tid=0x... nid=0x3d07 runnablejava.lang.Thread.State: RUNNABLE at com.example.Service.infiniteLoop(Service.java:100)at com.example.Controller.handle(Controller.java:50)# 6. 分析代码，定位问题

常见原因：

// 原因1：死循环publicvoidprocess(){while(true){// 忘记添加退出条件或sleepdoSomething();}}// 解决方案：publicvoidprocess(){while(!Thread.currentThread().isInterrupted()){try{doSomething();Thread.sleep(100);// 添加sleep，释放CPU}catch(InterruptedExceptione){Thread.currentThread().interrupt();break;}}}// 原因2：正则表达式回溯Stringtext="aaaaaaaaaaaaaaaaaaaaaaaaaaab";booleanmatches=text.matches("(a+)+b");// 灾难性回溯，CPU飙升// 解决方案：// 1. 使用更高效的正则booleanmatches=text.matches("a+b");// 2. 或使用find而不是matchesPatternpattern=Pattern.compile("(a+)+b");Matchermatcher=pattern.matcher(text);matcher.find();// 原因3：频繁GC（CPU被GC线程占用）// 查看GC情况jstat-gcutil123451000// 如果GC频繁，参考后面的"频繁Full GC"章节// 原因4：大量线程竞争// 使用jstack查看大量BLOCKED线程jstack12345|grep"java.lang.Thread.State"|sort|uniq-c// 50 BLOCKED// 100 WAITING// 解决方案：减少锁竞争，使用并发数据结构

使用Arthas快速定位：

# 启动arthasjava -jar arthas-boot.jar# 查看CPU占用最高的线程thread -n5# 直接查看热点方法profiler start# 运行一段时间profiler stop --format html --file /tmp/profile.html# 打开profile.html查看火焰图

5.3 频繁Full GC问题

诊断步骤：

# 1. 观察GC情况jstat -gcutil12345100010# 输出示例（频繁Full GC）：S0 S1 E O M CCS YGC YGCT FGC FGCT GCT0.095.210.598.796.595.3125012.4505025.67838.1280.096.815.399.196.595.3125212.4655226.89739.362# 观察到：老年代(O)使用率接近100%，Full GC频繁# 2. 查看GC日志tail-f gc.log|grep"Full GC"# 3. 分析GC原因jstat -gccause12345

常见原因和解决方案：

// 原因1：年轻代设置过小，对象过早进入老年代// 查看对象晋升情况// -XX:+PrintTenuringDistribution// 解决方案：-Xmn2g// 增大年轻代-XX:MaxTenuringThreshold=15// 增大晋升阈值// 原因2：大对象频繁创建// ❌ 错误示例：publicStringprocessData(){Stringresult="";for(inti=0;i<10000;i++){result+=data[i];// 每次都创建新String，产生大量对象}returnresult;}// ✅ 正确做法：publicStringprocessData(){StringBuildersb=newStringBuilder();for(inti=0;i<10000;i++){sb.append(data[i]);}returnsb.toString();}// 原因3：内存泄漏导致老年代不断增长// 使用jmap查看内存占用jmap-histo:live12345|head-20// 对比两次heap dumpjmap-dump:live,format=b,file=/tmp/heap1.hprof12345// 等待10分钟jmap-dump:live,format=b,file=/tmp/heap2.hprof12345// 使用MAT对比，找出持续增长的对象// 原因4：元空间不足触发Full GC// 查看元空间使用jstat-gc12345// MC和MU接近MaxMetaspaceSize// 解决方案：-XX:MetaspaceSize=512m-XX:MaxMetaspaceSize=1g// 原因5：显式调用System.gc()// 解决方案：-XX:+DisableExplicitGC// 禁用显式GC// 或者代码审查，去除System.gc()调用// 原因6：CMS的"Concurrent Mode Failure"// GC日志中出现：// [Full GC (Concurrent Mode Failure) ...]// 原因：CMS GC期间，老年代空间不足// 解决方案：-XX:CMSInitiatingOccupancyFraction=70// 降低阈值，提前触发CMS-Xms8g-Xmx8g// 增大堆内存

G1 Full GC问题：

# G1发生Full GC说明调优有问题# 常见原因：# 1. Humongous对象分配失败# 解决：增大Region或避免大对象-XX:G1HeapRegionSize=32m# 2. 并发标记跟不上内存分配速度# 解决：提前触发并发标记-XX:InitiatingHeapOccupancyPercent=40# 3. 晋升失败（to-space exhausted）# 解决：增加预留空间-XX:G1ReservePercent=15

5.4 内存泄漏检测

典型内存泄漏场景：

// 场景1：静态集合publicclassUserManager{privatestaticfinalMap<String,User>users=newHashMap<>();publicvoidregisterUser(Useruser){users.put(user.getId(),user);// 永不移除}// ✅ 解决方案：// 1. 添加移除方法// 2. 使用WeakHashMap// 3. 使用Guava Cache with过期策略}// 场景2：监听器未移除publicclassEventPublisher{privateList<EventListener>listeners=newArrayList<>();publicvoidaddListener(EventListenerlistener){listeners.add(listener);}// ❌ 忘记提供removeListener方法// ✅ 解决方案：publicvoidremoveListener(EventListenerlistener){listeners.remove(listener);}}// 场景3：ThreadLocal未清理publicclassRequestContext{privatestaticThreadLocal<User>currentUser=newThreadLocal<>();publicstaticvoidsetUser(Useruser){currentUser.set(user);// ❌ 使用后未清理，线程池复用线程时会导致泄漏}// ✅ 解决方案：publicstaticvoidclearUser(){currentUser.remove();}// 在finally块或Filter中清理try{RequestContext.setUser(user);// 处理请求}finally{RequestContext.clearUser();}}// 场景4：内部类持有外部类引用publicclassOuterClass{privatebyte[]largeArray=newbyte[10*1024*1024];// 10MBpublicInnerClassgetInnerClass(){returnnewInnerClass();// ❌ 内部类持有OuterClass引用}classInnerClass{// 即使只需要InnerClass，OuterClass的10MB也无法回收}// ✅ 解决方案：使用静态内部类staticclassInnerClass{// 不持有外部类引用}}// 场景5：资源未关闭publicvoidprocessFile(Stringpath)throwsIOException{FileInputStreamfis=newFileInputStream(path);// ❌ 如果抛出异常，流未关闭byte[]data=newbyte[fis.available()];fis.read(data);}// ✅ 解决方案：publicvoidprocessFile(Stringpath)throwsIOException{try(FileInputStreamfis=newFileInputStream(path)){byte[]data=newbyte[fis.available()];fis.read(data);}}

检测工具和方法：

# 方法1：对比两个时间点的heap dumpjmap -dump:live,format=b,file=heap1.hprof12345# 运行一段时间，执行相同操作jmap -dump:live,format=b,file=heap2.hprof12345# 使用MAT对比# 方法2：使用MAT的Leak Suspects报告# 1. 打开heap dump# 2. 点击"Leak Suspects"# 3. 查看报告，分析可疑对象# 方法3：使用MAT的Dominator Tree# 1. 打开heap dump# 2. 点击"Dominator Tree"# 3. 按Retained Heap排序# 4. 查看占用内存最多的对象# 方法4：使用VisualVM的OQL查询# 查找所有未关闭的文件流select* from java.io.FileInputStream# 查找大对象select* from instanceof java.lang.Object o where sizeof(o)>1000000# 方法5：使用JProfiler的内存泄漏检测# JProfiler → Memory → Recorded Objects# 选择类 → Mark Current Values# 运行一段时间# Remove Garbage# 查看仍然存在的对象

总结

本文从JVM内存模型、垃圾回收器原理、参数调优到监控工具和问题诊断，提供了一个完整的JVM性能调优指南。

核心要点回顾：

1. 理解内存模型：理解堆、栈、元空间的作用，是调优的基础
2. 选择合适的GC：根据应用特点选择合适的垃圾回收器
3. 合理设置参数：堆内存、GC参数、监控参数的合理配置
4. 持续监控：使用工具持续监控JVM运行状态
5. 问题诊断：掌握OOM、CPU高、频繁GC等问题的诊断方法

调优建议：

• 不要过早优化，先通过监控发现问题
• 每次只调整一个参数，观察效果
• 生产环境变更要谨慎，做好回滚准备
• 保留GC日志，便于问题排查
• 定期review内存使用情况