JVM参数调优学习

跟踪参数

跟踪、监控JVM状态，用于程序员JVM调优及故障排查

打印gc简要信息

• -XX:+PrintGC
• -verbose:gc
  [GC (Allocation Failure) 32686K->1648K(123904K), 0.0007230 secs] 2: [GC (Allocation Failure) 34034K->1600K(123904K), 0.0009652 secs]

这个查看结果为例，解释如下：

解释1：总共发生了2次gc，因为打印出的信息标记出了1与2

解释2：以第1次gc为例，32686K表示回收前，对象占用的空间。1648K表示回收后，对象占用的空间。123904K表示还有多少空间可用。0.0007230 secs表示这次垃圾回收花费的时间。
————————————————
版权声明：本文为CSDN博主「zj_daydayup」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/u012556994/article/details/81264962

打印gc详细信息及堆使用详细信息

• -XX:+PrintGCDetails

将gc日志记录到外部文件中去

-Xloggc:log/gc.log（参数中gc.log就是外部文件的名称）
当java程序出现OOM异常时，总是想查看当时gc的情况，那么使用这个参数记录下gc日志会非常便于故障排查。也可以进行日常JVM监控。

监控类的加载情况

-XX:+TraceClassLoading
使用这个参数可以监控java程序加载的类。

常用堆分配参数

①最大堆：-Xmx，java程序最大能使用多少内存大小，如果超过这个大小，那么java程序会报：out of memory（OOM错误）

②最小堆：-Xms

③指定新生代的内存：-Xmn

④总的堆：目前程序已经配置到的内存大小。一般而言程序一启动，会按照-Xms5m先分配5M的空间，这时总的堆大小就是5M。

⑤空闲堆：程序已经分配的内存大小减去已经使用的内存大小

⑥新生代（eden+from+to）和老年代（不包含永久区）的比值：-XX:NewRatio

Survivor区与Eden区的比值：-XX:SurvivorRatio

这2个比值的计算规则如下：

若-XX:NewRatio=4，则表示新生代：老年代=1:4，那么新生代（eden+from+to）=3072+512+512=4096k，老年代=16384k，新生代：老年代=4096k：16384k=1:4。

若-XX:SurvivorRatio=6，则表示Survivor区：Eden区=2:6，那么Survivor区（from+to）=1024+1024=2048，Eden区=6144，Survivor区：Eden区=2048:6144=2:6，这样的话，一个幸存区占整个新生代区的1：（2+6）=1/8

⑦官方推荐：

新生代占堆的3/8

幸存代占新生代的1/10

⑧发生OOM异常时把堆栈信息打印到外部文件

第1个：-XX:+HeapDumpOnOutOfMemoryError

第2个：-XX:+HeapDumpPath

⑨将堆的最小值-Xms 参数与最大值-Xmx 参数设置为一样即可避免堆自动扩展。因为JVM初始分配的内存由-Xms指定，默认是物理内存的1/64；JVM最大分配的内存由-Xmx指 定，默认是物理内存的1/4。默认空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制；空余堆内存大于70%时，JVM会减少堆直到 -Xms的最小限制。因此服务器一般设置-Xms、-Xmx相等以避免在每次GC 后调整堆的大小。对象的堆内存由称为垃圾回收器的自动内存管理系统回收。

3、常用栈分配参数

①栈大小参数为-Xss

栈大小通常只有几百k，决定于函数调用的深度。每个线程都有自己独立的栈空间（私有栈空间，不共享）。如果函数调用太深，超过了栈的大小，则会抛出java.lang.StackOverflowError。遇到这种错误，通常情况下，不是去调整-Xss参数，而是应该去检查是否是函数调用太深导致的，是否使用了递归，能不能保证递归出口等。
————————————————
版权声明：本文为CSDN博主「zj_daydayup」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/u012556994/article/details/81264962

三种参数写法

1、标准参数（-），所有的JVM实现都必须实现这些参数的功能，而且向后兼容。例如：-verbose:class（输出jvm载入类的相关信息，当jvm报告说找不到类或者类冲突时可此进行诊断）；-verbose:gc（输出每次GC的相关情况）；-verbose:jni（输出native方法调用的相关情况，一般用于诊断jni调用错误信息）。

2、非标准参数（-X），默认jvm实现这些参数的功能，但是并不保证所有jvm实现都满足，且不保证向后兼容。例如：-Xms512m；-Xmx512m；-Xmn200m；-Xss128k；-Xloggc:file（与-verbose:gc功能类似，只是将每次GC事件的相关情况记录到一个文件中，文件的位置最好在本地，以避免网络的潜在问题。若与verbose命令同时出现在命令行中，则以-Xloggc为准）。

