排查思路及常用命令
1、查看java进程
ps -ef | grep java
jps
2、检查JVM配置
ps aux | grep "applicationName=adsearch"
3、查看堆内存情况
jmap -heap 进程ID | head -n20
4、观察老年代的内存使用情况，推测可能原因
GC后的短时间能够恢复到一定值，即可排除是内存泄露
5、jmap查看堆内存中的对象信息
jmap -histo 进程ID | head -n20
6、dump堆内存文件
jmap -dump:format=b,file=heap 进程ID
7、用分析工具分析dump文件
jhat、JVisualVM
找到大对象
8、最后通过代码分析可疑对象
.
GC会对程序产生影响
FGC过于频繁：导致工作线程频繁被停止，让系统看起来一直有卡顿现象，也会使得程序的整体性能变差
YGC耗时过长：卡顿时间就会增大，加上YGC本身比较频繁，就会导致比较多的服务超时问题
FGC耗时过长：卡顿时间增加，尤其对于高并发服务，可能导致FGC期间比较多的超时问题，可用性降低
YGC过于频繁：降低服务的整体性能
.
导致FGC的原因
大对象：系统一次性加载了过多数据到内存中（比如SQL查询未做分页），导致大对象进入了老年代。
内存泄漏：频繁创建了大量对象，但是无法被回收（比如IO对象使用完后未调用close方法释放资源），先引发FGC，最后导致OOM。
程序频繁生成一些长生命周期的对象，当这些对象的存活年龄超过分代年龄时便会进入老年代，最后引发FGC. （即本文中的案例）。
程序BUG导致动态生成了很多新类，使得 Metaspace 不断被占用，先引发FGC，最后导致OOM。
代码中显式调用了gc方法，包括自己的代码甚至框架中的代码。
JVM参数设置问题：包括总内存大小、新生代和老年代的大小、Eden区和S区的大小、元空间大小、垃圾回收算法等等。
写完mybatis的SQL之后，一定要对各种 <if test> 进行空值考虑，我公司一次FGC就是因为这个导致的，另外部门定时推送过来的订单refId存在为空的情况，导致select的时候扫描全表几千万条数据（还是分库分表的。。。），导致产生了很多实体类对象和mybatis缓存对象。
所以对于只有查询一行的SQL语句，要加上limit 1，防止 <if test> 条件为空而导致扫描全表数据
.
排查总结
查看监控，记录出现问题的时间点和FGC频率
了解该时间点有没有上线版本
查看JVM参数设置：堆空间各个区域的大小，采用哪些垃圾回收器，分析JVM参数是否合理
对可能的原因进行排除：元空间打满、内存泄露、代码显示调用gc
通过 jmap -histo 命令并结合dump堆内存文件作进一步分析是否存在大对象或者长生命周期的对象
通过可疑对象，定位到具体代码
