一次线上java应用响应时间过长问题的排查

最近接手一个老java应用，没多久接到响应时间太长的报警，整个排查过程还是挺有意思的，记录一下。
整个过程中，设计到cpu，内存，垃圾回收，引用，spring, 单例 等等知识，整个下来，心情愉悦。

接到报警

吃完晚饭回来，接到报警短信，服务响应时间太长，达到2s以上。
第一反应，怎么可能，这个应用很简单，就提供了几个查询接口，QPS单机也就10左右，居然响应时间2s以上，这不科学。

看监控

看监控平台，有问题的机器，cpu占用很高，这。。。更不科学了。理论上，这应用cpu能到1%就不错了，现在居然80%，吓得我赶紧跑到机器上，top了一把，确实是java应用占用cpu很高。

找出占用cpu的线程

ps -mp pid -o THREAD,tid,time

发现cpu几乎全被一个线程占用了，将线程id转换成16进制

printf "%x\n" tid

打印线程堆栈信息

jstack pid |grep tid -A 30

看到的结果居然是，CMS垃圾收集器的线程。。。
这，这，这不科学。

垃圾回收

看垃圾回收日志，发现一直在进行Full GC，但是几乎没啥效果，GC完了，老年代依然是几乎占满的状态。
即使是CMS，也不能避免传说中的stop the world，所以响应时间变长了。
但是，现在问题来了，Full GC回收不掉的对象都是啥啥啥？

分析java堆内存

先把线上流量从这台机器切走，