JVM的那些常用参数以及命令

简介

java 启动参数共分为三类

• 其一是标准参数（-），所有的 JVM 实现都必须实现这些参数的功能，而且向后兼容
• 其二是非标准参数（-X），默认 jvm 实现这些参数的功能，但是并不保证所有 jvm 实现都满足，且不保证向后兼容
• 其三是非 Stable 参数（-XX），此类参数各个 jvm 实现会有所不同，将来可能会随时取消，需要慎重使用

调试参数

打印启动参数

可以查看默认参数

java -XX:+PrintCommandLineFlags -version

打印 GC 日志

不要用XX:+UseGCLogFileRotation ，这个会丢失旧的日志文件，而且重启会覆盖当前日志文件：

-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/home/GCEASY/gc.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=20M

应该用下面这个

-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/home/GCEASY/gc-%t.log

打印 ClassLoader 日志

这个参数会在控制台打印所有类加载 / 卸载信息

-XX:+TraceClassLoading -XX:+TraceClassUnloading

OOM 时 Dump 内存

 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/crashes/my-heap-dump.hprof

OOM 时执行脚本（比如重启）

 -XX:OnOutOfMemoryError=/scripts/restart-myapp.sh

打印 JIT 时间

-XX:-CITime

方法被编译时打印相关信息

-XX:-PrintCompilation

内存类

JVM 设置内存的单位默认是字节（不加单位的情况下）。

也可以在大小后面增加单位，例如：

-Xmn256m
-Xmn262144k
-Xmn268435456

设置初始新生代大小

-XX:NewSize=2G(也可以是 2M)

设置最大新生代大小

-XX:MaxNewSize=2G(也可以是 2M)

注意：-Xmn优先级大于 -XX:NewRatio

设置 Eden/Survivor 比例

表示两个 Survivor 和 Edgen 区的比，8 表示两个 Survivor:Eden=2:8，即一个 Survivor 占新生代的 1 /10。

计算方式为：

Survivor Size(1) = Young Generation Size / (2+<SurvivorRatio)
Eden Size = Young Generation Size / (2+SurvivorRatio) * SurvivorRatio

配置：

-XX:SurvivorRatio=8

8 也是默认的比例，不过这个比例在 Parallel Scavenge（新生代并行回收器，JDK5 以后的默认新生代回收器）回收器下是动态的，运行时会出现 Eden/Survivor 比例和配置的不同。

由于与吞吐量关系密切，Parallel Scavenge 收集器也经常称为“吞吐量优先”收集器。除上述两个参数之外，Parallel Scavenge 收集器还有一个参数 -XX:+UseAdaptiveSizePolicy 值得关注。这是一个开关参数，当这个参数打开之后，就不需要手工指定新生代的大小（-Xmn）、Eden 与 Survivor 区的比例（-XX:SurvivorRatio）、晋升老年代对象年龄（-XX:PretenureSizeThreshold）等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量，这种调节方式称为 GC 自适应的调节策略（GC Ergonomics)[插图]。如果读者对于收集器运作原来不太了解，手工优化存在困难的时候，使用 Parallel Scavenge 收集器配合自适应调节策略，把内存管理的调优任务交给虚拟机去完成将是一个不错的选择。只需要把基本的内存数据设置好（如 -Xmx 设置最大堆），然后使用 MaxGCPauseMillis 参数（更关注最大停顿时间）或 GCTimeRatio（更关注吞吐量）参数给虚拟机设立一个优化目标，那具体细节参数的调节工作就由虚拟机完成了。自适应调节策略也是 Parallel Scavenge 收集器与 ParNew 收集器的一个重要区别。

https://docs.oracle.com/javas…

设置老年代大小

老年代大小无法直接设置，只能通过堆大小 + 分配比例进行调整

# 设置新老一代大小之间的比率。默认值为 2。2 表示 New Size:Old Size=1:2，则新生代占堆大小的 1 /3，老年代占堆大小的 2 /3
-XX:NewRatio=2

新生代老年代大小计算方式为：

New Size = Heap Size / NewRatio + 1
Old Size = (Heap Size / NewRatio + 1) * NewRatio

设置永久代 (PermGen/MetaSpace) 大小

# 设置分配给永久生成的空间，如果超出该空间，则会触发垃圾回收。此选项在 JDK 8 中已弃用，并由 -XX：MetaspaceSize 选项取代。-XX:PermSize=size
#设置最大永久生成空间大小（以字节为单位）。此选项在 JDK 8 中已弃用，并由 -XX：MaxMetaspaceSize 选项取代。-XX:MaxPermSize=size

#设置分配的 Metaspace 的大小，Metaspace 将在首次超过垃圾收集时触发垃圾收集。垃圾收集的阈值取决于使用的元数据量而增加或减少。默认大小取决于平台。-XX:MetaspaceSize=size

#设置可以分配给 Metaspace 的最大本机内存。默认情况下，大小不受限制。应用程序的 Metaspace 量取决于应用程序本身，其他正在运行的应用程序以及系统上可用的内存量
-XX:MaxMetaspaceSize=size

初始大小和最大值的区别

初始值（比如-Xms）为 JVM 启动是向操作系统申请的内存大小(malloc)，最大值（比如-Xmx）表示，当使用的内存超过初始值后扩容的最大值

PS: JVM 配置了多少内存并不是说启动后就会占用多少物理内存，因为操作系统的内存分配是惰性的。对于已申请的内存虽然会分配地址空间，但并不会直接占用物理内存，真正使用的时候才会映射到实际的物理内存。