3、非Stable参数（-XX），此类参数各个jvm实现会有所不同，将来可能会随时取消，需要慎重使用。例如：-XX:PermSize=64m；-XX:MaxPermSize=512m。
————————————————
版权声明：本文为CSDN博主「mars-kobe」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/wang379275614/article/details/78471604

3.1 GC性能方面的考虑
　　对于GC的性能主要有2个方面的指标：吞吐量throughput（工作时间不算gc的时间占总的时间比）和暂停pause（gc发生时app对外显示的无法响应）。

1、Total Heap，默认情况下，vm会增加/减少heap大小以维持free space在整个vm中占的比例，这个比例由MinHeapFreeRatio和MaxHeapFreeRatio指定。一般而言，server端的app会有以下规则：对vm分配尽可能多的memory；将Xms和Xmx设为一样的值。如果虚拟机启动时设置使用的内存比较小，这个时候又需要初始化很多对象，虚拟机就必须重复地增加内存。处理器核数增加，内存也跟着增大。

2、The Young Generation，另外一个对于app流畅性运行影响的因素是young generation的大小。younggeneration越大，minor collection越少；但是在固定heap size情况下，更大的young generation就意味着小的tenured generation，就意味着更多的major collection(major collection会引发minor collection)。NewRatio反映的是young和tenured generation的大小比例。NewSize和MaxNewSize反映的是young generation大小的下限和上限，将这两个值设为一样就固定了young generation的大小（同Xms和Xmx设为一样）。如果希望，SurvivorRatio也可以优化survivor的大小，不过这对于性能的影响不是很大。SurvivorRatio是eden和survior大小比例。一般而言，server端的app会有以下规则：首先决定能分配给vm的最大的heap size，然后设定最佳的young generation的大小；如果heap size固定后，增加young generation的大小意味着减小tenured generation大小。让tenured generation在任何时候够大，能够容纳所有live的data（留10%-20%的空余）。

3.2 经验&规则
　　1、年轻代大小选择：响应时间优先的应用:尽可能设大,直到接近系统的最低响应时间限制(根据实际情况选择).在此种情况下,年轻代收集发生的频率也是最小的.同时,减少到达年老代的对象；吞吐量优先的应用:尽可能的设置大,可能到达Gbit的程度.因为对响应时间没有要求,垃圾收集可以并行进行,一般适合8CPU以上的应用；避免设置过小.当新生代设置过小时会导致:1.YGC次数更加频繁 2.可能导致YGC对象直接进入旧生代,如果此时旧生代满了,会触发FGC.

2、年老代大小选择：响应时间优先的应用:年老代使用并发收集器,所以其大小需要小心设置,一般要考虑并发会话率和会话持续时间等一些参数.如果堆设置小了,可以会造成内存碎 片,高回收频率以及应用暂停而使用传统的标记清除方式;如果堆大了,则需要较长的收集时间.最优化的方案,一般需要参考以下数据获得，并发垃圾收集信息、持久代并发收集次数、传统GC信息、花在年轻代和年老代回收上的时间比例。吞吐量优先的应用:一般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代.原因是,这样可以尽可能回收掉大部分短期对象,减少中期的对象,而年老代尽存放长期存活对象。

3、较小堆引起的碎片问题：因为年老代的并发收集器使用标记,清除算法,所以不会对堆进行压缩.当收集器回收时,他会把相邻的空间进行合并,这样可以分配给较大的对象.但是,当堆空间较小时,运行一段时间以后,就会出现"碎片",如果并发收集器找不到足够的空间,那么并发收集器将会停止,然后使用传统的标记,清除方式进行回收.如果出现"碎片",可能需要进行如下配置:-XX:+UseCMSCompactAtFullCollection:使用并发收集器时,开启对年老代的压缩；-XX:CMSFullGCsBeforeCompaction=0:上面配置开启的情况下,这里设置多少次Full GC后,对年老代进行压缩。

4、使用CMS的好处是用尽量少的新生代，经验值是128M－256M， 然后老生代利用CMS并行收集， 这样能保证系统低延迟的吞吐效率。 实际上cms的收集停顿时间非常的短，2G的内存， 大约20－80ms的应用程序停顿时间

5、系统停顿的时候可能是GC的问题也可能是程序的问题，多用jmap和jstack查看，或者killall -3 java，然后查看java控制台日志，能看出很多问题。(相关工具的使用方法将在后面的blog中介绍)。

