JVM调优和垃圾回收相关参数整理

末蓝、 2022-02-02 00:43 531阅读 0赞

## 一、内存调优 ##

#### `-Xms and -Xmx (or: -XX:InitialHeapSize and -XX:MaxHeapSize)` ####

`-Xms`和`-Xmx`可以说是最流行的JVM参数，它们可以允许我们指定JVM的初始和最大堆内存大小。一般来说，这两个参数的数值单位是Byte，但同时它们也支持使用速记符号，比如“k”或者“K”代表“kilo”，“m”或者“M”代表“mega”，“g”或者“G”代表“giga”。

推荐设置大小：3～4倍Full GC后的老年代空间占用量。

#### `-XX:+HeapDumpOnOutOfMemoryError and -XX:HeapDumpPath` ####

出现内存溢出时，通常来说，分析堆内存快照（`Heap dump`）是一个很好的定位手段，如果发生内存溢出时没有生成内存快照那就实在是太糟了，特别是对于那种JVM已经崩溃或者错误只出现在顺利运行了数小时甚至数天的生产系统上的情况。

幸运的是，我们可以通过设置`-XX:+HeapDumpOnOutOfMemoryError` 让JVM在发生内存溢出时自动的生成堆内存快照。有了这个参数，当我们不得不面对内存溢出异常的时候会节约大量的时间。默认情况下，堆内存快照会保存在JVM的启动目录下名为`java_pid<pid>.hprof` 的文件里（在这里就是JVM进程的进程号）。也可以通过设置`-XX:HeapDumpPath=<path>`来改变默认的堆内存快照生成路径，`<path>`可以是相对或者绝对路径。

虽然这一切听起来很不错，但有一点我们需要牢记。堆内存快照文件有可能很庞大，特别是当内存溢出错误发生的时候。因此，我们推荐将堆内存快照生成路径指定到一个拥有足够磁盘空间的地方。

#### `XX:OnOutOfMemoryError` ####

当内存溢发生时，我们甚至可以可以执行一些指令，比如发个E-mail通知管理员或者执行一些清理工作。通过`-XX:OnOutOfMemoryError` 这个参数我们可以做到这一点，这个参数可以接受一串指令和它们的参数。在这里，我们将不会深入它的细节，但我们提供了它的一个例子。在下面的例子中，当内存溢出错误发生的时候，我们会将堆内存快照写到`/tmp/heapdump.hprof` 文件并且在JVM的运行目录执行脚本`cleanup.sh`

$ java -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heapdump.hprof -XX:OnOutOfMemoryError ="sh ~/cleanup.sh" MyApp

#### `-XX:PermSize and -XX:MaxPermSize` ####

VM会加载很多类（因为它们依赖于大量的第三方库，而这又依赖于更多的库并且需要从里面将类加载进来）这就需要增加永久代的大小。我们可以使用-XX:PermSize 和-XX:MaxPermSize 来达到这个目的。

#### `-XX:InitialCodeCacheSize and -XX:ReservedCodeCacheSize` ####

JVM一个有趣的，但往往被忽视的内存区域是“代码缓存”，它是用来存储已编译方法生成的本地代码。代码缓存确实很少引起性能问题，但是一旦发生其影响可能是毁灭性的。如果代码缓存被占满，JVM会打印出一条警告消息，并切换到`interpreted-only`模式：JIT编译器被停用，字节码将不再会被编译成机器码。因此，应用程序将继续运行，但运行速度会降低一个数量级，直到有人注意到这个问题。

#### `-XX:+UseCodeCacheFlushing` ####

如果代码缓存不断增长，例如，因为热部署引起的内存泄漏，那么提高代码的缓存大小只会延缓其发生溢出。为了避免这种情况的发生，我们可以尝试一个有趣的新参数：当代码缓存被填满时让JVM放弃一些编译代码。通过使用`-XX:+UseCodeCacheFlushing` 这个参数，我们至少可以避免当代码缓存被填满的时候JVM切换到`interpreted-only` 模式。不过，我仍建议尽快解决代码缓存问题发生的根本原因，如找出内存泄漏并修复它。

--------------------

## 二、新生代垃圾回收 ##

单纯从JVM的功能考虑，并不需要新生代，完全可以针对整个堆进行操作。新生代存在的唯一理由是优化垃圾回收(GC)的性能。更具体说，把堆划分为新生代和老年代有2个好处：简化了新对象的分配(只在新生代分配内存),可以更有效的清除不再需要的对象(即死对象)(新生代和老年代使用不同的GC算法)。