GC 类

这里说一下 PermGen/Metaspace 的 GC，没有查到官方资料说永久代的固定垃圾回收器，但是在 stackoverflow 上有人回答到：

所有垃圾回收器都会回收永久代，包括 PS/CMS，但并不是每个 GC 周期都会清理永久代。

这个不用纠结，看 GC 日志里清理的信息即可。

Serial/Serial Old

最古老的，单线程，独占式，成熟，每次 GC 会 STW，适合单 CPU 服务器

Serial 是一个新生代收集器，Serial Old 是 Serial 收集器的的老年代版本

新生代和老年代都用串行收集器

-XX:+UseSerialGC

新生代使用 ParallerGC，老年代使用 Serial Old

-XX:+UseParallelGC

ParNew

和 Serial 基本没区别，唯一的区别：多线程，多 CPU 的，停顿时间比 Serial 少

新生代使用 ParNew，老年代使用 Serial Old

-XX:+UseParNewGC（在 Java 8 中已弃用，在 Java 9 中已删除）

Parallel Scavenge（ParallerGC）/Parallel Old

关注吞吐量的垃圾收集器，高吞吐量则可以高效率地利用 CPU 时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。

所谓吞吐量就是 CPU 用于运行用户代码的时间与 CPU 总消耗时间的比值，即吞吐量 = 运行用户代码时间 /（运行用户代码时间 + 垃圾收集时间），虚拟机总共运行了 100 分钟，其中垃圾收集花掉 1 分钟，那吞吐量就是 99%。

Parallel Scavenge 是一个新生代收集器，Parallel Old 是 Parallel Scavenge 收集器的的老年代版本

新生代使用 ParallerGC，老年代使用 Parallel Old

-XX:+UseParallelGC
#等价于
-XX:+UseParallelOldGC

Concurrent Mark Sweep（CMS）

CMS（Concurrent Mark Sweep），收集器是一种以获取最短回收停顿时间为目标的收集器，一个老年代垃圾回收器。目前很大一部分的 Java 应用集中在互联网站或者 B / S 系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS 收集器就非常符合这类应用的需求。

新生代使用 ParNew，老年代的用 CMS

-XX:+UseConcMarkSweepGC

G1

使用 G1 收集器

-XX:+UseG1GC

垃圾回收器的组合

命令	新生代回收器 & 算法	老年代回收器 & 算法	备注
-XX:+UseSerialGC	Serial 收集器	Serial Old 收集器
-XX:+UseG1GC	G1 收集器	G1 收集器
-XX:+UseParallelGC -XX:+UseParallelOldGC -XX:+UseAdaptiveSizePolicy	ParallerGC	Paraller Old	新生代比例自适应调整
-XX:+UseParallelGC -XX:+UseParallelOldGC -XX:-UseAdaptiveSizePolicy	ParallerGC	Paraller Old	新生代比例不自动调整
-XX:+UseParNewGC	ParNew	Serial Old	Java8 废弃，Java9 移除
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC	ParNew	CMS
-XX:+UseConcMarkSweepGC -XX:-UseParNewGC	Serial	CMS	Java8 废弃，Java9 移除

下面是一些缺省的写法

命令	等同于上表
-XX:+UseParallelGC	-XX:+UseParallelGC -XX:+UseParallelOldGC
-XX:+UseParallelOldGC	-XX:+UseParallelGC -XX:+UseParallelOldGC
-Xincgc (Java8 废弃，Java9 移除)	-XX:+UseParNewGC -XX:+UseConcMarkSweepGC
-XX:+UseConcMarkSweepGC	-XX:+UseParNewGC -XX:+UseConcMarkSweepGC

常用 JVM 参数组合

JDK7

JAVA_MEM_OPTS="-server -Xmx2g -Xms2g -Xmn256m -XX:PermSize=128m -Xss256k -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70"
JAVA_DEBUG_OPTS="-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/home/GCEASY/gc-%t.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/crashes/my-heap-dump.hprof -XX:OnOutOfMemoryError=/scripts/restart-myapp.sh"

JDK8

JAVA_MEM_OPTS="-server -Xmx2g -Xms2g -Xmn256m -XX:MetaspaceSize=256m -Xss1024m -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70"
JAVA_DEBUG_OPTS="-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/home/GCEASY/gc-%t.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/crashes/my-heap-dump.hprof -XX:OnOutOfMemoryError=/scripts/restart-myapp.sh"

关于 G1，虽然说 JDK8 中已经支持 G1 了，但是并不是说一定需要。

G1 的重要特点是为用户的应用程序的提供一个低 GC 延时和大内存 GC 的解决方案，适用于大内存场景（官方推荐堆 6G 以上）

如果程序正在使用 CMS 或 ParallelOld 垃圾回收器，并且具有一个或多个以下特征，那么则可以考虑升级为 G1：

• Full GC 持续时间太长或太频繁
• 对象分配率或年轻代升级老年代很频繁
• 垃圾收集时间或压缩暂停（超过 0.5 至 1 秒）时间过长

PS：如果正在使用 CMS 或 ParallelOld 收集器，并且程序没有遇到长时间的垃圾收集暂停，那么就不需要升级到 G1

参考

• 《深入理解 Java 虚拟机：JVM 高级特性与实战（第 2 版）》– 周志明[著]
• http://www.fasterj.com/articl…
• https://www.oracle.com/techne…
• https://www.oracle.com/techne…
• https://docs.oracle.com/javas…