### 查看JVM参数默认值
java -XX:+PrintFlagsInitial -version | grep "MetaspaceSize"
java -XX:+PringCommandLineFlags -version
### 订单风控
-XX:+UseG1GC -Xmx2g -XX:MaxGCPauseMillis=1000 -XX:MetaspaceSize=45m -XX:G1HeapRegionSize=8m -XX:SurvivorRatio=6 -XX:+UnlockExperimentalVMOptions -XX:G1NewSizePercent=20 -XX:G1MaxNewSizePercent=60 -XX:InitiatingHeapOccupancyPercent=20 -XX:G1ReservePercent=35 -Dfile.encoding=utf-8 -XX:+PrintGCDateStamps -XX:+PrintGCDetails -Xloggc:/Data/logs/risk/gc.log -XX:+HeapDumpAfterFullGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/Data/logs/risk/heapdump.hprof
#### Metadata GC Threshold
2020-05-08T09:49:19.352+0800: 1.803: [GC pause (Metadata GC Threshold) (young) (initial-mark), 0.0145880 secs]
[Parallel Time: 7.2 ms, GC Workers: 8]
[GC Worker Start (ms): Min: 1802.7, Avg: 1802.9, Max: 1803.6, Diff: 0.9]
[Ext Root Scanning (ms): Min: 1.2, Avg: 2.5, Max: 5.6, Diff: 4.4, Sum: 20.1]
[Update RS (ms): Min: 0.0, Avg: 0.5, Max: 0.8, Diff: 0.8, Sum: 4.3]
[Processed Buffers: Min: 0, Avg: 1.5, Max: 4, Diff: 4, Sum: 12]
[Scan RS (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
[Code Root Scanning (ms): Min: 0.0, Avg: 0.1, Max: 0.4, Diff: 0.4, Sum: 0.7]
[Object Copy (ms): Min: 0.0, Avg: 2.9, Max: 4.1, Diff: 4.1, Sum: 23.3]
[Termination (ms): Min: 0.0, Avg: 0.2, Max: 0.8, Diff: 0.8, Sum: 1.7]
[Termination Attempts: Min: 1, Avg: 11.6, Max: 24, Diff: 23, Sum: 93]
[GC Worker Other (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.1]
[GC Worker Total (ms): Min: 5.6, Avg: 6.3, Max: 7.1, Diff: 1.5, Sum: 50.4]
[GC Worker End (ms): Min: 1809.1, Avg: 1809.2, Max: 1809.8, Diff: 0.6]
[Code Root Fixup: 0.2 ms]
[Code Root Purge: 0.0 ms]
[Clear CT: 0.2 ms]
[Other: 7.1 ms]
[Choose CSet: 0.0 ms]
[Ref Proc: 6.7 ms]
[Ref Enq: 0.0 ms]
[Redirty Cards: 0.2 ms]
[Humongous Register: 0.0 ms]
[Humongous Reclaim: 0.0 ms]
[Free CSet: 0.0 ms]
[Eden: 24.0M(52.0M)->0.0B(52.0M) Survivors: 8192.0K->8192.0K Heap: 37.1M(100.0M)->12.6M(100.0M)]
[Times: user=0.11 sys=0.00, real=0.02 secs]
由于元数据空间不足导致的GC
解决方案:
1. 调整元数据空间初始大小,-XX:MetaspaceSize=64m(默认20m)
924.897: [GC pause (G1 Evacuation Pause) (mixed) (to-space exhausted), 0.1957310 secs]
#### GCLocker-initiated GC
#### to-space exhausted
无法为复制对象申请空间
old区的使用速度超过了垃圾收集器的回收速度
这种情况属于晋升失败的情况——G1收集器完成了标记阶段,开始启动混合式垃圾收集,准备要清理老年代分区,但是老年代分区在垃圾收集器释放出足够的空间之前就已经被耗尽了。这种失败通常意味着混合式垃圾收集需要更迅速得完成垃圾收集,每次新生代垃圾收集需要处理更多的老年代分区。一般来说,一系列的to-space exhausted之后会跟着一次FGC。
解决方案:
1. 让G1更早得启动混合式垃圾收集周期,调小-XX:InitiatingHeapOccupancyPercent=N这个参数的值,因为转移失败的代价比多执行一些并发标记周期高很多;默认情况下该参数是45(PS:这个参数表示的是占用整个堆内存的比例),不过,这个参数也不能调得太小,否则会导致过多的并发收集周期和混合式垃圾收集,给应用造成过多的停顿。
2. 还可以考虑增加每次混合式垃圾收集收集的Old分区数量,通过调整-XX:G1MixedGCCountTarget=N参数可以控制每个混合式周期中回收的Old分区数量,该参数的默认值是8;
Evacuation Failure 转移失败会导致应用长时间暂停
解决方案:
1. 让G1更早得启动混合式垃圾收集周期
2. 增加用于垃圾收集的线程个数,通过调整-XX:ConcGCThreads,代价是会多一些CPU的消耗;也就是会占用Java应用的CPU时间,这一点也需要权衡一下。
3. 有时候转移失败是由于survivor分区中没有足够的空间容纳新晋升的对象,如果是这种情况,还可以考虑增加-XX:G1ReservePercent的大小,在G1中这个默认值是10%。
#### Evacuation Failure
当没有更多的空闲region被提升到老一代或者复制到幸存空间时,并且由于堆已经达到最大值,堆不能扩展,从而发生Evacuation Failure
对于G1 GC,它是非常耗时的,1、对于成功复制的对象,G1需要更新引用,并且该region被一直引用;2、对于未成功复制的对象,G1将自动转发它们,并保留这些region。
解决方案:
1. 不要过度加一些jvm参数。比如-Xmn,这个参数会限制G1的参数的自动扩展。可以仅使用-Xms,-Xmx和暂停时间目标-XX:MaxGCPauseMillis,删除任何额外的堆大小,例如-Xmn,-XX:NewSize,-XX:MaxNewSize,-XX:SurvivorRatio等。
2. 如果问题仍然存在,则增加JVM堆大小(即-Xmx)
3. 如果您无法增加堆大小,并且您注意到marking cycle没有足够早地开始回收老一代,那么请减少-XX:InitiatingHeapOccupancyPercent。默认值是45%。减小该值将提前开始marking cycle 。另一方面,如果marking cycle 提前开始并且未收回,请将-XX:InitiatingHeapOccupancyPercent阈值增加到默认值以上。
4. 如果并发marking cyc
概念 :并发周期包含
- 初始标记(STW):标记处根集合可直达的对象;
- 并发标记:递归扫描整个堆里的对象图,包括SATB中写栅栏记录的引用;
- 重新标记(STW):处理所有剩下的SATB日志缓冲区和所有更新,也会在这里处理弱引用;
- 清除(STW):识别所有空闲分区、整理堆分区,为混合收集识别出高效的老年代分区;RSet梳理

9万+

被折叠的 条评论
为什么被折叠?