HotSpot JVM 又把新生代进一步划分为3个区域：一个相对大点的区域，称为”`伊甸园区(Eden)`”；两个相对小点的区域称为”`From 幸存区(survivor)`”和”`To 幸存区(survivor)`”。按照规定,新对象会首先分配在 Eden 中(如果新对象过大，会直接分配在老年代中)。在GC中，Eden 中的对象会被移动到survivor中，直至对象满足一定的年纪(定义为熬过GC的次数),会被移动到老年代。

总结一下，对象一般出生在Eden区，年轻代GC过程中，对象在2个幸存区之间移动，如果对象存活到适当的年龄，会被移动到老年代。当对象在老年代死亡时，就需要更高级别的GC，更重量级的GC算法(复制算法不适用于老年代，因为没有多余的空间用于复制)。

#### `-XX:NewSize and -XX:MaxNewSize` ####

就像可以通过参数`(-Xms and -Xmx)` 指定堆大小一样，可以通过参数指定新生代大小。设置 `XX:MaxNewSize` 参数时，应该考虑到新生代只是整个堆的一部分，新生代设置的越大，老年代区域就会减少。一般不允许新生代比老年代还大，因为要考虑GC时最坏情况，所有对象都晋升到老年代。 `-XX:MaxNewSize` 最大可以设置为`-Xmx/2` .

#### `-XX:NewRatio` ####

可以设置新生代和老年代的相对大小。这种方式的优点是新生代大小会随着整个堆大小动态扩展。参数 `-XX:NewRatio` 设置老年代与新生代的比例。例如 `-XX:NewRatio=3` 指定老年代/新生代为3/1. 老年代占堆大小的 3/4 ，新生代占 1/4 .

#### `-XX:SurvivorRatio` ####

参数 `-XX:SurvivorRatio 与 -XX:NewRatio` 类似，作用于新生代内部区域。`-XX:SurvivorRatio` 指定伊甸园区(Eden)与幸存区大小比例. 例如, `-XX:SurvivorRatio=10` 表示伊甸园区(Eden)是 幸存区To 大小的10倍(也是幸存区From的10倍).所以,伊甸园区(Eden)占新生代大小的10/12, 幸存区From和幸存区To 每个占新生代的1/12 .注意,两个幸存区永远是一样大的…

#### `-XX:+PrintTenuringDistribution` ####

参数 `-XX:+PrintTenuringDistribution` 指定JVM 在每次新生代GC时，输出幸存区中对象的年龄分布。例如:

Desired survivor size 75497472 bytes, new threshold 15 (max 15)
    - age 1: 19321624 bytes, 19321624 total
    - age 2: 79376 bytes, 19401000 total
    - age 3: 2904256 bytes, 22305256 total

第一行说明幸存区To大小为 75 MB. 也有关于老年代阀值(tenuring threshold)的信息, 老年代阀值，意思是对象从新生代移动到老年代之前，经过几次GC(即, 对象晋升前的最大年龄). 上例中,老年代阀值为15,最大也是15。  
之后行表示，对于小于老年代阀值的每一个对象年龄,本年龄中对象所占字节 (如果当前年龄没有对象,这一行会忽略). 上例中,一次 GC 后幸存对象大约 19 MB, 两次GC 后幸存对象大约79 KB , 三次GC 后幸存对象大约 3 MB .每行结尾，显示直到本年龄全部对象大小.所以,最后一行的 total 表示幸存区To 总共被占用22 MB . 幸存区To 总大小为 75 MB ,当前老年代阀值为15，可以断定在本次GC中，没有对象会移动到老年代。

**`TIP:`适当的配置新生代非常重要，有相当多的参数可以设置新生代。然而，单独调整新生代，而不考虑老年代是不可能优化成功的。当调整堆和GC设置时，我们总是应该同时考虑新生代和老年代。**

--------------------

## 三、吞吐量收集器 ##

在实践中我们发现对于大多数的应用领域，评估一个垃圾收集(GC)算法如何根据如下两个标准：吞吐量越高算法越好、暂停时间越短算法越好

首先让我们来明确垃圾收集(GC)中的两个术语:吞吐量(`throughput`)和暂停时间(`pause times`)。 JVM在专门的线程(GC threads)中执行GC。 只要GC线程是活动的，它们将与应用程序线程(application threads)争用当前可用CPU的时钟周期。 简单点来说，吞吐量是指应用程序线程用时占程序总用时的比例。 例如，吞吐量99/100意味着100秒的程序执行时间应用程序线程运行了99秒， 而在这一时间段内GC线程只运行了1秒。

