GC--gc调优

GC–gc调优
目标
满足应用的响应时间和吞吐量需求，尽量减少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:filename

CMS配置
-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