6、仔细了解自己的应用，如果用了缓存，那么年老代应该大一些，缓存的HashMap不应该无限制长，建议采用LRU算法的Map做缓存，LRUMap的最大长度也要根据实际情况设定。

7、采用并发回收时，年轻代小一点，年老代要大，因为年老大用的是并发回收，即使时间长点也不会影响其他程序继续运行，网站不会停顿。

8、JVM参数的设置(特别是 –Xmx –Xms –Xmn-XX:SurvivorRatio -XX:MaxTenuringThreshold等参数的设置没有一个固定的公式，需要根据PV old区实际数据 YGC次数等多方面来衡量。为了避免promotion faild可能会导致xmn设置偏小，也意味着YGC的次数会增多，处理并发访问的能力下降等问题。每个参数的调整都需要经过详细的性能测试，才能找到特定应用的最佳配置。

3.3 PromotionFailed:
　　垃圾回收时promotionfailed是个很头痛的问题，一般可能是两种原因产生，第一个原因是救助空间不够，救助空间里的对象还不应该被移动到年老代，但年轻代又有很多对象需要放入救助空间；第二个原因是年老代没有足够的空间接纳来自年轻代的对象；这两种情况都会转向Full GC，网站停顿时间较长。

解决方方案一：

第一个原因我的最终解决办法是去掉救助空间，设置-XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0即可，第二个原因我的解决办法是设置CMSInitiatingOccupancyFraction为某个值（假设70），这样年老代空间到70%时就开始执行CMS，年老代有足够的空间接纳来自年轻代的对象。

解决方案一的改进方案：

又有改进了，上面方法不太好，因为没有用到救助空间，所以年老代容易满，CMS执行会比较频繁。我改善了一下，还是用救助空间，但是把救助空间加大，这样也不会有promotion failed。具体操作上，32位Linux和64位Linux好像不一样，64位系统似乎只要配置MaxTenuringThreshold参数，CMS还是有暂停。为了解决暂停问题和promotion failed问题，最后我设置-XX:SurvivorRatio=1 ，并把MaxTenuringThreshold去掉，这样即没有暂停又不会有promotoin failed，而且更重要的是，年老代和永久代上升非常慢（因为好多对象到不了年老代就被回收了），所以CMS执行频率非常低，好几个小时才执行一次，这样，服务器都不用重启了。

-Xmx4000M -Xms4000M -Xmn600M-XX:PermSize=500M -XX:MaxPermSize=500M -Xss256K -XX:+DisableExplicitGC-XX:SurvivorRatio=1 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC-XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0-XX:+CMSClassUnloadingEnabled -XX:LargePageSizeInBytes=128M-XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly-XX:CMSInitiatingOccupancyFraction=80 -XX:SoftRefLRUPolicyMSPerMB=0-XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps-XX:+PrintHeapAtGC -Xloggc:log/gc.log

3.4 CMSInitiatingOccupancyFraction值与Xmn的关系公式
　　上面介绍了promontionfaild产生的原因是EDEN空间不足的情况下将EDEN与From survivor中的存活对象存入To survivor区时,To survivor区的空间不足，再次晋升到old gen区，而old gen区内存也不够的情况下产生了promontion faild从而导致full gc.那可以推断出：eden+from survivor < old gen区剩余内存时，不会出现promontion faild的情况，即：

(Xmx-Xmn)*(1-CMSInitiatingOccupancyFraction/100)>=(Xmn-Xmn/(SurvivorRatior+2)) 进而推断出：CMSInitiatingOccupancyFraction<=((Xmx-Xmn)-(Xmn-Xmn/(SurvivorRatior+2)))/(Xmx-Xmn)*100

例如：当xmx=128 xmn=36SurvivorRatior=1时CMSInitiatingOccupancyFraction<=((128.0-36)-(36-36/(1+2)))/(128-36)*100=73.913;

当xmx=128 xmn=24SurvivorRatior=1时CMSInitiatingOccupancyFraction<=((128.0-24)-(24-24/(1+2)))/(128-24)*100=84.615…

当xmx=3000 xmn=600SurvivorRatior=1时 CMSInitiatingOccupancyFraction<=((3000.0-600)-(600-600/(1+2)))/(3000-600)*100=83.33

CMSInitiatingOccupancyFraction低于70% 需要调整xmn或SurvivorRatior值。
————————————————
版权声明：本文为CSDN博主「mars-kobe」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/wang379275614/article/details/78471604