JVM 调优及调优实例

GC策略&内存申请、对象衰老JVM里的GC(GarbageCollection)的算法有很多种，如标记清除收集器，压缩收集器，分代收集器等等,详见HotSpotVMGC的种类现在比较常用的是分代收集（generationalcollection,也是SUNVM使用的,J2SE1.2之后引入），即将内存分为几个区域，将不同生命周期的对象放在不同区域里:younggeneration，tenuredgeneration和permanetgeneration。绝大部分的objec被分配在younggeneration(生命周期短)，并且大部分的object在这里die。当younggeneration满了之后，将引发minorcollection(YGC)。在minorcollection后存活的object会被移动到tenuredgeneration(生命周期比较长)。最后，tenuredgeneration满之后触发majorcollection。majorcollection（Fullgc）会触发整个heap的回收，包括回收younggeneration。permanetgeneration区域比较稳定，主要存放classloader信息。younggeneration有eden、2个survivor区域组成。其中一个survivor区域一直是空的，是eden区域和另一个survivor区域在下一次copycollection后活着的objecy的目的地。object在survivo区域被复制直到转移到tenured区。我们要尽量减少Fullgc的次数(tenuredgeneration一般比较大,收集的时间较长,频繁的Fullgc会导致应用的性能收到严重的影响)。堆内存GCJVM(采用分代回收的策略)，用较高的频率对年轻的对象(younggeneration)进行YGC，而对老对象(tenuredgeneration)较少(tenuredgeneration满了后才进行)进行FullGC。这样就不需要每次GC都将内存中所有对象都检查一遍。非堆内存不GCGC不会在主程序运行期对PermGenSpace进行清理，所以如果你的应用中有很多CLASS(特别是动态生成类，当然permgenspace存放的内容不仅限于类)的话,就很可能出现PermGenSpace错误。内存申请、对象衰老过程一、内存申请过程1. JVM会试图为相关Java对象在Eden中初始化一块内存区域；2. 当Eden空间足够时，内存申请结束。否则到下一步；3. JVM试图释放在Eden中所有不活跃的对象（minorcollection），释放后若Eden空间仍然不足以放入新对象，则试图将部分Eden中活跃对象放入Survivor区；4. Survivor区被用来作为Eden及old的中间交换区域，当OLD区空间足够时，Survivor区的对象会被移到Old区，否则会被保留在Survivor区；5. 当old区空间不够时，JVM会在old区进行majorcollection；6. 完全垃圾收集后，若Survivor及old区仍然无法存放从Eden复制过来的部分对象，导致JVM无法在Eden区为新对象创建内存区域，则出现"Outofmemory错误"；二、对象衰老过程1. 新创建的对象的内存都分配自eden。Minorcollection的过程就是将eden和在用survivorspace中的活对象copy到空闲survivorspace中。对象在younggeneration里经历了一定次数(可以通过参数配置)的minorcollection后，就会被移到oldgeneration中，称为tenuring。2. GC触发条件GC类型触发条件触发时发生了什么注意查看方式YGCeden空间不足清空Eden+fromsurvivor中所有noref的对象占用的内存将eden+fromsur中所有存活的对象copy到tosur中一些对象将晋升到old中:

tosur放不下的存活次数超过turningthreshold中的重新计算tenuringthreshold(serialparallelGC会触发此项)重新调整Eden和from的大小(parallelGC会触发此项)全过程暂停应用是否为多线程处理由具体的GC决定jstat–gcutil

gclogFGCold空间不足perm空间不足

显示调用System.GC,RMI等的定时触发YGC时的悲观策略dumplive的内存信息时(jmap–dump:live)清空heap中noref的对象permgen中已经被卸载的classloader中加载的class信息如配置了CollectGenOFirst,则先触发YGC(针对serialGC)如配置了ScavengeBeforeFullGC,则先触发YGC(针对serialGC)全过程暂停应用是否为多线程处理由具体的GC决定是否压缩需要看配置的具体GCjstat–gcutil

