服务程序卡死无响应一例
服务端使用Springboot编写，在测试时发现服务超时，对数据库进行了检查，无慢SQL，内存使用正常，磁盘使用正常；
使用top查看应用服务器状态，发现Java进程62278占用CPU 700%，通过进程ID，查看对应线程；
[cayy@localhost test]$ top -H -p 62278 top - 10:53:11 up 164 days, 16:13, 4 users, load average: 5.77, 6.06, 6.16 Threads: 46 total, 8 running, 38 sleeping, 0 stopped, 0 zombie %Cpu(s):100.0 us, 0.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 12125828 total, 168556 free, 10434352 used, 1522920 buff/cache KiB Swap: 8257532 total, 7755516 free, 502016 used. 1131656 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 62282 xisoft 20 0 13.8g 8.5g 13388 R 99.9 73.4 27:03.49 java 62280 xisoft 20 0 13.8g 8.5g 13388 R 99.9 73.4 27:03.41 java 62281 xisoft 20 0 13.8g 8.5g 13388 R 99.9 73.4 27:04.16 java 62284 xisoft 20 0 13.8g 8.5g 13388 R 99.9 73.4 27:03.00 java 62285 xisoft 20 0 13.8g 8.5g 13388 R 99.9 73.4 27:03.41 java 62286 xisoft 20 0 13.8g 8.5g 13388 R 99.9 73.4 27:03.37 java 62287 xisoft 20 0 13.8g 8.5g 13388 R 99.9 73.4 27:02.80 java 62283 xisoft 20 0 13.8g 8.5g 13388 R 99.7 73.4 27:03.27 java 62278 xisoft 20 0 13.8g 8.5g 13388 S 0.0 73.4 0:00.00 java 62279 xisoft 20 0 13.8g 8.5g 13388 S 0.0 73.4 0:12.47 java
使用jstack将java线程状况输出到文件
$ jstack 62278 > 62278.txt
转换线程的id到16进制
$ python -c "print hex(62282)"
0xf34a
在jstack输出文件中检索0xf34a
$ cat 62278.txt | grep 0xf34a "GC task thread#2 (ParallelGC)" os_prio=0 tid=0x00007f7d28062000 nid=0xf34a runnable
发现主要线程花费在GC上面，这种情况一般都是有大量对象的创建，甚至瞬时好几百万；使用jmap查使用情况会发现Eden Spaces使用率100%；
$ jmap -heap 62278
具体分析需要对内存进行dump然后用内存工具分析
jmap -dump:format=b,file=62278.dmp 62278
可下载Eclipse的Memory Analyzer或者VisualVM，建议下载最新版本；
https://www.eclipse.org/mat/ https://visualvm.github.io/download.html
注意：由于dump达8GB，所以需要先修改分析工具的配置内存到12G，否则会耗费较长的CPU时间，或者报内存不够；
使用分析工具可找到具体的对象；