某天，接到测试部门反馈说线上项目突然很快，由于当前版本代码和上一版本相比就多了一个刚上线了一个5分钟1次的跑批任务，先关闭次任务后观察是否卡顿，并检查堆内存是否使用完造成频繁gc

1.通过jmap命令查看堆内存中的对象

2.生成当前堆快照文件并用mat工具打开（file->HeapDump）

导出命令如下：

 ./jmap -dump:format=b,file=heap.dump 3920149

发现是有一个任务线程创建了最多的对象，调整对应配置如下核心线程从1个改5个线程

3.查看堆内存设置情况：

 ./jhsdb jmap --heap --pid  7853

返回说明：

1. MinHeapFreeRatio：最小堆空闲比例，表示堆中空闲空间的最小比例。默认值为40，表示堆中至少有40%的空间是空闲的。

2. MaxHeapFreeRatio：最大堆空闲比例，表示堆中空闲空间的最大比例。默认值为70，表示堆中最多可以有70%的空间是空闲的。

3. MaxHeapSize：最大堆大小，表示堆的最大可用空间。

4. NewSize：新生代大小，表示新生代的初始大小。

5. MaxNewSize：最大新生代大小，表示新生代的最大可用空间。

6. OldSize：老年代大小，表示老年代的初始大小。

7. NewRatio：新生代与老年代的比例，表示新生代与老年代的大小比例默认为2。

8. SurvivorRatio：幸存者区与Eden区的比例，表示幸存者区与Eden区的大小比例。默认值为8，表示幸存者区的大小是Eden区大小的1/8。

9. MetaspaceSize：元数据区大小，表示元数据区的初始大小。

10. CompressedClassSpaceSize：压缩类空间大小，表示压缩类空间的初始大小。

11. MaxMetaspaceSize：最大元数据区大小，表示元数据区的最大可用空间。

12. G1HeapRegionSize：G1堆区域大小，表示G1堆区域的大小

堆分为新生代和老年代 默认占比 1:2, 可以看到老年代占用使用过高，调整其大小,调整为3 使用参数为：

-XX:NewRatio=3

新生代分为eden区、From Survivor(S0区)、To Survivor(S1区) 默认占比8:1:1,,可以看的s区100%，调整为6

-XX:SurvivorRatio=6

其他调整为：

 -Xmx8192M 最大堆内存调整为8192M
-XX:MetaspaceSize=256M 设置元数据区初始值256M
-XX:MaxMetaspaceSize=512M 设置元数据区最大值256M
-XX:MaxDirectMemorySize=256M 设置堆外内存256M
-XX:PretenureSizeThreshold=11457280 设置对象超过11457280 字节直接进入老年代
-XX:MaxTenuringThreshold=15 设置垃圾最大年龄15 超过这个就进入老年代
-XX:+HeapDumpOnOutOfMemoryError 打印OOM
-XX:HeapDumpPath=./logs/dump.hprof dump文件

4.调整后重启观察gc情况发现明显好转从600多次fgc到12次fgc，而且12次均为启动时就触发

./jstat -gcutil 7853 5000 5

返回说明：

• S0：Survivor 0区的使用率，表示Survivor 0区已使用的百分比。
• S1：Survivor 1区的使用率，表示Survivor 1区已使用的百分比。
• E：Eden区的使用率，表示Eden区已使用的百分比。
• O：老年代的使用率，表示老年代已使用的百分比。
• M：元数据区的使用率，表示元数据区已使用的百分比。
• CCS：压缩类空间的使用率，表示压缩类空间已使用的百分比。
• YGC：Young Generation垃圾回收的次数，表示Young Generation垃圾回收的次数。
• YGCT：Young Generation垃圾回收的总时间，表示Young Generation垃圾回收的总时间。
• FGC：Full GC的次数，表示Full GC的次数。
• FGCT：Full GC的总时间，表示Full GC的总时间。
• CGC：Concurrent Mode Failure的次数，表示Concurrent Mode Failure的次数。
• CGCT：Concurrent Mode Failure的总时间，表示Concurrent Mode Failure的总时间。
• GCT：垃圾回收的总时间，表示垃圾回收的总时间。

参数解析

5.打印gc.log定位增加参数

 -XX:+PrintGCDetails  -Xloggc:./logs/gc.log

发现如下日志：

6.定位system.gc的具体位置

下载 https://arthas.aliyun.com/arthas-boot.jar

启动后选择本地项目如下：

访问arthas 的web界面

可以发现是由于项目中引入领英的paldb的问题要如何解决呢？

方法1：

-XX:+DisableExplicitGC

该参数将使JVM完全忽略系统的GC调用（不管使用的收集器是什么类型），国产欧拉系统设置了不生效，cenos机器设置正常

方法2：

-XX:+ExplicitGCInvokesConcurrent

该参数启用后JVM无论什么时候调用系统GC，都执行CMS GC，而不是Full GC。

7.再次观察gc

至此卡顿问题解决！