术语”暂停时间”是指一个时间段内应用程序线程让与GC线程执行而完全暂停。 例如，GC期间100毫秒的暂停时间意味着在这100毫秒期间内没有应用程序线程是活动的。 如果说一个正在运行的应用程序有100毫秒的“平均暂停时间”，那么就是说该应用程序所有的暂停时间平均长度为100毫秒。 同样，100毫秒的“最大暂停时间”是指该应用程序所有的暂停时间最大不超过100毫秒。

现在让我们来看看跟面向吞吐量垃圾收集算法有关的重要JVM配置参数。

#### `-XX:+UseSerialGC` ####

我们使用该标志来激活串行垃圾收集器，例如单线程面向吞吐量垃圾收集器。 无论年轻代还是年老代都将只有一个线程执行垃圾收集。 该标志被推荐用于只有单个可用处理器核心的JVM。 在这种情况下，使用多个垃圾收集线程甚至会适得其反，因为这些线程将争用CPU资源，造成同步开销，却从未真正并行运行。

#### `-XX:+UseParallelGC` ####

有了这个标志，我们告诉JVM使用多线程并行执行年轻代垃圾收集。

#### `-XX:+UseParallelOldGC` ####

除了激活年轻代并行垃圾收集，也激活了年老代并行垃圾收集。 当期望高吞吐量，并且JVM有两个或更多可用处理器核心时，我建议使用该标志。

#### `-XX:ParallelGCThreads` ####

通过`-XX:ParallelGCThreads=<value>`我们可以指定并行垃圾收集的线程数量。 例如，-XX:ParallelGCThreads=6表示每次并行垃圾收集将有6个线程执行。 如果不明确设置该标志，虚拟机将使用基于可用(虚拟)处理器数量计算的默认值。 决定因素是由Java Runtime。availableProcessors()方法的返回值N，如果N<=8，并行垃圾收集器将使用N个垃圾收集线程，如果N>8个可用处理器，垃圾收集线程数量应为3+5N/8。

#### `-XX:GCTimeRatio` ####

通过`-XX:GCTimeRatio=<value>`我们告诉JVM吞吐量要达到的目标值。 更准确地说，-XX:GCTimeRatio=N指定目标应用程序线程的执行时间(与总的程序执行时间)达到N/(N+1)的目标比值。 例如，通过`-XX:GCTimeRatio=9`我们要求应用程序线程在整个执行时间中至少9/10是活动的(因此，GC线程占用其余1/10)。 基于运行时的测量，JVM将会尝试修改堆和GC设置以期达到目标吞吐量。 `-XX:GCTimeRatio`的默认值是99，也就是说，应用程序线程应该运行至少99%的总执行时间。

#### `XX:MaxGCPauseMillis` ####

通过`-XX:GCTimeRatio=<value>`告诉JVM最大暂停时间的目标值(以毫秒为单位)。 在运行时，吞吐量收集器计算在暂停期间观察到的统计数据(加权平均和标准偏差)。 如果统计表明正在经历的暂停其时间存在超过目标值的风险时，JVM会修改堆和GC设置以降低它们。 需要注意的是，年轻代和年老代垃圾收集的统计数据是分开计算的，还要注意，默认情况下，最大暂停时间没有被设置。

--------------------

## 四、CMS收集器 ##

就像吞吐量收集器,CMS收集器处理老年代的对象,然而其操作要复杂得多。吞吐量收集器总是暂停应用程序线程，并且可能是相当长的一段时间，然而这能够使该算法安全地忽略应用程序。相比之下，CMS收集器被设计成在大多数时间能与应用程序线程并行执行，仅仅会有一点(短暂的)停顿时间。GC与应用程序并行的缺点就是，可能会出现各种同步和数据不一致的问题。为了实现安全且正确的并发执行，CMS收集器的GC周期被分为了好几个连续的阶段。

#### CMS收集器的过程 ####

CMS收集器的GC周期由6个阶段组成。其中4个阶段(名字以Concurrent开始的)与实际的应用程序是并发执行的，而其他2个阶段需要暂停应用程序线程。

