笔记

万物寻其根,通其堵,便能解其困。
  博客园  :: 新随笔  :: 管理

JVM参数配置 合集

Posted on 2025-04-19 14:45  草妖  阅读(13)  评论(0)    收藏  举报
-XX:InitialHeapSize堆内存初始值(内存单位:默认(byte)、K(kb)、M(mb)、G(gb),后续内存单位不再累述);

-XX:MaxHeapSize:堆内存最大值;

-XX:+PrintCommandLineFlags :打印虚拟机的显示和隐藏参数;

参照:https://zhuanlan.zhihu.com/p/491684586

-XX:+UseCompressedClassPointers:类指针压缩(因为对于任何一个jvm中的对象而言,其内部都有一个指向自己对应类(属于哪个class)的指针(Java习惯叫引用),在64位的Java虚拟机中,默认是启动压缩的,有利于节约内存占用);

-XX:+UseCompressedOops:普通对象指针压缩(表示是否使用普通对象指针压缩,Oops是Ordinary object pointers的缩写,就是任何指向一个在堆中的对象(非简单类型)的指针,默认也是启动压缩的);

-XX:-UseLargePagesIndividualAllocation与oops一起使用,有关博客表明在较大的页内存使用时,也会自动启动;

-XX:+UseParallelGC:垃圾收集器。

-XX:+UseCondCardMark:Java虚拟机(JVM)的一个启动参数,用于启用并发标记清除(CMS)垃圾收集器中的条件卡表(Conditional Card Marking)功能。
  具体来说,该功能通过减少对内存区域的扫描次数来提高垃圾收集的效率。在传统的CMS中,每次垃圾收集时都需要扫描整个堆内存,而启用条件卡表后,只有当某个内存区域被确定为脏(即包含垃圾对象)时,才会进行扫描,从而减少了不必要的扫描操作‌
  开启会增加一次额外判断的开销,但能够避免伪共享问题,两者各有性能损耗,是否打开要根据应用实际运行情况来进行测试权衡。

-XX:ParallelGCThreads: GC收集器的并发线程数,具体配置个数如下:(注:同样适用于CMS)
当CPU数量小于或等于8,ParallelGCThreads的值等于CPU数量;
当CPU数量大于8,则使用公式:ParallelGCThreads数值=3+((5*CPU数量)/8)

 

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

-XX:MaxGCPauseMillis参数允许的值是一个大于0的毫秒数,收集器将尽力保证内存回收花费的时间不超过用户设定值。不过大家不要异想天开地认为如果把这个参数的值设置得更小一点就能使得系统的垃圾收集速度变得更快,垃圾收集停顿时间缩短是以牺牲吞吐量和新生代空间为代价换取的:系统把新生代调得小一些,收集300MB新生代肯定比收集500MB快,但这也直接导致垃圾收集发生得更频繁,原来10秒收集一次、每次停顿100毫秒,现在变成5秒收集一次、每次停顿70毫秒。停顿时间的确在下降,但吞吐量也降下来了。

-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。如果读者对于收集器运作不太了解,手工优化存在困难的话,使用Parallel Scavenge收集器配合自适应调节策略,把内存管理的调优任务交给虚拟机去完成也许是一个很不错的选择。只需要把基本的内存数据设置好(如-Xmx设置最大堆),然后使用-XX:MaxGCPauseMillis参数(更关注最大停顿时间)或XX:GCTimeRatio(更关注吞吐量)参数给虚拟机设立一个优化目标,那具体细节参数的调节工作就由虚拟机完成了。自适应调节策略也是Parallel Scavenge收集器区别于ParNew收集器的一个重要特性。(注:在 JDK 1.8 中,如果使用 CMS,无论 UseAdaptiveSizePolicy 如何设置,都会将 UseAdaptiveSizePolicy 设置为 false;不过不同版本的JDK存在差异;)

 

