详解JVM 内存结构与实战调优总结

GC优化案例做个总结：

1在进行GC优化之前，需要确认项目的架构和代码等已经没有优化空间。我们不能指望一个系统架构有缺陷或者代码层次优化没有穷尽的应用，通过GC优化令其性能达到一个质的飞跃。
2其次，虚拟机内部已有很多优化来保证应用的稳定运行，所以不要为了调优而调优，不当的调优可能适得其反。
3最后，GC优化是一个系统而复杂的工作，没有万能的调优策略可以满足所有的性能指标。

GC优化必须建立在我们深入理解各种垃圾回收器的基础上，才能有事半功倍的效果。

一 JVM 内存结构

当代主流虚拟机（Hotspot VM）的垃圾回收都采用“分代回收”的算法。“分代回收”是基于这样一个事实：对象的生命周期不同，所以针对不同生命周期的对象可以采取不同的回收方式，以便提高回收效率。

Hotspot VM将内存划分为不同的物理区，就是“分代”思想的体现。

JVM内存主要由新生代、老年代、永久代构成。

① 新生代（Young Generation）：大多数对象在新生代中被创建，其中很多对象的生命周期很短。每次新生代的垃圾回收（又称Minor GC）后只有少量对象存活，所以选用复制算法，只需要少量的复制成本就可以完成回收。

新生代内又分三个区：一个Eden区，两个Survivor区（一般而言），大部分对象在Eden区中生成。当Eden区满时，还存活的对象将被复制到两个Survivor区（中的一个）。当这个Survivor区满时，此区的存活且不满足“晋升”条件的对象将被复制到另外一个Survivor区。对象每经历一次Minor GC，年龄加1，达到“晋升年龄阈值”后，被放到老年代，这个过程也称为“晋升”。显然，“晋升年龄阈值”的大小直接影响着对象在新生代中的停留时间，在Serial和ParNew GC两种回收器中，“晋升年龄阈值”通过参数MaxTenuringThreshold设定，默认值为15。

② 老年代（Old Generation）：在新生代中经历了N次垃圾回收后仍然存活的对象，就会被放到年老代，该区域中对象存活率高。老年代的垃圾回收（又称Major GC）通常使用“标记-清理”或“标记-整理”算法。整堆包括新生代和老年代的垃圾回收称为Full GC（HotSpot VM里，除了CMS之外，其它能收集老年代的GC都会同时收集整个GC堆，包括新生代）。
③ 永久代（Perm Generation）：主要存放元数据，例如Class、Method的元信息，与垃圾回收要回收的Java对象关系不大。相对于新生代和年老代来说，该区域的划分对垃圾回收影响比较小。

常见垃圾回收器

不同的垃圾回收器，适用于不同的场景。常用的垃圾回收器：

串行（Serial）回收器是单线程的一个回收器，简单、易实现、效率高。

并行（ParNew）回收器是Serial的多线程版，可以充分的利用CPU资源，减少回收的时间。

吞吐量优先（Parallel Scavenge）回收器，侧重于吞吐量的控制。

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

GC日志

每一种回收器的日志格式都是由其自身的实现决定的，换而言之，每种回收器的日志格式都可以不一样。但虚拟机设计者为了方便用户阅读，将各个回收器的日志都维持一定的共性。JavaGC日志中简单介绍了这些共性。

参数基本策略

各分区的大小对GC的性能影响很大。如何将各分区调整到合适的大小，分析活跃数据的大小是很好的切入点。

活跃数据的大小是指，应用程序稳定运行时长期存活对象在堆中占用的空间大小，也就是Full GC后堆中老年代占用空间的大小。可以通过GC日志中Full GC之后老年代数据大小得出，比较准确的方法是在程序稳定后，多次获取GC数据，通过取平均值的方式计算活跃数据的大小。

参数	倍数
总大小	3-4 倍活跃数据的大小
新生代	1-1.5 活跃数据的大小
老年代	2-3 倍活跃数据的大小
永久代	1.2-1.5 倍Full GC后的永久代空间占用

例如，根据GC日志获得老年代的活跃数据大小为300M，那么各分区大小可以设为：

总堆：1200MB = 300MB × 4* 新生代：450MB = 300MB × 1.5* 老年代： 750MB = 1200MB - 450MB*

这部分设置仅仅是堆大小的初始值，后面的优化中，可能会调整这些值，具体情况取决于应用程序的特性和需求。

二优化步骤

GC优化一般步骤可以概括为：确定目标、优化参数、验收结果。

确定目标

明确应用程序的系统需求是性能优化的基础，系统的需求是指应用程序运行时某方面的要求，譬如： - 高可用，可用性达到几个9。 - 低延迟，请求必须多少毫秒内完成响应。 - 高吞吐，每秒完成多少次事务。

明确系统需求之所以重要，是因为上述性能指标间可能冲突。比如通常情况下，缩小延迟的代价是降低吞吐量或者消耗更多的内存或者两者同时发生。

由于笔者所在团队主要关注高可用和低延迟两项指标，所以接下来分析，如何量化GC时间和频率对于响应时间和可用性的影响。通过这个量化指标，可以计算出当前GC情况对服务的影响，也能评估出GC优化后对响应时间的收益，这两点对于低延迟服务很重要。

举例：假设单位时间T内发生一次持续25ms的GC，接口平均响应时间为50ms，且请求均匀到达，根据下图所示：

