HotSpot虚拟机参数使用

参数使用方式

1
2
3
-xx:+<option>开启 option参数
-xx:-<option>关闭 option参数
-xx:<option>=<value> 将option参数的值设置为value

内存管理参数

参数 默认值 使用介绍
DisableExplicitGC 默认关闭 忽略来自System.gc()方法触发的垃圾收集
ExplicitGCInovokesConcurrent 默认关闭 当收到System.gc()方法提交的垃圾收集申请时，使用CMS收集器进行收集
UseSerialGC Client模式的虚拟机默认开启，其他模式关闭 虚拟机运行在Client模式下的默认值，打开此开关后，使用Serial+Serial Old的收集器组合进行内存回收
UseParNewGC 默认关闭 打开此开关后，使用ParNew+Serial Old的的收集器组合进行内存回收
UseConcMarkSweepGC 默认关闭 打开此开关后，使用PerNew+CMS+Serial Old的收集器组合进行内存回收。如果CMS收集器出现Concurrent Mode Failure，则Serial Old收集器组件将作为后备收集器
UseParallelGC Server模式的虚拟机默认开启，其他模式关闭 虚拟机运行在Server模式下的默认值，打开此开关后，使用Parallel Scavenge+Serial Old的收集器组合进行内存回收
UseParallelOldGC 默认关闭 打开此开关后，使用Parallel Scavenge+Parallel Old的收集器组合进行内存回收
SurvivorRatio 默认为8 新生代中Eden区域与Survivor区域的容量比值
MaxPermSize 大部分情况下默认值是64MB 永久代的最大值
-Xms：初始堆大小
-Mmx：最大最大小

调试参数

参数 默认值 使用介绍
PrintGC 默认关闭 打印GC信息
PrintGCDetails 默认关闭 打印GC的详细信息
PrintGCTimeStamps 默认关闭 打印GC停顿耗时
HeapDumpOnOutOf MemeoryError 默认关闭 在发生内存溢出异常时是否生成堆转储快照，关闭则不生成

垃圾分代回收


在JVM分代垃圾回收机制中，把对空间分为了Young Generation 和 Old Generation，又将Young Generation分为Eden Space 、From区和To区。新建对象总是在Eden区，当Eden区空间不足就会触发一次Young GC，将还在使用的对象复制到From区，清空Eden区。然后在Eden区继续新建对象，当Eden区空间不足时，触发Young GC，就会把Eden和From区中，还是使用的对象赋值到To区，清空Eden和From。然后接着新建对象，再次触发Young GC，把还在使用的对象复制的From区。这样多次复制，超过某个阈值的对象如果还没有被释放，就是复制到Old Generation。当Old Generation也用完时，就会触发一个Full GC，即所谓的全量回收。Full GC会对系统的性能带来很大的影响，应合理配置Young Generation和Old Generation的大小，尽量减少Full GC。

GC日志的理解（周志明）

每一种收集器的日志形式都是由它们自身的实现所决定的，换而言之，每个收集器的日志格式都可以不一样。但虚拟机设计者为了方便用户阅读，将各个收集器的日志都维持一定的共性，例如以下两段典型的GC日志：

1
2
3
4
33.125: [GC [DefNew: 3324K->152K(3712K), 0.0025925 secs] 3324K->152K(11904K), 
0.0031680 secs]
100.667: [Full GC [Tenured: 0K->210K(10240K), 0.0149142 secs] 4603K->210K(19456K), 
[Perm : 2999K->2999K(21248K)], 0.0150007 secs] [Times: user=0.01 sys=0.00, real=0.02 secs]

最前面的数字“33.125：”和“100.667：”代表了GC发生的时间，这个数字的含义是从Java虚拟机启动以来经过的秒数。
GC日志开头的“［GC”和“［Full GC”说明了这次垃圾收集的停顿类型，而不是用来区分新生代GC还是老年代GC的。如果有“Full”，说明这次GC是发生了Stop-The-World的，例如下面这段新生代收集器ParNew的日志也会出现“［Full GC”（这一般是因为出现了分配担保失败之类的问题，所以才导致STW）。如果是调用System.gc()方法所触发的收集，那么在这里将显示“［Full GC (System)”。

1
[Full GC 283.736: [ParNew: 261599K->261599K(261952K), 0.0000288 secs]

接下来的“［DefNew”、“［Tenured”、“［Perm”表示GC发生的区域，这里显示的区域名称与使用的GC收集器是密切相关的，例如上面样例所使用的Serial收集器中的新生代名为“Default New Generation”，所以显示的是“［DefNew”。如果是ParNew收集器，新生代名称就会变为“［ParNew”，意为“Parallel New Generation”。如果采用Parallel Scavenge收集器，那它配套的新生代称为“PSYoungGen”，老年代和永久代同理，名称也是由收集器决定的。

后面方括号内部的“3324K->152K(3712K)”含义是“GC前该内存区域已使用容量-> GC后该内存区域已使用容量 (该内存区域总容量)”。而在方括号之外的“3324K->152K(11904K)”表示“GC前Java堆已使用容量 -> GC后Java堆已使用容量 (Java堆总容量)”。

再往后，“0.0025925 secs”表示该内存区域GC所占用的时间，单位是秒。有的收集器会给出更具体的时间数据，如“［Times： user=0.01 sys=0.00， real=0.02 secs］”，这里面的user、sys和real与Linux的time命令所输出的时间含义一致，分别代表用户态消耗的CPU时间、内核态消耗的CPU事件和操作从开始到结束所经过的墙钟时间（Wall Clock Time）。CPU时间与墙钟时间的区别是，墙钟时间包括各种非运算的等待耗时，例如等待磁盘I/O、等待线程阻塞，而CPU时间不包括这些耗时，但当系统有多CPU或者多核的话，多线程操作会叠加这些CPU时间，所以读者看到user或sys时间超过real时间是完全正常的。