1. 服务出现频繁younggc

   1. 排查过程：

      1. falcon中发现younggc升高

      2. jmap -histo:live pid 看到存在大量char[],byte[],string

      3. 定位到是日志过多，执行各阶段中的日志和统计日志上报过多

   2. 解决方式：

      1. 增加执行日志打印开关和白名单，关闭执行日志

      2. 统计日志合并上报

   3. 经验沉淀：

      1. 梳理日志，分必要性控制打印

      2. 减少转JSON

2. 服务出现频繁younggc

   1. 排查过程

      1. falcon中发现younggc升高

      2. jmap -histo:live pid 看到存在大量char[],byte[],string

      3. 怀疑日志过多引起，修改后改善不明显

      4. http://jvm.sankuai.com中dump heap

      5. mat打开查找较大对象，发现sql in查询过大

   2. 解决方式：

      1. 先降级缓存为空再查询DB逻辑

      2. 优化DB查询逻辑。

   3. 经验沉淀：

      1. http://jvm.sankuai.com使用

         使用公司的scalpel平台可以一键dump出内存，地址：http://jvm.sankuai.com

      2. mat使用

         使用map工具分析内存。

3.服务每次启动时会出现一次fullgc

1. 排查过程

   1. falcon中发现服务每次启动时每台机器都会出现一次fullgc，之后正常。

   2. jstat -gc 进程号 间隔打印时间(ms) 打印次数 ,例如 jstat -gc 31132 2000 10

      发现服务metaspace已使用的内存大小为277M，再看我们的配置

      -XX:MetaspaceSize=256m
      -XX:MaxMetaspaceSize=512m

   3. 发现metaspace已使用的内存大于MetaspaceSize

      MetaspaceSize表示的是元空间出现首次FGC时的初始大小，如果不配置默认为20.8M，

      注意：这个参数并不是我们通常意义上理解的元空间的初始大小，实际上是元空间大小和发生fullgc的阈值是不断增大的，直到MaxMetaspaceSize。

      MaxMetaspaceSize是表示元空间出现FGC时最大的阈值。

   4. 因此是由于MetaspaceSize设置小了，在项目启动时，元空间大小已超过了我们配置的MetaspaceSize，因此触发了Metaspace的首次fullgc。

2. 解决方式：

   1. 调大MetaspaceSize大小，从原来的256M，设置为512M。

3. 经验沉淀：

   1. 重新理解MetaspaceSize参数。

      参考 https://www.jianshu.com/p/b448c21d2e71