那么有(50ms+25ms)/T比例的请求会受GC影响，其中GC前的50ms内到达的请求都会增加25ms，GC期间的25ms内到达的请求，会增加0-25ms不等，如果时间T内发生N次GC，受GC影响请求占比=(接口响应时间+GC时间)×N/T 。可见无论降低单次GC时间还是降低GC次数N都可以有效减少GC对响应时间的影响。

优化

通过收集GC信息，结合系统需求，确定优化方案，例如选用合适的GC回收器、重新设置内存比例、调整JVM参数等。

进行调整后，将不同的优化方案分别应用到多台机器上，然后比较这些机器上GC的性能差异，有针对性的做出选择，再通过不断的试验和观察，找到最合适的参数。

验收优化结果

将修改应用到所有服务器，判断优化结果是否符合预期，总结相关经验。

接下来，我们通过三个案例来实践以上的优化流程和基本原则（本文中三个案例使用的垃圾回收器均为ParNew+CMS，CMS失败时Serial Old替补)。

三 JVM调试工具

通过案例，我们知道要有一个更系统的调优方案，首先就要系统得了解调优工具。

3.1 jstat

jstat命令可以查看堆内存各部分的使用量，以及加载类的数量。命令的格式如下：

jstat [-命令选项] [vmid] [间隔时间/毫秒] [查询次数]

查看class加载统计

F:\t>jstat -class 12076

Loaded  Bytes  Unloaded  Bytes     Time

 5962 10814.2        0     0.0       3.75

查看编译统计

F:\t>jstat -compiler 12076

Compiled Failed Invalid   Time   FailedType FailedMethod

   3115      0       0     3.43          0

垃圾回收统计

F:\t>jstat -gc 12076

S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU

  CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT

3584.0 6656.0 3412.1  0.0   180224.0 89915.4   61440.0     5332.1   27904.0 2626

7.3 3840.0 3420.8      6    0.036   1      0.026    0.062

#也可以指定打印的间隔和次数，每1秒中打印一次，共打印5次

F:\t>jstat -gc 12076 1000 5

S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU

  CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT

3584.0 6656.0 3412.1  0.0   180224.0 89915.4   61440.0     5332.1   27904.0 2626

7.3 3840.0 3420.8      6    0.036   1      0.026    0.062

3584.0 6656.0 3412.1  0.0   180224.0 89915.4   61440.0     5332.1   27904.0 2626

7.3 3840.0 3420.8      6    0.036   1      0.026    0.062

3584.0 6656.0 3412.1  0.0   180224.0 89915.4   61440.0     5332.1   27904.0 2626

7.3 3840.0 3420.8      6    0.036   1      0.026    0.062

3584.0 6656.0 3412.1  0.0   180224.0 89915.4   61440.0     5332.1   27904.0 2626

7.3 3840.0 3420.8      6    0.036   1      0.026    0.062

3584.0 6656.0 3412.1  0.0   180224.0 89915.4   61440.0     5332.1   27904.0 2626

7.3 3840.0 3420.8      6    0.036   1      0.026    0.062

3.2 Jmap的使用以及内存溢出分析

前面通过jstat可以对jvm堆的内存进行统计分析，而jmap可以获取到更加详细的内容，如：内存使用情况的汇总、对内存溢出的定位与分析。

查看内存使用情况

[root@node01 ~]# jmap -heap 6219

Attaching to process ID 6219, please wait...

Debugger attached successfully.

Server compiler detected.

JVM version is 25.141-b15

using thread-local object allocation.

Parallel GC with 2 thread(s)

Heap Configuration: #堆内存配置信息

MinHeapFreeRatio         = 0

MaxHeapFreeRatio         = 100

MaxHeapSize              = 488636416 (466.0MB)

NewSize                  = 10485760 (10.0MB)

MaxNewSize               = 162529280 (155.0MB)

OldSize                  = 20971520 (20.0MB)

NewRatio                 = 2

SurvivorRatio            = 8

MetaspaceSize            = 21807104 (20.796875MB)

CompressedClassSpaceSize = 1073741824 (1024.0MB)

MaxMetaspaceSize         = 17592186044415 MB

G1HeapRegionSize         = 0 (0.0MB)

Heap Usage: # 堆内存的使用情况

PS Young Generation #年轻代

Eden Space:

capacity = 123731968 (118.0MB)

used     = 1384736 (1.320587158203125MB)

free     = 122347232 (116.67941284179688MB)

1.1191416594941737% used

From Space:

capacity = 9437184 (9.0MB)

used     = 0 (0.0MB)

free     = 9437184 (9.0MB)

0.0% used

To Space:

capacity = 9437184 (9.0MB)

used     = 0 (0.0MB)

free     = 9437184 (9.0MB)

0.0% used

PS Old Generation #年老代

capacity = 28311552 (27.0MB)

used     = 13698672 (13.064071655273438MB)

free     = 14612880 (13.935928344726562MB)

48.38545057508681% used

13648 interned Strings occupying 1866368 bytes.

查看内存中对象数量及大小

#查看所有对象，包括活跃以及非活跃的

jmap -histo <pid> | more

#查看活跃对象

jmap -histo:live <pid> | more

[root@node01 ~]# jmap -histo:live 6219 | more

num     #instances         #bytes  class name