*  `初始标记`：为了收集应用程序的对象引用需要暂停应用程序线程，该阶段完成后，应用程序线程再次启动。
 *  `并发标记`：从第一阶段收集到的对象引用开始，遍历所有其他的对象引用。
 *  `并发预清理`：改变当运行第二阶段时，由应用程序线程产生的对象引用，以更新第二阶段的结果。
 *  `重标记`：由于第三阶段是并发的，对象引用可能会发生进一步改变。因此，应用程序线程会再一次被暂停以更新这些变化，并且在进行实际的清理之前确保一个正确的对象引用视图。这一阶段十分重要，因为必须避免收集到仍被引用的对象。
 *  `并发清理`：所有不再被应用的对象将从堆里清除掉。
 *  `并发重置`：收集器做一些收尾的工作，以便下一次GC周期能有一个干净的状态。

#### 挑战 ####

当我们在真实的应用中使用CMS收集器时，我们会面临两个主要的挑战，可能需要进行调优：

###### 1、堆碎片 ######

堆碎片是有可能的，不像吞吐量收集器，CMS收集器并没有任何碎片整理的机制。因此，应用程序有可能出现这样的情形，即使总的堆大小远没有耗尽，但却不能分配对象——仅仅是因为没有足够连续的空间完全容纳对象。当这种事发生后，并发算法不会帮上任何忙，因此，万不得已JVM会触发`Full GC`，重新整理内存空间。

###### 2、对象分配率高 ######

第二个挑战就是应用的对象分配率高。如果获取对象实例的频率高于收集器清除堆里死对象的频率，并发算法将再次失败。从某种程度上说，老年代将没有足够的可用空间来容纳一个从年轻代提升过来的对象。这种情况被称为“并发模式失败”，并且JVM会执行堆碎片整理：触发`Full GC`。

--------------------

#### `-XX：+UseConcMarkSweepGC` ####

该标志首先是激活CMS收集器。默认HotSpot JVM使用的是并行收集器。

#### `-XX：UseParNewGC` ####

当使用CMS收集器时，该标志激活年轻代使用多线程并行执行垃圾回收。  
注意，当使用`-XX：+UseConcMarkSweepGC`时，`-XX：UseParNewGC`会自动开启。因此，如果年轻代的并行GC不想开启，可以通过设置`-XX：-UseParNewGC`来关掉。

#### `-XX：+CMSConcurrentMTEnabled` ####

当该标志被启用时，并发的CMS阶段将以多线程执行(因此，多个GC线程会与所有的应用程序线程并行工作)。该标志已经默认开启，如果顺序执行更好，这取决于所使用的硬件，多线程执行可以通过`-XX：-CMSConcurremntMTEnabled`禁用。

#### `-XX：ConcGCThreads` ####

标志`-XX：ConcGCThreads=<value>`(早期JVM版本也叫`-XX:ParallelCMSThreads`)定义并发CMS过程运行时的线程数。比如value=4意味着CMS周期的所有阶段都以4个线程来执行。尽管更多的线程会加快并发CMS过程，但其也会带来额外的同步开销。因此，对于特定的应用程序，应该通过测试来判断增加CMS线程数是否真的能够带来性能的提升。

#### `-XX:+CMSClassUnloadingEnabled` ####

相对于并行收集器，CMS收集器默认不会对永久代进行垃圾回收。如果希望对永久代进行垃圾回收，可用设置标志`-XX:+CMSClassUnloadingEnabled`。在早期JVM版本中，要求设置额外的标志`-XX:+CMSPermGenSweepingEnabled`。注意，即使没有设置这个标志，一旦永久代耗尽空间也会尝试进行垃圾回收，但是收集不会是并行的，而再一次进行Full GC。

#### `-XX:+ExplicitGCInvokesConcurrent and -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses` ####

如今,被广泛接受的最佳实践是避免显式地调用GC(所谓的“系统GC”)，即在应用程序中调用system.gc()。然而，这个建议是不管使用的GC算法的，值得一提的是，当使用CMS收集器时，系统GC将是一件很不幸的事，因为它默认会触发一次Full GC。幸运的是，有一种方式可以改变默认设置。标志`-XX:+ExplicitGCInvokesConcurrent`命令JVM无论什么时候调用系统GC，都执行CMS GC，而不是Full GC。第二个标志`-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses`保证当有系统GC调用时，永久代也被包括进CMS垃圾回收的范围内。因此，通过使用这些标志，我们可以防止出现意料之外的”stop-the-world”的系统GC。

--------------------

## 五、GC日志 ##

#### `-XX:+PrintGC` ####

参数`-XX:+PrintGC`（或者`-verbose:gc`）开启了简单GC日志模式，为每一次新生代（young generation）的GC和每一次的Full GC打印一行信息。下面举例说明：

[GC 246656K->243120K(376320K), 0.0929090 secs]
    [Full GC 243120K->241951K(629760K), 1.5589690 secs]

