Java进程假死排查记录—JVM参数调整

排查过程

我最近在跑一个项目，其中某一个Java进程跑着跑着就假死了，后台接口请求总是会无响应超时。于是乎，我参考了java服务程序假死（进程存在但请求无响应）的几种原因这篇文章中的第二点，进行排查。

1. java线程出现死锁，或所有线程被阻塞；（我没有看到线程全部阻塞）
   
2. 数据库连接池中的连接耗尽，导致获取数据库连接时永久等待；mybatis超时时间是默认的。
3. 出现了内存泄漏导致了OutOfMemory，内存空间不足导致分配内存空间持续失败;服务器的可用内存足够，但是分配给jvm的内存被耗尽的情况，容易出现这种情况；（内存好像也足够，不过老年代占比好像有90%多）。
   
4. 服务程序运行过程中替换了jar包，但是没有进行重启服务，这属于不按规则操作引起的问题；（没有操作）
5. 磁盘空间满，导致需要写数据的地方全部失败；（磁盘充足）
6. 线程池满，无法分配更多的线程来处理请求，通常是因为线程被大量阻塞在某个请求上；

以下是网友给出的一些思路

一、JVisualVM分析

1. 从第一张线程的图中，并没有看出线程有啥问题，但是从图二中可见老年代的MinorGC消耗1秒太久了。
2. 放大图二，会看到老年代在每次MinorGC之后都会增长。给出的猜测是Servivor区太小，由于内存担保机制，导致MinorGC把大量生命周期短的对象拷贝到老年代中，从而老年代越来越大无法被FullGC导致的假死问题。
   
   不过后来我在假死之前查看GC情况发现，其中年轻代MinorGC非常的频繁，而且GC时间很久，我的猜测是Servivor区太小导致的。
   

二 导出堆Dump文件，分析内存

内存占用的比较多，新时代、老年代的占比高。需要排查一下内存溢出、死锁啥的。
导出堆Dump文件：jmap -dump:format=b,file=path/test.hprof pid
然后使用JVisualVM打开这个文件。可以看到哪些类占用了比较多的堆内存。

jvm启动参数设置OOM异常时，自动生成dump文件

-XX:+HeapDumpOnOutOfMemoryError 设置当首次遭遇内存溢出时导出此时堆中相关信息
-XX:HeapDumpPath=/tmp/heapdump.hprof 指定导出堆信息时的路径或文件名

Visual GC 插件下载

https://visualvm.github.io/pluginscenters.html

一些其他的命令：

1. jps 查看当前系统存在哪些正在运行的Java程序。
2. jstack pid 了解Java进程中线程的运行情况。

GC触发过程图

一些我参考的文档

1. java生成hprof文件方式以及分析工具
   
2. jstat指令官方文档
3. JVM频繁GC分析
4. JVM 调优/问题排查 浅谈
5. 什么是 Minor GC/Major GC

好了，写的可能没有逻辑，比较散乱。第一次尝试排查问题。还请大佬们、靓仔、小姐姐们多多指教！