# 系统监控full gc频繁导致系统全面卡顿
# 现象
客户几乎每天都会出现几次全面卡顿，给人的感觉是服务器宕机，有时候几分钟或几十分钟后又自动恢复！
# 分析排查
通过seeyondump导出的卡顿时间的系统监控，或登录系统管理员直接查看系统监控发现： JVM堆内存占用很正常，运行时间5天但是 G1 Old GC （full gc）有40次，这个很不正常！
G1 Old Generation的Count是非常关键的数字，理论每天凌晨OA程序会主动进行1次full gc，其余时间都不会做。 意味着：正常情况系统运行天数跟G1 Old full gc次数基本相同（宝蓝德中间件会相差10次左右），如果G1 Old full gc明显高于运行天数，则存在问题！
系统触发 Full GC 危害较大：它会让 JVM 扫描并整理堆内全部内存，该操作性能开销极高，期间所有业务线程都会暂停，业务请求无法正常处理，直到垃圾回收完成后才恢复运行。 工作时间触发 Full GC 时间段内会让客户：无法访问系统、已登录系统的客户点击待办无反应、点击表单无反应，给人一种“宕机”的感觉。
JVM堆配置越大（32G以上），GC 扫描整理的内存越多，STW 停顿时间越长，会造成服务卡顿、接口超时，降低系统稳定性。
# 分析方向
如果JVM堆内存运行正常，但Full GC数字过高，通常是标准程序代码 或 客开代码主动触发了GC！
# 第一步：看GC日志
通常标准产品会开启GC日志输出，可以先根据配置检查GC日志，JVM配置示例如下（信创中间件路径不通，可自行查看中间件JVM配置和信创部署手册）：
开启GC日志的配置
-XX:+PrintGCDetails
GC日志存放路径配置
-Xloggc:/data/Seeyon/V5/ApacheJetspeed/logs/gc.log
gc.log日志示例如下图所示，看信息显示 [Full GC (System.gc()) 24056M->19543M(40976M), 58.3030420 secs] 表示：
- (System.gc())：说明是代码主动调用了 System.gc()，强制触发 Full GC。
- 这是G1 GC 最忌讳的行为之一，会直接打断 G1 的自适应调优，导致严重的性能问题。
# 第二步：arthas跟踪gc调用源头
定位具体代码点，需要使用Arthas工具找到 JVM 中主动调用 System.gc() 的代码位置，从而解决因 System.gc() 频繁触发 Full GC 导致的服务卡顿问题。
需要做如下操作：
options unsafe true：开启 Arthas 的unsafe 模式，允许对 JVM 核心类（如 java.lang.System）进行增强和追踪。stack java.lang.System gc：对 java.lang.System.gc() 方法进行栈追踪，打印每次调用该方法时的完整调用栈，从而定位是谁调用了它。
一、下载Arthas：从 Arthas官网入口下载 (opens new window) 名为arthas-boot.jar的包，放置到OA服务器任意位置（不用放到OA程序下，更不要放到OA的lib下）
二、找到OA的java进程PID，然后将arhtas挂到OA的Java进程中，开启gc的执行监听：
ps -ef | grep java
进入arthas
java -jar arthas-boot.jar OA的Java进程PID
在arthas命令模式下 运行如下命令
options unsafe true
在arthas命令模式下 运行如下命令，然后等待触发full gc后看输出日志
stack java.lang.System gc
三、以上运行后，保持窗口别动，需要等下次系统触发G1 Old Full GC的时候 回来看日志输出，只要触发新的Full GC就能抓到是什么代码执行了主动System.gc()
# 备用方案
在没有部署Arthas的前提下，可以提前扫描该项目的所有客开代码，查找是否有 System.gc() 这个代码，如果有，那肯定原因就是它 ： 不允许在Java代码中主动执行 System.gc() ， 及时去掉代码，更新客户服务器！
如果问题偶发，Arthas经常不在线，来不及抓到问题，可以通过配置JVM参数 "忽略代码中所有 System.gc() 调用，防止人为触发 Full GC 导致服务长时间卡顿" ：
-XX:+DisableExplicitGC
# 正常运行的系统监控示例