-XX:MaxTenuringThreshold:晋升年龄最大阈值,默认15。在新生代中对象存活次数(经过YGC的次数)后仍然存活,就会晋升到老年代。每经过一次YGC,年龄加1,当survivor区的对象年龄达到TenuringThreshold时,表示该对象是长存活对象,就会直接晋升到老年代。

-XX:TargetSurvivorRatio:设定survivor区的目标使用率。默认50,即survivor区对象目标使用率为50%。

另注:GC -XX:TargetSurvivorRatio 参数实践及gc日志分析-CSDN博客

 

-XX:CMSInitiatingOccupancyFraction:CMS垃圾收集器,当老年代达到设置时,触发CMS(如:-XX:CMSInitiatingOccupancyFraction=70,当老年代达到70%时,触发CMS)。详细可以查看:-XX:CMSInitiatingOccupancyFraction-CSDN博客

 

CMS垃圾碎片回收处理:

-XX:UseCMSCompactAtFullCollection:选项是用来控制CMS(Concurrent Mark-Sweep)垃圾收集器的行为。这个选项的全称是 "Use CMS Compact At Full Collection",它指示JVM在执行完全垃圾收集(full GC)时,尝试压缩(compact,在JVM的堆内存中,随着时间的推移,由于对象被创建和销毁,内存中会产生碎片。压缩操作会重新安排堆中的对象,使得空闲空间更加紧凑,减少内存碎片。)内存空间,从而减少内存碎片。注:默认是开启的,此参数从JDK 9开始废弃。
-XX:CMSFullGCsBeforeCompaction:这个参数的作用是要求CMS收集器在执行过若干次(数量由参数值决定)不整理空间的Full GC之后,下一次进入Full GC前会先进行碎片整理(默认值为0,表示每次进入Full GC时都进行碎片整理)。注:与-XX:+UseCMSCompactAtFullCollection搭配使用,此参数从JDK 9开始废弃。

 

G1收集器参数:

  -XX:+UseG1GC:为开启G1垃圾收集器。

  -XX:MaxGCPauseMillis: 设置GC的最大暂停时间,单位ms,如:-XX:MaxGCPauseMillis=200为200ms(200为默认值)。注:这个数值比较关键,如果过小会发生频繁,如果过大会停顿过久,所以所谓的调优,就是根据要具体项目具体设置该值。每次根据用户设定允许的收集停顿时间,优先处理回收价值收益最大的那些Region,这也就是“Garbage First”名字的由来。

  -XX:G1HeapRegionSize: 设置每个region大小。注:取值范围为1MB~32MB,且应为2的N次幂。如指定的最大内存划分-Xmx32g或-Xmx16g,G1 会将指定的堆内存均分为N个Region,N 默认情况下是 2048,每个Region的大小为:32G / 2048 = 16M。
  -Xmx32g堆内存的最大内存为32G。

 

-XX:DisableExplicitGC是JVM的一个启动参数(-XX:+DisableExplicitGC),用于禁用代码中显式调用的System.gc(),使其变为空操作‌。

 

-XX:+SafepointTimeout -XX:SafepointTimeoutDelay=2000 打印进入SafePoint超过2000ms的线程

-XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1 格式化输出SafePoint相关信息

 

-Xverify:none:禁用字节码验证器。字节码验证器是JVM中的一个安全机制,用于检查字节码是否符合Java语言规范,以防止潜在的安全漏洞。 -noverify:与-Xverify:none相同,禁用字节码验证。注:如果程序运行的全部代码(包括自己编写的、第三方包中的、从外部加载的、动态生成的等所有代码)都已经被反复使用和验证过,在生产环境的实施阶段就可以考虑使用-Xverify:none参数来关闭大部分的类验证措施,以缩短虚拟机类加载的时间。

 

-XX:CompileThreshold:为 JIT编译的阈值, 当函数的调用次数超过-XX:CompileThreshold时,JIT就将字节码编译成本地机器码。

