jvm常用参数配置有哪些呢

本篇文章为大家展示了jvm常用参数配置有哪些呢，内容简明扼要并且容易理解，绝对能使你眼前一亮，通过这篇文章的详细介绍希望你能有所收获。

使用-XX：+UnlockExperimentalVMOptions  -XX：+UseJVMCICompiler参数来启用Graal编译器。

打印初始化参数：

java -XX:+PrintFlagsInitial

java -ea TestAssert 用来设置jvm是否启动断言机制（从JDK 1.4开始支持），缺省时jvm关闭断言机制。

-XX:ReservedCodeCacheSize=240m  JIT编译代码缓存大小

-XX:SoftRefLRUPolicyMSPerMB=50  默认1000ms .  软引用存活时间。超过后，在下次垃圾回收时回收。

clock - timestamp <= freespace * SoftRefLRUPolicyMSPerMB

clock记录是上一次GC的时间戳，timestamp则是最近一次读取soft-reference引用对象。他们的差【clock - timestamp】表示了soft-reference有多久没用了，越大表示越久没用。如果软引用上次被get()的时间离最近一次GC的时间不会太久远的话就可以不被当前GC回收。解释： 我们知道软引用，实在空间不足的情况下才会被回收，当然这个只是一个比较简单的解释。实际上软引用的回收机制复杂得多，需要SoftRefLRUPolicyMSPerMB的意思。

-XX:+HeapDumpOnOutOfMemoryError   堆异常生成文件 -XX:HeapDumpPath=/export/home/tomcat/logs/..

-XX:-OmitStackTraceInFastThrow  是否打印堆栈 ，默认开启。 大量抛出同样的异常的后，后面的异常输出将不打印堆栈。

JVM只对几个特定类型异常开启了Fast Throw优化，这些异常包括：NullPointerException，ArithmeticException，ArrayIndexOutOfBoundsException，ArrayStoreException，ClassCastException。

-XX:CICompilerCount=2  最大并行编译数

-XX：+/-UseTLAB  启用本地线程内存缓冲区

使用的64位 JVM会默认使用选项 +UseCompressedOops 开启指针压缩，将指针压缩至32位。

JVM默认延时加载偏向锁。这个延时的时间大概为4s左右，具体时间因机器而异。当然我们也可以设置JVM参数 -XX:BiasedLockingStartupDelay=0 来取消延时加载偏向锁。

·-XX：MaxMetaspaceSize：设置元空间最大值，默认是-1，即不限制，或者说只受限于本地内存大小。

-XX：MetaspaceSize：指定元空间的初始空间大小，以字节为单位，达到该值就会触发垃圾收集进行类型卸载，同时收集器会对该值进行调整：如果释放了大量的空间，就适当降低该值；如果释放了很少的空间，那么在不超过-XX：MaxMetaspaceSize（如果设置了的话）的情况下，适当提高该值。

·-XX：MinMetaspaceFreeRatio：作用是在垃圾收集之后控制最小的元空间剩余容量的百分比，可减少因为元空间不足导致的垃圾收集的频率。类似的还有

-XX：MaxMetaspaceFreeRatio，用于控制最大的元空间剩余容量的百分比。

Heap（堆）内存大小设置

-Xms512m    -Xmx1g

New Generation（新生代）内存大小设置

-Xmn256m    =>  -XX:NewSize=256m    -XX:MaxNewSize=256m

设置JVM的新生代内存大小（－Xmn 是将NewSize与MaxNewSize设为一致。256m）.

XX：+HeapDumpOnOutOfMemoryError  可以让虚拟机在内存溢出异常出现之后自动生成堆转储快照文件

设置新生代（包括Eden和两个Survivor区）与老年代的比值（除去持久代）。设置为3，则新生代与老年代所占比值为1：3，新生代占整个堆栈的1/4

-XX:NewRatio=3

设置为8,则两个Survivor区与一个Eden区的比值为2:8,一个Survivor区占整个新生代的1/10

-XX:SurvivorRatio=8

Eden内存大小设置：新生代减去2*Survivor的内存大小就是Eden的大小。

Stack(栈)内存大小设置

-Xss1m    每个线程都会产生一个栈。在相同物理内存下，减小这个值能生成更多的线程。如果这个值太小会影响方法调用的深度。