gclog3.permanentgeneration空间不足会引发FullGC,仍然不够会引发PermGenSpace错误。参考：/blog/356502/blog/archives/164

/redcreen/archive/2011/05/04/2037056.htmlJVM参数设置、分析不管是YGC还是FullGC,GC过程中都会对导致程序运行中中断,正确的选择不同的GC策略,调整JVM、GC的参数，可以极大的减少由于GC工作，而导致的程序运行中断方面的问题，进而适当的提高Java程序的工作效率。但是调整GC是以个极为复杂的过程，由于各个程序具备不同的特点，如：web和GUI程序就有很大区别（Web可以适当的停顿，但GUI停顿是客户无法接受的），而且由于跑在各个机器上的配置不同（主要cup个数，内存不同），所以使用的GC种类也会不同(如何选择见GC种类及如何选择)。本文将注重介绍JVM、GC的一些重要参数的设置来提高系统的性能。GC性能方面的考虑对于GC的性能主要有2个方面的指标：吞吐量throughput（工作时间不算gc的时间占总的时间比）和暂停pause（gc发生时app对外显示的无法响应）。1.TotalHeap默认情况下，vm会增加/减少heap大小以维持freespace在整个vm中占的比例，这个比例由MinHeapFreeRatio和MaxHeapFreeRatio指定。一般而言，server端的app会有以下规则：• 对vm分配尽可能多的memory；• 将Xms和Xmx设为一样的值。如果虚拟机启动时设置使用的内存比较小，这个时候又需要初始化很多对象，虚拟机就必须重复地增加内存。• 处理器核数增加，内存也跟着增大。2.TheYoungGeneration另外一个对于app流畅性运行影响的因素是younggeneration的大小。younggeneration越大，minorcollection越少；但是在固定heapsize情况下，更大的younggeneration就意味着小的tenuredgeneration，就意味着更多的majorcollection(majorcollection会引发minorcollection)。NewRatio反映的是young和tenuredgeneration的大小比例。NewSize和MaxNewSize反映的是younggeneration大小的下限和上限，将这两个值设为一样就固定了younggeneration的大小（同Xms和Xmx设为一样）。如果希望，SurvivorRatio也可以优化survivor的大小，不过这对于性能的影响不是很大。SurvivorRatio是eden和survior大小比例。一般而言，server端的app会有以下规则：• 首先决定能分配给vm的最大的heapsize，然后设定最佳的younggeneration的大小；• 如果heapsize固定后，增加younggeneration的大小意味着减小tenuredgeneration大小。让tenuredgeneration在任何时候够大，能够容纳所有live的data（留10%-20%的空余）。经验&&规则1. 年轻代大小选择• 响应时间优先的应用:尽可能设大,直到接近系统的最低响应时间限制(根据实际情况选择).在此种情况下,年轻代收集发生的频率也是最小的.同时,减少到达年老代的对象.• 吞吐量优先的应用:尽可能的设置大,可能到达Gbit的程度.因为对响应时间没有要求,垃圾收集可以并行进行,一般适合8CPU以上的应用.• 避免设置过小.当新生代设置过小时会导致:1.YGC次数更加频繁2.可能导致YGC对象直接进入旧生代,如果此时旧生代满了,会触发FGC.2. 年老代大小选择1. 响应时间优先的应用:年老代使用并发收集器,所以其大小需要小心设置,一般要考虑并发会话率和会话持续时间等一些参数.如果堆设置小了,可以会造成内存碎片,高回收频率以及应用暂停而使用传统的标记清除方式;如果堆大了,则需要较长的收集时间.最优化的方案,一般需要参考以下数据获得:并发垃圾收集信息、持久代并发收集次数、传统GC信息、花在年轻代和年老代回收上的时间比例。2. 吞吐量优先的应用:一般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代.原因是,这样可以尽可能回收掉大部分短期对象,减少中期的对象,而年老代尽存放长期存活对象.3. 较小堆引起的碎片问题因为年老代的并发收集器使用标记,清除算法,所以不会对堆进行压缩.当收集器回收时,他会把相邻的空间进行合并,这样可以分配给较大的对象.但是,当堆空间较小时,运行一段时间以后,就会出现"碎片",如果并发收集器找不到足够的空间,那么并发收集器将会停止,然后使用传统的标记,清除方式进行回收.如果出现"碎片",可能需要进行如下配置:-XX:+UseCMSCompactAtFullCollection:使用并发收集器时,开启对年老代的压缩.-XX:CMSFullGCsBeforeCompaction=0:上面配置开启的情况下,这里设置多少次FullGC后,对年老代进行压缩4. 用64位操作系统，Linux下64位的jdk比32位jdk要慢一些，但是吃得内存更多，吞吐量更大5. XMX和XMS设置一样大，MaxPermSize和MinPermSize设置一样大，这样可以减轻伸缩堆大小带来的压力6. 使用CMS的好处是用尽量少的新生代，经验值是128M－256M，然后老生代利用CMS并行收集，这样能保证系统低延迟的吞吐效率。实际上cms的收集停顿时间非常的短，2G的内存，大约20－80ms的应用程序停顿时间7. 系统停顿的时候可能是GC的问题也可能是程序的问题，多用jmap和jstack查看，或者killall-3java，然后查看java控制台日志，能看出很多问题。(相关工具的使用方法将在后面的blog中介绍)8. 仔细了解自己的应用，如果用了缓存，那么年老代应该大一些，缓存的HashMap不应该无限制长，建议采用LRU算法的Map做缓存，LRUMap的最大长度也要根据实际情况设定。9. 采用并发回收时，年轻代小一点，年老代要大，因为年老大用的是并发回收，即使时间长点也不会影响其他程序继续运行，网站不会停顿10. JVM参数的设置(特别是–Xmx–Xms–Xmn-XX:SurvivorRatio-XX:MaxTenuringThreshold等参数的设置没有一个固定的公式，需要根据PVold区实际数据YGC次数等多方面来衡量。为了避免promotionfaild可能会导致xmn设置偏小，也意味着YGC的次数会增多，处理并发访问的能力下降等问题。每个参数的调整都需要经过详细的性能测试，才能找到特定应用的最佳配置。promotionfailed:垃圾回收时promotionfailed是个很头痛的问题，一般可能是两种原因产生，第一个原因是救助空间不够，救助空间里的对象还不应该被移动到年老代，但年轻代又有很多对象需要放入救助空间；第二个原因是年老代没有足够的空间接纳来自年轻代的对象；这两种情况都会转向FullGC，网站停顿时间较长。解决方方案一：第一个原因我的最终解决办法是去掉救助空间，设置-XX:SurvivorRatio=65536-XX:MaxTenuringThreshold=0即可，第二个原因我的解决办法是设置CMSInitiatingOccupancyFraction为某个值（假设70），这样年老代空间到70%时就开始执行CMS，年老代有足够的空间接纳来自年轻代的对象。解决方案一的改进方案：又有改进了，上面方法不太好，因为没有用到救助空间，所以年老代容易满，CMS执行会比较频繁。我改善了一下，还是用救助空间，但是把救助空间加大，这样也不会有promotionfailed。具体操作上，32位Linux和64位Linux好像不一样，64位系统似乎只要配置MaxTenuringThreshold参数，CMS还是有暂停。为了解决暂停问题和promotionfailed问题，最后我设置-XX:SurvivorRatio=1，并把MaxTenuringThreshold去掉，这样即没有暂停又不会有promotoinfailed，而且更重要的是，年老代和永久代上升非常慢（因为好多对象到不了年老代就被回收了），所以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.logCMSInitiatingOccupancyFraction值与Xmn的关系公式上面介绍了promontionfaild产生的原因是EDEN空间不足的情况下将EDEN与Fromsurvivor中的存活对象存入Tosurvivor区时,Tosurvivor区的空间不足，再次晋升到oldgen区，而oldgen区内存也不够的情况下产生了promontionfaild从而导致fullgc.那可以推断出：eden+fromsurvivor<oldgen区剩余内存时，不会出现promontionfaild的情况，即：(Xmx-Xmn)*(1-CMSInitiatingOccupancyFraction/100)>=(Xmn-Xmn/(SurvivorRatior+2))进而推断出：CMSInitiatingOccupancyFraction<=((Xmx-Xmn)-(Xmn-Xmn/(SurvivorRatior+2)))/(Xmx-Xmn)*100例如：当xmx=128xmn=36SurvivorRatior=1时CMSInitiatingOccupancyFraction<=((128.0-36)-(36-36/(1+2)))/(128-36)*100=73.913当xmx=128xmn=24SurvivorRatior=1时CMSInitiatingOccupancyFraction<=((128.0-24)-(24-24/(1+2)))/(128-24)*100=84.615…当xmx=3000xmn=600SurvivorRatior=1时CMSInitiatingOccupancyFraction<=((3000.0-600)-(600-600/(1+2)))/(3000-600)*100=83.33CMSInitiatingOccupancyFraction低于70%需要调整xmn或SurvivorRatior值。参考：JAVAHOTSPOTVM（/blog/archives/164）JVM几个重要的参数

(校长)javajvm参数-Xms-Xmx-Xmn-Xss调优总结JavaHotSpotVMOptions/archiver/tid-2835.htmlFrequentlyAskedQuestionsAbouttheJavaHotSpotVMJavaSEHotSpotataGlanceJava性能调优笔记(内附测试例子很有用)说说MaxTenuringThreshold这个参数生产环境参数实例及分析javaapplication项目（非web项目）改进前：-Xms128m-Xmx128m-XX:NewSize=64m-XX:PermSize=64m-XX:+UseConcMarkSweepGC-XX:CMSInitiatingOccupancyFraction=78-XX:ThreadStackSize=128-Xloggc:logs/gc.log-Dsun.rmi.dgc.server.gcInterval=3600000-Dsun.rmi.dgc.client.gcInterval=3600000-Dsun.rmi.server.exceptionTrace=true问题:1. permsize设置较小,很容易达到报警范围(0.8)2. 没有设置MaxPermSize，堆增长会带来额外压力。3. NewSize较大，oldgen剩余空间64m，一方面可能会带来old区容易增长到报警范围（监控数据显示oldgenused长期在50m左右，接近78%，容易出现fullgc）,另一方面也存在promontionfail风险改进后：-Xms128m-Xmx128m-Xmn24m-XX:PermSize=80m-XX:MaxPermSize=80m-Xss256k-XX:SurvivorRatio=1-XX:MaxTenuringThreshold=20-XX:+UseParNewGC-XX:+UseConcMarkSweepGC-XX:CMSInitiatingOccupancyFraction=75-XX:+UseCMSCompactAtFullCollection-XX:+CMSParallelRemarkEnabled-XX:CMSFullGCsBeforeCompaction=2-XX:SoftRefLRUPolicyMSPerMB=0-XX:+PrintClassHistogram-XX:+PrintGCDetails-XX:+PrintGCTimeStamps-XX:+PrintHeapAtGC-Xloggc:logs/gc.log-Dsun.rmi.dgc.server.gcInterval=3600000-Dsun.rmi.dgc.client.gcInterval=3600000-Dsun.rmi.server.exceptionTrace=true修改点：1. PermSize与MaxPermSize都设置为80，一方面避免nonheapwarn(报警阀值0.8非对内存一般占用到60M以内），一方面避免堆伸缩带来的压力2. 通过设置Xmn=24M及SurvivorRatio=1使得Eden区=fromspace=tospace=8M,降低了Eden区大小，降低YGC的时间(降低到3-4ms左右),同时通过设MaxTenuringThreshold=20，使得oldgen的增长很缓慢。带来的问题是YGC的次数明显提高了很多。3. 其他参数优化修改后带来的好处见JVM参数设置再次改进后-Xms128m-Xmx128m-Xmn36m-XX:PermSize=80m-XX:MaxPermSize=80m-Xss256k-XX:SurvivorRatio=1-XX:MaxTenuringThreshold=20-XX:+UseParNewGC-XX:+UseConcMarkSweepGC-XX:CMSInitiatingOccupancyFraction=73-XX:+UseCMSCompactAtFullCollection-XX:+CMSParallelRemarkEnabled-XX:CMSFullGCsBeforeCompaction=2-XX:SoftRefLRUPolicyMSPerMB=0-XX:+PrintClassHistogram-XX:+PrintGCDetails-XX:+PrintGCTimeStamps-XX:+PrintHeapAtGC-Xloggc:logs/gc.log-Dsun.rmi.dgc.server.gcInterval=3600000-Dsun.rmi.dgc.client.gcInterval=3600000-Dsun.rmi.server.exceptionTrace=true修改点：在上面的基础上调整Xmn大小到36M，设置CMSInitiatingOccupancyFraction=73。Dden区与Survivor区大小都增加到12M，通过CMSInitiatingOccupancyFraction计算公式,计算得出value为73是，可以避免promotionfaild问题，同时满足堆内存监控报警值在80%：内存大小128M*80%=102.4M102.4M-36M=66.4M(老生代达到此值报警）老生代达到67.15M（92M*0.73）将发生FullGC，所以在老生代大小达到66.4M时也就是WARN报警时将很有可能出现FullGC。增大了Eden和Survivor区的值，会减小YGC的次数，但由于空间变大理论上也会相应的增加YGC的时间，不过由于新生代本身就很小（才36M）这点儿变化可以忽略掉。实际的监控值显示YGC的时间在4-5ms之间。是可以接受范围。SurvivorRatio这个值还得在仔细考虑下,有待优化中网上某个牛人的配置:每天几百万pv一点问题都没有，网站没有停顿$JAVA_ARGS.="-Dresin.home=$SERVER_ROOT-server-Xms6000M-Xmx6000M-Xmn500M-XX:PermSize=500M-XX:MaxPermSize=500M-XX:SurvivorRatio=65536-XX:MaxTenuringThreshold=0-Xnoclassgc-XX:+DisableExplicitGC-XX:+UseParNewGC-XX:+UseConcMarkSweepGC-XX:+UseCMSCompactAtFullCollection-XX:CMSFullGCsBeforeCompaction=0-XX:+CMSClassUnloadingEnabled-XX:-CMSParallelRemarkEnabled-XX:CMSInitiatingOccupancyFraction=90-XX:SoftRefLRUPolicyMSPerMB=0-XX:+PrintClassHistogram-XX:+PrintGCDetails-XX:+PrintGCTimeStamps-XX:+PrintHeapAtGC-Xloggc:log/gc.log";说明一下，-XX:SurvivorRatio=65536-XX:MaxTenuringThreshold=0就是去掉了救助空间；-Xnoclassgc禁用类垃圾回收，性能会高一点；-XX:+DisableExplicitGC禁止System.gc()，免得程序员误调用gc方法影响性能；-XX:+UseParNewGC，对年轻代采用多线程并行回收，这样收得快；带CMS参数的都是和并发回收相关的，不明白的可以上网搜索；CMSInitiatingOccupancyFraction，这个参数设置有很大技巧，基本上满足(Xmx-Xmn)*(100–CMSInitiatingOccupancyFraction)/100>=Xmn就不会出现promotionfailed。在我的应用中Xmx是6000，Xmn是500，那么Xmx-Xmn是5500兆，也就是年老代有5500兆，CMSInitiatingOccupancyFraction=90说明年老代到90%满的时候开始执行对年老代的并发垃圾回收（CMS），这时还剩10%的空间是5500*10%=550兆，所以即使Xmn（也就是年轻代共500兆）里所有对象都搬到年老代里，550兆的空间也足够了，所以只要满足上面的公式，就不会出现垃圾回收时的promotionfailed；SoftRefLRUPolicyMSPerMB这个参数我认为可能有点用，官方解释是softlyreachableobjectswillremainaliveforsomeamountoftimeafterthelasttimetheywerereferenced.Thedefaultvalueisonesecondoflifetimeperfreemegabyteintheheap，我觉得没必要等1秒；-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-