-XX:-UseCounterDecay:关闭JIT调用计数器热度的衰减,让方法计数器统计方法调用的绝对次数。默认情况下,当超过一定的时间限度,如果方法的调用次数仍然不足以让它提交给即时编译器编译,每次GC时会对调用计数器进行砍半的操作,导致有些方法一直温热,永远都达不到触发C2编译的1万次的阀值。

-XX:CounterHalfLifeTime:参数设置半衰周期的时间,单位是秒。

-XX:BackEdgeThreshold:回边计数器的阈值。注:但是当前的HotSpot虚拟机实际上并未使用此参数,我们必须设置另外一个参数-XX:OnStackReplacePercentage来间接调整回边计数器的阈值,其计算公式有如下两种:

  1、虚拟机运行在客户端模式下,回边计数器阈值计算公式为:方法调用计数器阈值(-XX:CompileThreshold)乘以OSR比率(-XX:OnStackReplacePercentage)除以100。其中-XX: OnStackReplacePercentage默认值为933,如果都取默认值,那客户端模式虚拟机的回边计数器的阈值为13995。

   2、虚拟机运行在服务端模式下,回边计数器阈值的计算公式为:方法调用计数器阈值(-XX:CompileThreshold)乘以(OSR比率(-XX:OnStackReplacePercentage)减去解释器监控比率(-XX:InterpreterProfilePercentage)的差值)除以100。其中-XX:OnStack ReplacePercentage默认值为140,XX:InterpreterProfilePercentage默认值为33,如果都取默认值,那服务端模式虚拟机回边计数器的阈值为10700。

 

-XX:+UnlockDiagnosticVMOptions:解锁诊断参数。

 

-XX:+PrintCFGToFile(用于客户端编译器)或-XX:PrintIdealGraphFile(用于服务端编译器):要求Java虚拟机将编译过程中各个阶段的数据(譬如对客户端编译器来说包括字节码、HIR生成、LIR生成、寄存器分配过程、本地代码生成等数据)输出到文件中。如:-XX:PrintIdealGraphLevel=2-XX:PrintIdealGraphFile=ideal.xml。

 

-XX:CompileOnly:允许指定几种方法 dontinline:防止内联指定方法。(-XX:CompileOnly=Demo::workload,限定只允许编译 workload() 方法;)

 

-XX:+AlwaysAtomicAccesses:从JDK 9起,HotSpot增加了一个实验性的参数(这是JEP 188对Java内存模型更新的一部分内容)来约束虚拟机对所有数据类型进行原子性的访问。而针对double类型,由于现代中央处理器中一般都包含专门用于处理浮点数据的浮点运算器(Floating Point Unit,FPU),用来专门处理单、双精度的浮点数据,所以哪怕是32位虚拟机中通常也不会出现非原子性访问的问题,实际测试也证实了这一点。笔者的看法是,在实际开发中,除非该数据有明确可知的线程竞争,否则我们在编写代码时一般不需要因为这个原因刻意把用到的long和double变量专门声明为volatile。

 

 -XX:ThreadStackSize是一个JVM(Java虚拟机)的参数,用于设置每个线程的堆栈大小。堆栈大小决定了线程可以使用的内存量,主要用于存储局部变量、方法调用和执行状态。

 

-XX:HandlePromotionFailure:参数的设置值是否允许担保失败;空间担保分配是指在发生Minor GC之前,虚拟机会检查老年代最大可用的连续空间是否大于新生代所有对象的总空间。如果大于,则此次Minor GC是安全的。如果小于,则虚拟机会查看HandlePromotionFailure设置值是否允许担保失败。如果HandlePromotionFailure=true,那么会继续检查老年代最大可用连续空间是否大于历次晋升到老年代的对象的平均大小,如果大于,则尝试进行一次Minor GC,但这次Minor GC依然是有风险的,失败后会重新发起一次Full gc;如果小于或者HandlePromotionFailure=false,则改为直接进行一次Full GC,所有才会说一次Full GC很有可能是由一次Minor GC触发的。

 

参数形式:-XX:+/-参数 # +表示开启,-表示关闭