方法区内存分配（JDK8以前的版本使用，JDK8以后没有持久代了，使用的MetaSpace）

-XX: PermSize=128m 设置持久代初始内存大小128M

-XX:MaxPermSize=512m 设置持久代最大内存大小512M

元空间（Metaspace）(JDK8)  默认20M

-XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=512m（JDK8）

JDK8的持久代几乎可用完机器的所有内存，同样设一个128M的初始值，512M的最大值保护一下。

·-XX：MaxMetaspaceSize：设置元空间最大值，默认是-1，即不限制，或者说只受限于本地内存大小。

·-XX：MetaspaceSize：指定元空间的初始空间大小，以字节为单位，达到该值就会触发垃圾收集进行类型卸载，同时收集器会对该值进行调整：如果释放了大量的空间，就适当降低该值；如果释放了很少的空间，那么在不超过-XX：MaxMetaspaceSize（如果设置了的话）的情况下，适当提高该值

·-XX：MinMetaspaceFreeRatio：作用是在垃圾收集之后控制最小的元空间剩余容量的百分比，可减少因为元空间不足导致的垃圾收集的频率。

类似的还有-XX：Max-MetaspaceFreeRatio，用于控制最大的元空间剩余容量的百分比。

方法区的垃圾收集主要回收两部分内容：废弃的常量和不再使用的类型。回收废弃常量与回收Java堆中的对象非常类似。举个常量池中字面量回收的例子，假如一个字符串“java”曾经进入常量池

中，但是当前系统又没有任何一个字符串对象的值是“java”，换句话说，已经没有任何字符串对象引用常量池中的“java”常量，且虚拟机中也没有其他地方引用这个字面量。如果在这时发生内存回收，而且

垃圾收集器判断确有必要的话，这个“java”常量就将会被系统清理出常量池。常量池中其他类（接口）、方法、字段的符号引用也与此类似。

-Xnoclassgc  表示关闭JVM对方法区类的垃圾回收

Direct ByteBuffer（直接内存）内存大小设置

-XX:MaxDirectMemorySize

设置新生代代对象进入老年代的年龄

-XX:MaxTenuringThreshold=15

单位字节）对象大小大于1024字节的直接在老年代分配对象,-XX：PretenureSizeThreshold参数只对Serial和ParNew两款新生代收集器有效，HotSpot

的其他新生代收集器，如Parallel Scavenge并不支持这个参数。如果必须使用此参数进行调优，可考虑ParNew加CMS的收集器组合。

-XX:PretenureSizeThreshold=1024

TLAB占eden区的百分比 默认1%

-XX:TLABWasteTargetPercent =1

因此在eclipse.ini中加入参数-XX：+DisableExplicitGC屏蔽掉System.gc()。

垃圾收集

配套策略

CMS作为老年代的收集器，却无法与JDK 1.4.0中已经存在的新生代收集器Parallel    Scavenge配合工作 。

