记一次生产环境CPU过高的查询过程

周六的凌晨线上预警，cpu使用过高，然后开始查询
1.top查询cpu占比最高的，可以看到是java服务，再查可以看到4个gc线程占满了cpu，由此可知，jvm内存不够，或者，java代码写得有漏洞导致对象无法回收。


2.然后jps定位具体服务，发现是yusp-flow服务 10072
3.jstack导出线程栈信息，jmap导出dump进行内存分析，如果熟悉代码的话，看线程栈信息大概就能定位到位置了

jstack 10072> 10072.jstack
jmap -heap 10072> 10072.heap

4.然后使用内存分析工具查看dump分析，由于这个dump为7.5g，在linux上使用mat分析或windows内存高的电脑分析，否则会出现死机

具体的看这个也分析不出来了，只知道是jackson中序列化出现了问题，大致可以猜到出现了死循环，然后无限创建对象，并且还回收不了，耗尽内存，然后看一下线程堆栈信息，找一下代码的入口位置

线程堆栈信息中发现了，enc在写日志的时候进行序列化，出现了问题，造成了死循环，上面都是死循环信息如下图，可以看出信息非常规律，应该就是死循环了

参考：
1.https://blog.csdn.net/weixin_43956062/article/details/105914317
2.https://www.jianshu.com/p/3fb19e601818
3.https://blog.csdn.net/gg4236131/article/details/120100385