----------------------------------------------1:         37437        7914608  [C

2:         34916         837984  java.lang.String

3:           884         654848  [B

4:         17188         550016  java.util.HashMap$Node

5:          3674         424968  java.lang.Class

6:          6322         395512  [Ljava.lang.Object;

7:          3738         328944  java.lang.reflect.Method

8:          1028         208048  [Ljava.util.HashMap$Node;

9:          2247         144264  [I

10:          4305         137760  java.util.concurrent.ConcurrentHashMap$Node

11:          1270         109080  [Ljava.lang.String;

12:            64          84128  [Ljava.util.concurrent.ConcurrentHashMap$Node;

13:          1714          82272  java.util.HashMap

14:          3285          70072  [Ljava.lang.Class;

15:          2888          69312  java.util.ArrayList

16:          3983          63728  java.lang.Object

17:          1271          61008  org.apache.tomcat.util.digester.CallMethodRule

18:          1518          60720  java.util.LinkedHashMap$Entry

19:          1671          53472  com.sun.org.apache.xerces.internal.xni.QName

20:            88          50880  [Ljava.util.WeakHashMap$Entry;

21:           618          49440  java.lang.reflect.Constructor

22:          1545          49440  java.util.Hashtable$Entry

23:          1027          41080  java.util.TreeMap$Entry

24:           846          40608  org.apache.tomcat.util.modeler.AttributeInfo

25:           142          38032  [S

26:           946          37840  java.lang.ref.SoftReference

27:           226          36816  [[C

。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

#对象说明

B  byte

C  char

D  double

F  float

I  int

J  long

Z  boolean

[  数组，如[I表示int[]

[L+类名 其他对象

将内存使用情况dump到文件中

#用法：

jmap -dump:format=b,file=dumpFileName <pid>

#示例

jmap -dump:format=b,file=/tmp/dump.dat 6219

可以看到已经在/tmp下生成了dump.dat的文件。

通过jhat对dump文件进行分析

在上一小节中，我们将jvm的内存dump到文件中，这个文件是一个二进制的文件，不方便查看，这时我们可以借助于jhat工具进行查看。

#用法：

jhat -port <port> <file>

#示例：

[root@node01 tmp]# jhat -port 9999 /tmp/dump.dat

Reading from /tmp/dump.dat...

Dump file created Mon Sep 10 01:04:21 CST 2018

Snapshot read, resolving...

Resolving 204094 objects...

Chasing references, expect 40 dots........................................

Eliminating duplicate references........................................

Snapshot resolved.

Started HTTP server on port 9999

Server is ready.

打开浏览器进行访问, 在最后由OQL查询功能.

3.3 Jmp使用以及内存溢出分析

使用MAT对内存溢出的定位与分析

内存溢出在实际的生产环境中经常会遇到，比如，不断地将数据写入到一个集合中，出现了死循环，读取超大的文件等等，都可能会造成内存溢出。

如果出现了内存溢出，首先我们需要定位到发生内存溢出的环节，并且进行分析，是正常还是非正常情况，如果是正常的需求，就应该考虑加大内存的设置，如果是非正常需求，那么就要对代码进行修改，修复这个bug。首先，我们得先学会如何定位问题，然后再进行分析。如何定位问题呢，我们需要借助于jmap与MAT工具进行定位分析。

接下来，我们模拟内存溢出的场景。

模拟内存溢出

编写代码，向List集合中添加100万个字符串，每个字符串由1000个UUID组成。如果程序能够正常执行，最后打印ok。

public class TestJvmOutOfMemory {

public static void main(String[] args) {

    List<Object> list = new ArrayList<>();

    for (int i = 0; i < 10000000; i++) {

            String str = "";

            for (int j = 0; j < 1000; j++) {

            str += UUID.randomUUID().toString();

            }

             list.add(str);

        }

    System.out.println("ok");

    }

}

为了演示效果，我们将设置执行的参数

#参数如下：

-Xms8m -Xmx8m -XX:+HeapDumpOnOutOfMemoryError

java.lang.OutOfMemoryError: Java heap space

Dumping heap to java_pid5348.hprof ...

Heap dump file created [8137186 bytes in 0.032 secs]

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space

at java.util.Arrays.copyOf(Arrays.java:3332)

at

java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)

at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:448)

at java.lang.StringBuilder.append(StringBuilder.java:136)

at cn.itcast.jvm.TestJvmOutOfMemory.main(TestJvmOutOfMemory.java:14)

Process finished with exit code 1

可以看到，当发生内存溢出时，会dump文件到java_pid5348.hprof。

导入到MA T工具中进行分析,

可以看到，有91.03%的内存由Object[]数组占有，所以比较可疑。

分析：这个可疑是正确的，因为已经有超过90%的内存都被它占有，这是非常有可能出现内存溢出的。

可以看到集合中存储了大量的uuid字符串

3.4 Jsatck的使用

有些时候我们需要查看下jvm中的线程执行情况，比如，发现服务器的CPU的负载突然增高了、出现了死锁、死循环等，我们该如何分析呢？

由于程序是正常运行的，没有任何的输出，从日志方面也看不出什么问题，所以就需要看下jvm的内部线程的执行情况，然后再进行分析查找出原因。

这个时候，就需要借助于jstack命令了，jstack的作用是将正在运行的jvm的线程情况进行快照，并且打印出来。

#用法：jstack <pid>

[root@node01 bin]# jstack 2203

3.5 VisualVM工具的使用

VisualVM，能够监控线程，内存情况，查看方法的CPU时间和内存中的对象，已被GC的对象，反向查看分配的堆栈(如100个String对象分别由哪几个对象分配出来的)。

VisualVM使用简单，几乎0配置，功能还是比较丰富的，几乎囊括了其它JDK自带命令的所有功能。

内存信息

线程信息

Dump堆（本地进程

Dump线程（本地进程）

打开堆Dump。堆Dump可以用jmap来生成

打开线程Dump

生成应用快照（包含内存信息、线程信息等等）

性能分析。CPU分析（各个方法调用时间，检查哪些方法耗时多），内存分析（各类对象占用的内存，检查哪些类占用内存多）

......

启动

在jdk的安装目录的bin目录下，找到jvisualvm.exe，双击打开即可。

查看 CPU、内存、类、线程运行信息

参看线程信息

也可以点击右上角Dump按钮，将线程的信息导出，其实就是执行的jstack命令。

监控远程JVM

VisualJVM不仅是可以监控本地jvm进程，还可以监控远程的jvm进程，需要借助于JMX技术实现。

什么是JMX

JMX（Java Management Extensions，即Java管理扩展）是一个为应用程序、设备、系统等植入管理功能的框架。JMX可以跨越一系列异构操作系统平台、系统体系结构和网络传输协议，灵活地开发无缝集成的系统、网络和服务管理应用。

监控Tomcat

想要监控远程的tomcat，就需要在远程的tomcat进行对JMX配置，

3.6 可视化GC日志分析工具

GC日志输出参数

前面通过-XX:+PrintGCDetails可以对GC日志进行打印，我们就可以在控制台查看，这样虽然可以查看GC的信息，但是并不直观，可以借助于第三方的GC日志分析工具进行查看。

在日志打印输出涉及到的参数如下：

-XX:+PrintGC 输出GC日志 

-XX:+PrintGCDetails 输出GC的详细日志 

-XX:+PrintGCTimeStamps 输出GC的时间戳（以基准时间的形式） 

-XX:+PrintGCDateStamps 输出GC的时间戳（以日期的形式，如 2013-05-04T21:53:59.234+0800） 

-XX:+PrintHeapAtGC 在进行GC的前后打印出堆的信息 

-Xloggc:../logs/gc.log 日志文件的输出路径

测试

-XX:+UseG1GC -XX:MaxGCPauseMillis=100 -Xmx256m -XX:+PrintGCDetails

-XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC

-Xloggc:F://test//gc.log

运行后就可以在E盘下生成gc.log文件。

使用GC Easy

它是一款在线的可视化工具，易用、功能强大，网站：http://gceasy.io/

四 CPU 占用过高排查实战

1、先通过 top 命令找到消耗 cpu 很高的进程 id

假设id 是 2022, top 命令是我们在 Linux 下最常用的命令之一，它可以实时显示正在执行进程的 CPU 使用率、内存使用率以及系统负载等信息。其中上半部分显示的是系统的统计信息，下半部分显示的是进程的使用率统计信息。

2、执行 top -p 2022 单独监控该进程
3、在第 2 步的监控界面输入 H，获取当前进程下的所有线程信息
4、找到消耗 cpu 特别高的线程编号，假设是 2734（要等待一阵）
5、执行 jstack 123456 对当前的进程做 dump，输出所有的线程信息
6、将第 4 步得到的线程编号 11354 转成 16 进制是 0x7b
7、根据第 6 步得到的 0x7b 在第 5 步的线程信息里面去找对应线程内容
8、解读线程信息，定位具体代码位置

发现找是 VM 的线程占用过高，我们发现我开启的参数中，有垃圾回收的日志显示，所以我们要换一个思路，可能是我们的业务线程没问题，而是垃圾回收的导致的。

jstat（代码中有打印 GC 参数，生产上可以使用这个 jstat –gc 来统计，达到类似的效果）：

是用于监视虚拟机各种运行状态信息的命令行工具。它可以显示本地或者远程虚拟机进程中的类装载、内存、垃圾收集、JIT 编译等运行数据，在没有 GUI图形界面，只提供了纯文本控制台环境的服务器上，它将是运行期定位虚拟机性能问题的首选工具。

假设需要每 250 毫秒查询一次进程 13616 垃圾收集状况，一共查询 10 次，那命令应当是：jstat-gc 13616 250010。

使用这个大量的 FullGC 了，并且还抛出了 OUT Of Memory。

怎么办？OOM 了. 我们可以看到，这个里面 CPU 占用过高是什么导致的？

是业务线程吗？不是的，这个是 GC 线程占用过高导致的。JVM 在疯狂的进行垃圾回收，JVM 中默认的垃圾回收器是多线程的，所以多线程在疯狂回收，导致 CPU 占用过高。

内存占用过高思路

用于生成堆转储快照（一般称为 heapdump 或 dump 文件）。jmap 的作用并不仅仅是为了获取 dump 文件，它还可以查询 finalize 执行队列、Java 堆和永久代的详细信息，如空间使用率、当前用的是哪种收集器等。和 jinfo 命令一样，jmap 有不少功能在Windows 平台下都是受限的，除了生成 dump 文件的-dump 选项和用于查看每个类的实例；

空间占用统计的-histo 选项在所有操作系统都提供之外。

把 JVM 中的对象全部打印出来，但是这样太多了，那么我们选择前 20 的对象展示出来，jmap –histo 1196 | head -20

定位问题的关键，就是这条命令。很多个 88 万个对象。

问题总结（找到问题）

一般来说，前面这几行，就可以看出，到底是哪些对象占用了内存。

这些对象回收不掉吗？是的，这些对象回收不掉，这些对象回收不掉，导致了 FullGC,里面还有 OutOfMemory。

任务数多于线程数，那么任务会进入阻塞队列，就是一个队列，你进去，排队，有机会了，你就上来跑。

但是，因为代码中任务数一直多于线程数，所以每 0.1S，就会有 50 个任务进入阻塞对象，50 个任务底下有对象，至少对象送进去了，但是没执行。所以导致对象一直都在，同时还回收不了。

为什么回收不了？因为Executor 是一个 GCroots。

所以堆中，就会有对象 80 万个，阻塞队列中 80 万个任务，futureTask。并且这些对象还回收不了。

小结

在 JVM 出现性能问题的时候。（表现上是 CPU100%，内存一直占用）

1、如果 CPU 的 100%，要从两个角度出发，一个有可能是业务线程疯狂运行，比如说想很多死循环。还有一种可能性，就是 GC 线程在疯狂的回收，因为 JVM 中垃圾回收器主流也是多线程的，所以很容易导致 CPU 的 100%

2、在遇到内存溢出的问题的时候，一般情况下我们要查看系统中哪些对象占用得比较多。在实际的业务代码中，找到对应的对象，分析对应的类，找到为什么这些对象不能回收的原因，就是可达性分析算法，JVM 的内存区域，还有垃圾回收器的基础。

四由亿级系统引起的思考：亿级流量电商系统 JVM 调优

根据淘宝的一个官方的数据分析,每天点击量在亿级的系统,用户一次浏览点击 20~40 次之间，推测出每日活跃用户（日活用户）在 500 万左右。

同时结合淘宝的一个点击数据，可以发现，能够付费的也就是橙色的部分（cart）的用户，比例只有 10%左右。

90%的用户仅仅是浏览，那么我们可以通过图片缓存、Redis 缓存等技术，我们可以把 90%的用户解决掉。

10%的付费用户，大概算出来是每日成交 50 万单左右。

GC 预估

如果是普通业务，一般处理时间比较平缓，大概在 3,4 个小时处理，算出来每秒只有几十单，这个一般的应用可以处理过来（不需要 JVM 预估调优）另外电商系统中有大促场景（秒杀、限时抢购等），一般这种业务是几种在几分钟。我们算出来大约每秒 2000 单左右的数据，承受大促场景的使用 4 台服务器（使用负载均衡）。每台订单服务器也就是大概 500 单/秒。

我们测试发现，每个订单处理过程中会占据 0.2MB 大小的空间（什么订单信息、优惠券、支付信息等等），那么一台服务器每秒产生 100M 的内存空间，这些对象基本上 1 秒后都会变成垃圾对象。

加入我们设置堆的空间最大值为 3 个 G，我们按照默认情况下的设置，新生代 1/3 的堆空间，老年代 2/3 的堆空间。Eden:S0:S1=8:1:1，我们推测出，old 区=2G,Eden 区=800M,S0=S1=100M。

根据对象的分配原则（对象优先在 Eden 区进行分配），由此可得，8 秒左右 Eden 区空间满了。

每 8 秒触发一个 MinorGC（新生代垃圾回收），这次 MinorGC 时，JVM 要 STW，但是这个时候有 100M 的对象是不能回收的（线程暂停，对象需要 1 秒后都会变成垃圾对象），那么就会有 100M 的对象在本次不能被回收（只有下次才能被回收掉）。

所以经过本次垃圾回收后。本次存活的 100M 对象会进入 S0 区，但是由于另外一个 JVM 对象分配原则（如果在 Survivor 空间中相同年龄所有对象大小的总和大于 Survivor 空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到 MaxTenuringThreshold 中要求的年龄）。

所以这样的对象本质上不会进去 Survivor 区，而是进入老年代。

所以我们推算，大概每个 8 秒会有 100M 的对象进入老年代。大概 20*8=160 秒，也就是 2 分 40 秒左右 old 区就会满掉，就会触发一次 FullGC,一般来说，这次 FullGC 是可以避免的，同时由于 FullGC 不单单回收老年代+新生代，还要回收元空间，这些 FullGC 的时间可能会比较长（老年代回收的朝生夕死的对象，使用标记清除/标记整理算法决定了效率并不高,同时元空间也要回收一次，进一步加大 GC 时间）。

所以问题的根本就是做到如何避免没有必要的 FullGC。

GC 预估调优

我们在项目中加入 VM 参数：

-Xms3072M -Xmx3072M -Xmn2048M -XX:SurvivorRatio=7

-Xss256K -XX:MetaspaceSize= 128M -XX:MaxMetaspaceSize= 128M

-XX:MaxTenuringThreshold=2

-XX:ParallelGCThreads=8

-XX:+UseConcMarkSweepGC

1、首先看一下堆空间：old 区=1G，Eden 区=1.4G,S0=S1=300M

2 、那么第一点，Eden 区大概需要 14 秒才能填满，填满之后，100M 的存活对象会进入 S0 区（由于这个区域变大，不会触发动态年龄判断）

3、再过 14 秒，Eden 区，填满之后，还是剩余 100M 的对象要进入 S1 区。但是由于原来的 100M 已经是垃圾了（过了 14 秒了），所以，S1 也只会有 Eden 区过来的 100M 对象，S0 的 100M 已经别回收，也不会触发动态年龄判断。

4、反反复复，这样就没有对象会进入 old 区，就不会触发 FullGC,同时我们的 MinorGC 的频次也由之前的 8 秒变为 14 秒，虽然空间加大，但是换来的还是 GC 的总时间会减少。

5、-Xss256K -XX:MetaspaceSize= 128M -XX:MaxMetaspaceSize= 128M

栈一般情况下很少用到 1M。所以为了线程占用内存更少，我们可以减少到 256K元空间一般启动后就不会有太多的变化，我们可以设定为 128M，节约内存空间。

6、-XX:MaxTenuringThreshold=2

这个是分代年龄（年龄为 2 就可以进入老年代），因为我们基本上都使用的是 Spring 架构，Spring 中很多的 bean 是长期要存活的，没有必要在 Survivor 区过渡太久，所以可以设定为 2，让大部分的 Spring 的内部的一些对象进入老年代。

7、-XX:ParallelGCThreads=8

线程数可以根据你的服务器资源情况来设定（要速度快的话可以设置大点，根据 CPU 的情况来定，一般设置成 CPU 的整数倍）。

8、-XX:+UseConcMarkSweepGC

因为这个业务响应时间优先的，所以还是可以使用 CMS 垃圾回收器或者 G1 垃圾回收器。

五案例一 Major GC和Minor GC频繁

确定目标

服务情况：Minor GC每分钟100次，Major GC每4分钟一次，单次Minor GC耗时25ms，单次Major GC耗时200ms，接口响应时间50ms。

由于这个服务要求低延时高可用，结合上文中提到的GC对服务响应时间的影响，计算可知由于Minor GC的发生，12.5%的请求响应时间会增加，其中8.3%的请求响应时间会增加25ms，可见当前GC情况对响应时间影响较大。

（50ms+25ms）× 100次/60000ms = 12.5%，50ms × 100次/60000ms = 8.3% 。

优化目标：降低TP99、TP90时间。

优化

首先优化Minor GC频繁问题。通常情况下，由于新生代空间较小，Eden区很快被填满，就会导致频繁Minor GC，因此可以通过增大新生代空间来降低Minor GC的频率。例如在相同的内存分配率的前提下，新生代中的Eden区增加一倍，Minor GC的次数就会减少一半。

这时很多人有这样的疑问，扩容Eden区虽然可以减少Minor GC的次数，但会增加单次Minor GC时间么？根据上面公式，如果单次Minor GC时间也增加，很难保证最后的优化效果。我们结合下面情况来分析，单次Minor GC时间主要受哪些因素影响？是否和新生代大小存在线性关系？首先，单次Minor GC时间由以下两部分组成：T1（扫描新生代）和 T2（复制存活对象到Survivor区）如下图。（注：这里为了简化问题，我们认为T1只扫描新生代判断对象是否存活的时间，其实该阶段还需要扫描部分老年代，后面案例中有详细描述。）

扩容前：新生代容量为R ，假设对象A的存活时间为750ms，Minor GC间隔500ms，那么本次Minor GC时间= T1（扫描新生代R）+T2（复制对象A到S）。

扩容后：新生代容量为2R ，对象A的生命周期为750ms，那么Minor GC间隔增加为1000ms，此时Minor GC对象A已不再存活，不需要把它复制到Survivor区，那么本次GC时间 = 2 × T1（扫描新生代R），没有T2复制时间。

可见，扩容后，Minor GC时增加了T1（扫描时间），但省去T2（复制对象）的时间，更重要的是对于虚拟机来说，复制对象的成本要远高于扫描成本，所以，单次Minor GC时间更多取决于GC后存活对象的数量，而非Eden区的大小。因此如果堆中短期对象很多，那么扩容新生代，单次Minor GC时间不会显著增加。下面需要确认下服务中对象的生命周期分布情况：

通过上图GC日志中两处红色框标记内容可知： 1. new threshold = 2（动态年龄判断，对象的晋升年龄阈值为2），对象仅经历2次Minor GC后就晋升到老年代，这样老年代会迅速被填满，直接导致了频繁的Major GC。 2. Major GC后老年代使用空间为300M+，意味着此时绝大多数(86% = 2G/2.3G)的对象已经不再存活，也就是说生命周期长的对象占比很小。

由此可见，服务中存在大量短期临时对象，扩容新生代空间后，Minor GC频率降低，对象在新生代得到充分回收，只有生命周期长的对象才进入老年代。这样老年代增速变慢，Major GC频率自然也会降低。

优化结果

通过扩容新生代为为原来的三倍，单次Minor GC时间增加小于5ms，频率下降了60%，服务响应时间TP90，TP99都下降了10ms+，服务可用性得到提升。

调整前：

调整后：

小结

如何选择各分区大小应该依赖应用程序中对象生命周期的分布情况：如果应用存在大量的短期对象，应该选择较大的年轻代；如果存在相对较多的持久对象，老年代应该适当增大。

JVM引入动态年龄计算，主要基于如下两点考虑：

1 如果固定按照MaxTenuringThreshold设定的阈值作为晋升条件： a）MaxTenuringThreshold设置的过大，原本应该晋升的对象一直停留在Survivor区，直到Survivor区溢出，一旦溢出发生，Eden+Svuvivor中对象将不再依据年龄全部提升到老年代，这样对象老化的机制就失效了。 b）MaxTenuringThreshold设置的过小，“过早晋升”即对象不能在新生代充分被回收，大量短期对象被晋升到老年代，老年代空间迅速增长，引起频繁的Major GC。分代回收失去了意义，严重影响GC性能。

2 相同应用在不同时间的表现不同：特殊任务的执行或者流量成分的变化，都会导致对象的生命周期分布发生波动，那么固定的阈值设定，因为无法动态适应变化，会造成和上面相同的问题。

总结来说，为了更好的适应不同程序的内存情况，虚拟机并不总是要求对象年龄必须达到Maxtenuringthreshhold再晋级老年代。

六案例二请求高峰期发生GC，导致服务可用性下降

确定目标

GC日志显示，高峰期CMS在重标记（Remark）阶段耗时1.39s。Remark阶段是Stop-The-World（以下简称为STW）的，即在执行垃圾回收时，Java应用程序中除了垃圾回收器线程之外其他所有线程都被挂起，意味着在此期间，用户正常工作的线程全部被暂停下来，这是低延时服务不能接受的。本次优化目标是降低Remark时间。

优化

解决问题前，先回顾一下CMS的四个主要阶段，以及各个阶段的工作内容。下图展示了CMS各个阶段可以标记的对象，用不同颜色区分。

1. Init-mark初始标记(STW) ，该阶段进行可达性分析，标记GC ROOT能直接关联到的对象，所以很快。
1. Concurrent-mark并发标记，由前阶段标记过的绿色对象出发，所有可到达的对象都在本阶段中标记。
1. Remark重标记(STW) ，暂停所有用户线程，重新扫描堆中的对象，进行可达性分析，标记活着的对象。因为并发标记阶段是和用户线程并发执行的过程，所以该过程中可能有用户线程修改某些活跃对象的字段，指向了一个未标记过的对象，如下图中红色对象在并发标记开始时不可达，但是并行期间引用发生变化，变为对象可达，这个阶段需要重新标记出此类对象，防止在下一阶段被清理掉，这个过程也是需要STW的。特别需要注意一点，这个阶段是以新生代中对象为根来判断对象是否存活的。
1. 并发清理，进行并发的垃圾清理。

可见，Remark阶段主要是通过扫描堆来判断对象是否存活。那么准确判断对象是否存活，需要扫描哪些对象？CMS对老年代做回收，Remark阶段仅扫描老年代是否可行？

结论是不可行，原因如下：

如果仅扫描老年代中对象，即以老年代中对象为根，判断对象是否存在引用，上图中，对象A因为引用存在新生代中，它在Remark阶段就不会被修正标记为可达，GC时会被错误回收。新生代对象持有老年代中对象的引用，这种情况称为“跨代引用”。因它的存在，Remark阶段必须扫描整个堆来判断对象是否存活，包括图中灰色的不可达对象。

灰色对象已经不可达，但仍然需要扫描的原因：新生代GC和老年代的GC是各自分开独立进行的，只有Minor GC时才会使用根搜索算法，标记新生代对象是否可达，也就是说虽然一些对象已经不可达，但在Minor GC发生前不会被标记为不可达，CMS也无法辨认哪些对象存活，只能全堆扫描（新生代+老年代）。由此可见堆中对象的数目影响了Remark阶段耗时。分析GC日志可以得出同样的规律，Remark耗时>500ms时，新生代使用率都在75%以上。这样降低Remark阶段耗时问题转换成如何减少新生代对象数量。

新生代中对象的特点是“朝生夕灭”，这样如果Remark前执行一次Minor GC，大部分对象就会被回收。CMS就采用了这样的方式，在Remark前增加了一个可中断的并发预清理（CMS-concurrent-abortable-preclean），该阶段主要工作仍然是并发标记对象是否存活，只是这个过程可被中断。此阶段在Eden区使用超过2M时启动，当然2M是默认的阈值，可以通过参数修改。如果此阶段执行时等到了Minor GC，那么上述灰色对象将被回收，Reamark阶段需要扫描的对象就少了。

除此之外CMS为了避免这个阶段没有等到Minor GC而陷入无限等待，提供了参数CMSMaxAbortablePrecleanTime ，默认为5s，含义是如果可中断的预清理执行超过5s，不管发没发生Minor GC，都会中止此阶段，进入Remark。根据GC日志红色标记2处显示，可中断的并发预清理执行了5.35s，超过了设置的5s被中断，期间没有等到Minor GC ，所以Remark时新生代中仍然有很多对象。

对于这种情况，CMS提供CMSScavengeBeforeRemark参数，用来保证Remark前强制进行一次Minor GC。

优化结果

经过增加CMSScavengeBeforeRemark参数，单次执行时间>200ms的GC停顿消失，从监控上观察，GCtime和业务波动保持一致，不再有明显的毛刺。

小结

通过案例分析了解到，由于跨代引用的存在，CMS在Remark阶段必须扫描整个堆，同时为了避免扫描时新生代有很多对象，增加了可中断的预清理阶段用来等待Minor GC的发生。只是该阶段有时间限制，如果超时等不到Minor GC，Remark时新生代仍然有很多对象，我们的调优策略是，通过参数强制Remark前进行一次Minor GC，从而降低Remark阶段的时间。

七案例三发生Stop-The-World的GC

确定目标

GC日志如下图（在GC日志中，Full GC是用来说明这次垃圾回收的停顿类型，代表STW类型的GC，并不特指老年代GC），根据GC日志可知本次Full GC耗时1.23s。这个在线服务同样要求低时延高可用。本次优化目标是降低单次STW回收停顿时间，提高可用性。

优化

首先，什么时候可能会触发STW的Full GC呢？ 1. Perm空间不足； 2. CMS GC时出现promotion failed和concurrent mode failure（concurrent mode failure发生的原因一般是CMS正在进行，但是由于老年代空间不足，需要尽快回收老年代里面的不再被使用的对象，这时停止所有的线程，同时终止CMS，直接进行Serial Old GC）； 3. 统计得到的Young GC晋升到老年代的平均大小大于老年代的剩余空间； 4. 主动触发Full GC（执行jmap -histo:live [pid]）来避免碎片问题。

然后，我们来逐一分析一下： - 排除原因2：如果是原因2中两种情况，日志中会有特殊标识，目前没有。 - 排除原因3：根据GC日志，当时老年代使用量仅为20%，也不存在大于2G的大对象产生。 - 排除原因4：因为当时没有相关命令执行。 - 锁定原因1：根据日志发现Full GC后，Perm区变大了，推断是由于永久代空间不足容量扩展导致的。

找到原因后解决方法有两种： 1. 通过把-XX:PermSize参数和-XX:MaxPermSize设置成一样，强制虚拟机在启动的时候就把永久代的容量固定下来，避免运行时自动扩容。 2. CMS默认情况下不会回收Perm区，通过参数CMSPermGenSweepingEnabled、CMSClassUnloadingEnabled ，可以让CMS在Perm区容量不足时对其回收。

由于该服务没有生成大量动态类，回收Perm区收益不大，所以我们采用方案1，启动时将Perm区大小固定，避免进行动态扩容。

优化结果

调整参数后，服务不再有Perm区扩容导致的STW GC发生。

小结

对于性能要求很高的服务，建议将MaxPermSize和MinPermSize设置成一致（JDK8开始，Perm区完全消失，转而使用元空间。而元空间是直接存在内存中，不在JVM中），Xms和Xmx也设置为相同，这样可以减少内存自动扩容和收缩带来的性能损失。虚拟机启动的时候就会把参数中所设定的内存全部化为私有，即使扩容前有一部分内存不会被用户代码用到，这部分内存在虚拟机中被标识为虚拟内存，也不会交给其他进程使用。

性能调优实战一：网站流量浏览量暴增后，网站反应页面响很慢

1、问题推测：

在测试环境测速度比较快，但是一到生产就变慢，所以推测可能是因为垃圾收集导致的业务线程停顿。

2、定位：

为了确认推测的正确性，在线上通过 jstat -gc 指令看到 JVM 进行 GC 次数频率非常高，GC 所占用的时间非常长，所以基本推断就是因为 GC 频率非常高，所以导致业务线程经常停顿，从而造成网页反应很慢。

3、解决方案：

因为网页访问量很高，所以对象创建速度非常快，导致堆内存容易填满从而频繁 GC，所以这里问题在于新生代内存太小，所以这里可以增加 JVM 内存就行了，所以初步从原来的 2G 内存增加到 16G 内存。

4、第二个问题：

增加内存后的确平常的请求比较快了，但是又出现了另外一个问题，就是不定期的会间断性的卡顿，而且单次卡顿的时间要比之前要长很多。

5、问题推测：

之前的优化加大了内存，所以推测可能是因为内存加大了，从而导致单次 GC 的时间变长从而导致间接性的卡顿。

6、定位

：还是通过 jstat -gc 指令查看到的确 FGC 次数并不是很高，但是花费在 FGC 上的时间是非常高的，根据 GC 日志查看到单次 FGC 的时间有达到几十秒的。

7、解决方案：

因为 JVM 默认使用的是 PS+PO 的组合，PS+PO 垃圾标记和收集阶段都是 STW，所以内存加大了之后，需要进行垃圾回收的时间就变长了，所以这里要想避免单次 GC 时间过长，所以需要更换并发类的收集器，因为当前的 JDK 版本为 1.7，所以最后选择 CMS 垃圾收集器，根据之前垃圾收集情况设置了一个预期的停顿的时间，上线后网站再也没有了卡顿问题。

性能调优实战二：后台系统导出数据操作引发的 OOM

问题描述：公司的后台系统，偶发性的引发 OOM 异常，堆内存溢出。

1、偶发还是频发。

因为是偶发性的，所以第一次简单的认为就是堆内存不足导致，所以单方面的加大了堆内存从 4G 调整到 8G。

2、查看堆内存

问题依然没有解决，只能从堆内存信息下手，通过开启了 -XX:+HeapDumpOnOutOfMemoryError 参数获得堆内存的 dump 文件。

3、查看线程信息

VisualVM 对堆 dump 文件进行分析，通过 VisualVM 查看到占用内存最大的对象是 String 对象，本来想跟踪着 String 对象找到其引用的地方，但 dump 文件太大，跟踪进去的时候总是卡死，而 String 对象占用比较多也比较正常，最开始也没有认定就是这里的问题，于是就从线程信息里面找突破点。

4、发现异常信息

通过线程进行分析，先找到了几个正在运行的业务线程，然后逐一跟进业务线程看了下代码，发现有个引起我注意的方法，导出订单信息。

5、查看异常信息

因为订单信息导出这个方法可能会有几万的数据量，首先要从数据库里面查询出来订单信息，然后把订单信息生成 excel，这个过程会产生大量的 String 对象。

6、发现：按钮可以一直点击

为了验证自己的猜想，于是准备登录后台去测试下，结果在测试的过程中发现导出订单的按钮前端居然没有做点击后按钮置灰交互事件，结果按钮可以一直点，因为导出订单数据本来就非常慢，使用的人员可能发现点击后很久后页面都没反应，结果就一直点，结果就大量的请求进入到后台，堆内存产生了大量的订单对象和 EXCEL 对象，而且方法执行非常慢，导致这一段时间内这些对象都无法被回收，所以最终导致内存溢出。

7、点击按钮后置灰

最终没有调整任何 JVM参数，只是在前端的导出订单按钮上加上了置灰状态，等后端响应之后按钮才可以进行点击，然后减少了查询订单信息的非必要字段来减少生成对象的体积，然后问题就解决了。

参考：美团技术团队