目标
满足应用的响应时间和吞吐量需求,尽量减少GC对应用的影响
原则
- 大部分时候都不需要调优GC,只需配置-Xms,-Xmx即可,JVM会自动进行调整
- 先满足响应时间需求,再满足吞吐量需求
- FullGC对应用的影响更大,要尽量减少FullGC执行的时间和频率,减少转移到Old的对象数量
监控GC状态
- 查看一下GC的总体执行情况
jstat -gcutil pid
参数 | 说明 |
---|---|
YGC | Minor GC执行的次数 |
YGCT | Minor GC执行的总耗时 |
YGCT/YGC | Minor GC平均耗时 |
FGC | Full GC执行的次数 |
FGCT | Full GC执行的总耗时 |
FGCT/FGC | Full GC平均耗时 |
- 查看一下GC执行的频率和详细情况 在命令行中加入-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:filename 查看GC日志中每次GC的间隔时间,即可得出GC执行的频率 也可以使用GcViewer工具,导入GC日志,进行更详细的分析(趋势分析,什么时间段GC执行得更频繁,耗时更多等)
分析监控结果
分析GC结果,确定是否需要调优,可参考以下标准(实际标准以应用的实际情况为准)
- Minor GC平均耗时少于50毫秒
- Minor GC平均频率少于10秒
- Full GC平均耗时少于1秒
- Full GC平均频率少于10分钟
当出现OutOfMemoryError时,要确定是什么问题,是内存分配不足还是因为内存泄漏或者没有及时,可以通过jmap命令或者在命令行加入-XX:+HeapDumpOnOutOfMemoryError,然后对dump出的Heap进行分析(可以使用MAT或者jvisualvm工具)
调优GC
基本策略
-
代空间调整。调整Heap中各区的大小,目标是寻找一个平衡点,在不发生OutOfMemoryError的情况下,满足应用响应时间和吞吐量的需求
增大内存,可以减少GC执行频率,但会增加GC执行时间 减少内存,可以减少GC执行时间,但会增加GC执行频率 -
内存不作动态调整,因为每次调整内存(Heap或Perm)都会触发FullGC
-Xms和-Xmx设置成相同(整个Heap大小不变) 设置-Xmn(Young区大小不变,从而Old区的大小也不变) 设置-XX:SurvivorRatio(Eden、两个Survivor大小不变) -XX:PermSize和-XX:MaxPermSize设置成相同(Perm区大小不变) - 永久代和元空间的调整注意:永久代或者元空间内并没有保存类实例的具体信息(即类对象),也没有反射对象(如方法对象);这些内容都保存在常规的堆空间内。只在编译器或者JVM的运行时有用,这部分信息被称为“类的元数据”。对永久代而言,可以通过-XX:PermSize=N和-XX:MaxPermSize=N调整大小;而元空间大小可以通过-XX:MetaspaceSize=N和-XX:MaxMetaspaceSize=N调整。
-
避免主动触发GC
程序调用了System.gc方法,会触发FullGC 在命令行中加入-XX:+DisableExplicitGC,可以忽略主动GC的调用 - 控制并发除Serial收集器之外几乎所有的垃圾收集器使用的算法基于多线程。启动的线程数由-XX:ParallelGCThreads=N参数控制。下面的参数可以调整线程的数目:使用-XX:+UseParallelGC收集新生代空间使用-XX:+UseParallelOldGC收集老年代空间使用-XX:+UseParNewGC收集新生代空间使用-XX:+UseG1GC收集新生代空间CMS收集的“时空停顿”阶段(但并非Full GC)G1收集器的“时空停顿”阶段(但并非Full GC)
- 自适应调整根据调优的策略,JVM会不断地尝试,寻找优化性能的机会,所以在JVM的运行过程中,堆、代以及Survivor空间的大小都可能会发生变化。自适应调整在两个方面能提供重要帮助:A、意味着小型应用程序不需要再为指定了过大的堆而担心。B、意味着很多应用程序根本不需要担心它们堆的大小,如果需要使用的堆大小超过了平台的默认值,可以放心的分配更大的堆,而不用关心其他的细节。JVM会自动调整堆和代的大小,依据垃圾回收算法的性能目标,使用优化的内存量。自适应调整就是让自动调整生效的法宝。使用-XX:-UseAdaptiveSizePolicy可以在全局范围内关闭自适应调整功能。(如果想了解JVM空间如何调整,可以通过-XX:+PrintAdaptiveSizePolicy)
更多高级调优见《Java性能权威指南》中的6.4章节。
响应时间调优
-
使用-XX:+UseParallelOldGC策略
-
观察Minor GC的频率和耗时,确定Young大小
确保只调整Young大小,不调整Old和Perm的大小 耗时大,则减少Eden,频率高则增加Eden,此时Survivor大小不变 如果耗时和频率都合适,则保持Eden大小不变,调整Survivor大小,相应要调整Young大小,主要目的是减少从Young移到Old的对象数量 观察每次GC后是否有对象迁移到Old,如果有,则增加Survivor大小或对象Age大小,确保将对象尽可能地留在Young(设置-XX:+PrintTenuringDistribution,可以看到每次GC后Survivor的大小和各个Age对象的数量,如果Survivor满了,则增加Survivor大小,如果Survivor未满,但仍有对象迁移到Old(排除大对象),则设置age=max(age)+1,-XX:MaxTenuringThreshold=N[0-31]) -
观察Full GC的频率和耗时,确定Old大小
确保只调整Old大小,不调整Young和Perm大小 耗时大则减少Old,频率高则增加Old 如果调整后仍然不能满足耗时需求,则考虑使用CMS策略。此时Old要增大20%-30%,因为CMS会产生碎片,要预留更多的内存给应用,否则容易产生concurrent mode error错误,会退化成Serial回收,耗时更大。如果出现concurrent mode error,可以增大Old或者减少碎片整理的百分比(-XX:CMSInitiatingOccupancyFraction=N),增大CMS的频率,加快收集Old
吞吐量调优
在满足响应时间的前提下,增加Young和Old的大小,然后再进行响应时间的分析
推荐配置
基本配置
-Xms=-Xmx
-XX:PermSize=-XX:MaxPermSize 设置-Xmn 设置-XX:SurvivorRatio -Xss=256k(默认是1M,一般不需要那么大,如果发生StackOverflowError,则增加此值) -XX:-UseAdaptiveSizePolicy(不允许JVM动态调整各区的大小) -XX:+DisableExplicitGC(关闭主动GC调用) -XX:+HeapDumpOnOutOfMemoryError -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:filenameCMS配置
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled -XX:+CMSScavengeBeforeRemark -XX:+ ScavengeBeforeFullGC -XX+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=X -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 -XX:CMSInitiatingPermOccupancyFraction=80 -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled转自:https://www.jianshu.com/p/b2dff817f983