行开始首先是GC的类型（可以是“GC”或者“Full GC”），然后是在GC之前和GC之后已使用的堆空间，再然后是当前的堆容量，最后是GC持续的时间（以秒计）。  
第一行的意思就是GC将已使用的堆空间从246656K减少到243120K，当前的堆容量（译者注：GC发生时）是376320K，GC持续的时间是0.0929090秒。

简单模式的GC日志格式是与GC算法无关的，日志也没有提供太多的信息。在上面的例子中，我们甚至无法从日志中判断是否GC将一些对象从young generation移到了old generation。所以详细模式的GC日志更有用一些。

#### `-XX:PrintGCDetails` ####

如果不是使用`-XX:+PrintGC`，而是`-XX:PrintGCDetails`，就开启了详细GC日志模式。在这种模式下，日志格式和所使用的GC算法有关。我们首先看一下使用Throughput垃圾收集器在young generation中生成的日志。

[GC 
    [PSYoungGen: 142816K->10752K(142848K)] 246648K->243136K(375296K), ]
    [Times: user=0.55 sys=0.10, real=0.09 secs]

`PSYoungGen`是指GC发生的区域。  
142816K->10752K(142848K)，这三个数字分别对应GC之前占用年轻代的大小，GC之后年轻代占用，以及整个年轻代的大小。  
246648K->243136K(375296K)，这三个数字分别对应GC之前占用堆内存的大小，GC之后堆内存占用，以及整个堆内存的大小。  
0.0935090 secs 是该时间点GC占用耗费时间。

“Times”部分包含了GC所使用的CPU时间信息，分别为操作系统的用户空间和系统空间所使用的时间。同时，它显示了GC运行的“真实”时间（0.09秒）。如果CPU时间（0.55秒+0.10秒）明显多于”真实“时间（0.09秒），我们可以得出结论：GC使用了多线程运行。这样的话CPU时间就是所有GC线程所花费的CPU时间的总和。实际上我们的例子中的垃圾收集器使用了8个线程。

接下来看一下Full GC的输出日志

[Full GC
        [PSYoungGen: 10752K->9707K(142848K)]
        [ParOldGen: 232384K->232244K(485888K)] 243136K->241951K(628736K)
        [PSPermGen: 3162K->3161K(21504K)], 1.5265450 secs
    ]

除了关于young generation的详细信息，日志也提供了old generation和permanent generation的详细信息。对于这三个generations，一样也可以看到所使用的垃圾收集器、堆空间的大小、GC前后的堆使用情况。需要注意的是显示堆空间的大小等于young generation和old generation各自堆空间的和。以上面为例，堆空间总共占用了241951K，其中9707K在young generation，232244K在old generation。Full GC持续了大约1.53秒，用户空间的CPU执行时间为10.96秒，说明GC使用了多线程。

#### `-XX:+PrintGCTimeStamps和-XX:+PrintGCDateStamps` ####

使用`-XX:+PrintGCTimeStamps`可以将时间和日期也加到GC日志中。表示自JVM启动至今的时间戳会被添加到每一行中。  
例子如下：

0.185: [GC 66048K->53077K(251392K), 0.0977580 secs]
    0.323: [GC 119125K->114661K(317440K), 0.1448850 secs]
    0.603: [GC 246757K->243133K(375296K), 0.2860800 secs]

如果指定了`-XX:+PrintGCDateStamps`，每一行就添加上了绝对的日期和时间。

2019-01-03T12:08:38.102-0100: [GC 66048K->53077K(251392K), 0.0959470 secs]
    2019-01-03T12:08:38.239-0100: [GC 119125K->114661K(317440K), 0.1421720 secs]
    2019-01-03T12:08:38.513-0100: [GC 246757K->243133K(375296K), 0.2761000 secs]

如果需要也可以同时使用两个参数。推荐同时使用这两个参数，因为这样在关联不同来源的GC日志时很有帮助。

#### `-Xloggc` ####

缺省的GC日志时输出到终端的，使用`-Xloggc`:也可以输出到指定的文件。需要注意这个参数隐式的设置了参数`-XX:+PrintGC和-XX:+PrintGCTimeStamps`，但为了以防在新版本的JVM中有任何变化，我仍建议显示的设置这些参数。

--------------------

参考文献：JVM实用参数 [http://ifeve.com/useful-jvm-flags/][http_ifeve.com_useful-jvm-flags]

[http_ifeve.com_useful-jvm-flags]: http://ifeve.com/useful-jvm-flags/