Serial  + Serial Old  (客户端常用）  -XX: +UseSerialGC

ParNew + Serial Old  (少用）  -XX: +UseParNewGC    jdk9后不支持

Serial  + CMS  （少用）

ParNew + CMS  (jdk5 常用）+ （并发失败 Serial Old） 

-XX: +UseConcMarkSweepGC  -XX：+UseCMS-CompactAtFullCollection -XX：CMSFullGCsBefore-Compaction=6

-XX:CMSInitiatingOccupancyFraction=70   CMS垃圾收集器，当老年代达到70%时，触发CMS垃圾回收。

Parallel Scavenge + Serial Old     -XX:+UseParallelGC

Parallel Scavenge + Paraller Old (jdk6 常用） -XX:+UseParallelOldGC

G1   -XX: +UseG1GC

ZGC使用

-XX:+UnlockExperimentalVMOptions -XX:+UseZGC  XX:+UseNUMA

Epsilon   -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC

Epsilon收集器  不能够进行垃圾收集为“卖点”的垃圾收集器

ParNew收集器是激活CMS后（使用-XX：+UseConcMarkSweepGC选项）的默认新生代收集器，也可以使用-XX：+/-UseParNewGC选项来强制指定或者禁用它。所以自JDK 9开始，ParNew加CMS收集器的组合就不再是官方推荐的服务端模式下的收集器解决方案了。官方希望它能完全被G1所取代，甚至还取消了ParNew加Serial Old以及Serial加CMS这两组收集器组合的支持（其实原本也很少人这样使用），并直接取消了-XX：+UseParNewGC参数，这意味着ParNew和CMS从此只能互相搭配使用，再也没有其他收集器能够和它们配合了。

ParNew收集器

-XX：ParallelGCThreads参数来限制垃圾收集的线程数。

Parallel Scavenge收集器

Parallel Scavenge收集器提供了两个参数用于精确控制吞吐量，分别是控制最大垃圾收集停顿时间的-XX：MaxGCPauseMillis参数以及直接设置吞吐量大小的-XX：GCTimeRatio参数

-XX：MaxGCPauseMillis参数允许的值是一个大于0的毫秒数，收集器将尽力保证内存回收花费的时间不超过用户设定值。

-XX：GCTimeRatio参数的值则应当是一个大于0小于100的整数，也就是垃圾收集时间占总时间的比率。譬如把此参数设置为19，那允许的最大垃圾收集时间就占总时间的5%（即1/(1+19)），默认值为99，即允许最大1%（即1/(1+99)）的垃圾收集时间。

-XX：+UseAdaptiveSizePolicy。这是一个开关参数，当这个参数被激活之后，就不需要人工指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX：SurvivorRatio）、晋升老年代对象大小（-XX：PretenureSizeThreshold）等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量。这种调节方式称为垃圾收集的自适应的调节策略（GC Ergonomics）

CMS收集器提供了一个-XX：+UseCMS-CompactAtFullCollection开关参数（默认是开启的，此参数从JDK 9开始废弃） fullGC时开启内存整理。

-XX：CMSFullGCsBefore-Compaction（此参数从JDK 9开始废弃），这个参数的作用是要求CMS收集器在执行过若干次（数量由参数值决定）不整理空间的Full GC之后，下一次进入Full GC前会先进行碎片整理（默认值为0，表示每次进入Full GC时都进行碎片整理）。

调高参数-XX：CMSInitiatingOccu-pancyFraction的值来提高CMS的触发百分比 ， 达到该百分比，进行垃圾收集。到了JDK 6时，CMS收集器的启动阈值就已经默认提升至92%。但这又会更容易面临另一种风险：要是CMS运行期间预留的内存无法满足程序分配新对象的需要，就会出现一次“并发失败”（Concurrent Mode Failure），这时候虚拟机将不得不启动后备预案：冻结用户线程的执行，临时启用Serial Old收集器来重新进行老年代的垃圾收集，但这样停顿时间就很长了

G1收集

使用参数-XX：MaxGCPauseMillis指定，默认值是200毫秒），优先处理回收价值收益最大的那些Region，设定允许的收集停顿时间

每个Region的大小可以通过参数-XX：G1HeapRegionSize设定，取值范围为1MB～32MB，且应为2的N次幂。

暂不支持类卸载（JDK 11时不支持，JDK 12的ZGC已经支持）

日志：

-Xlog[:[selector][:[output][:[decorators][:output-options]]]]

命令行中最关键的参数是选择器（Selector），它由标签（Tag）和日志级别（Level）共同组成，垃圾收集器的标签名称为“gc”。

全部支持的gc功能模块标签名如下所示

add，age，alloc，annotation，aot，arguments，attach，barrier，biasedlocking，blocks，bot，breakpoint，bytecode

另外，还可以使用修饰器（Decorator）来要求每行日志输出都附加上额外的内容，支持附加在日志行上的信息包括：

·time：当前日期和时间。

·uptime：虚拟机启动到现在经过的时间，以秒为单位。

·timemillis：当前时间的毫秒数，相当于System.currentTimeMillis()的输出。

·uptimemillis：虚拟机启动到现在经过的毫秒数。

·timenanos：当前时间的纳秒数，相当于System.nanoTime()的输出。

·uptimenanos：虚拟机启动到现在经过的纳秒数。

·pid：进程ID。

·tid：线程ID。

·level：日志级别。

如果不配置，默认的是：

-Xlog:all=warning:stdout:uptime,level,tags

-XX:+UseG1GC -Xms20M -Xmx20M -Xmn10M -Xlog:all=info:stdout:uptime,level,tags,time

-Xlog[:[what][:[output][:[decorators][:output-options[,...]]]]]

-Xlog:gc*=info，表示包含 gc 标签的所有日志，info 级别的都会输出，就是上面说的 gc 相关的所有标签。

-XX:+UseG1GC -Xms20M -Xmx20M -Xmn10M -Xlog:gc*=info:stdout:time,uptime,tags

output

包含三种输出：

* stdout： 标准输出

* stderr： 标准错误输出

* file=filename 输出到文件

对于输出到文件可以配置output-options：filecount=50,filesize=100M这个表示保留50个文件，每个文件100M

java -Xlog:gc GCTest

查看GC基本信息，在JDK 9之前使用-XX：+PrintGC，JDK 9后使用-Xlog：gc：

查看GC详细信息，在JDK 9之前使用-XX：+PrintGCDetails，在JDK 9之后使用-X-log：gc*，用通配符*将GC标签下所有细分过程都打印出来，如果把日志级别调整到Debug或者Trace

查看GC前后的堆、方法区可用容量变化，在JDK 9之前使用-XX：+PrintHeapAtGC，JDK 9之后使用-Xlog：gc+heap=debug：

查看GC过程中用户线程并发时间以及停顿的时间，在JDK 9之前使用-XX：+Print-GCApplicationConcurrentTime以及-XX：+PrintGCApplicationStoppedTime，JDK 9之后使用-Xlog：safepoint    java -Xlog:safepoint GCTest

查看收集器Ergonomics机制（自动设置堆空间各分代区域大小、收集目标等内容，从Parallel收集器开始支持）自动调节的相关信息。在JDK 9之前使用-XX：+PrintAdaptive-SizePolicy，JDK 9之后使用-Xlog：gc+ergo*=trace：    java -Xlog:gc+ergo*=trace GCTest

查看熬过收集后剩余对象的年龄分布信息，在JDK 9前使用-XX：+PrintTenuring-Distribution，JDK 9之后使用-Xlog：gc+age=trace：    java -Xlog:gc+age=trace GCTest

-verbose:gc 开启GC日志

-XX:+PrintGCDetails -Xloggc:./gc.log -XX:+PrintGCDateStamps 将GC日志详情输入到gc.log中

但是加入参数-XX：+PrintGCApplicationStoppedTime-XX：+PrintGCDate-Stamps-Xloggc：gclog.log后，从收集器日志文件中确认了停顿确实是由垃圾收集导致的，大部分收集时间都控制在100毫秒以内，但偶尔就出现一次接近1分钟的长时间收集过程。

在Java的GUI程序中要避免这种现象，可以加入参数“-Dsun.awt.keepWorkingSetOnMinimize=true”来解决。这个参数在许多AWT的程序上都有应用，例如JDK（曾经）自带的VisualVM，启动配置文件中就有这个参数，

所以先加入参数-XX：+PrintSafepointStatistics和-XX：PrintSafepointStatisticsCount=1去查看安全点日志，

添加-XX：+SafepointTimeout和-XX：SafepointTimeoutDelay=2000两个参数，让虚拟机在等到线程进入安全点的时间超过2000毫秒时就认定为超时，这样就会输出导致问题的线程名称，

我们已经知道安全点是以“是否具有让程序长时间执行的特征”为原则进行选定的，所以方法调用、循环跳转、异常跳转这些位置都可能会设置有安全点，但是HotSpot虚拟机为了避免安全点过多带来过重的负担，对循环还有一项优化措施，认为循环次数较少的话，执行时间应该也不会太长，所以使用int类型或范围更小

的数据类型作为索引值的循环默认是不会被放置安全点的。这种循环被称为可数循环（Counted Loop），相对应地，使用long或者范围更大的数据类型作为索引值的循环就被称为不可数循环（Uncounted Loop），将会被放置安全点。通常情况下这个优化措施是可行的，但循环执行的时间不单单是由其次数决定，如果循环体单次执行就特别慢，那即使是可数循环也可能会耗费很多的时间。

上述内容就是jvm常用参数配置有哪些呢，你们学到知识或技能了吗？如果还想学到更多技能或者丰富自己的知识储备，欢迎关注亿速云行业资讯频道。