这篇文章主要介绍“java获取到heapdump文件后怎么快速分析”，在日常操作中，相信很多人在java获取到heapdump文件后怎么快速分析问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”java获取到heapdump文件后怎么快速分析”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！
heap dump： heap dump文件是一个二进制文件，它保存了某一时刻JVM堆中对象使用情况。HeapDump文件是指定时刻的Java堆栈的快照，是一种镜像文件。
产生heap dump(内存溢出)错误原因一般出于以下原因：
1)JVM内存过小，
2)程序不严密，
3)产生过多的垃圾无法回收。
在之前的OOM问题复盘之后，本周，又一Java服务出现了内存问题，这次问题不严重，只会触发堆内存占用高报警，没有触发OOM，但好在之前的复盘中总结了dump脚本，会在堆占用高时自动执行jstack与jmap，使得我们成功保留了问题现场。
发现有heapdump文件后，我立马拷贝到本机，并使用MAT分析，如下：
很显然，好像是什么接口分配了非常大的String对象，一个String对象约200MB，那它是哪分配的呢？
这个分配行为肯定是某个线程做的，而线程是最常见的GC Root，因此只要查找对象的GC Root即可，如下：
找到了大对象对应的分配线程是http-nio-8088-exec-6，如下：
如何查看这个线程在干什么呢？在MAT中摸索了一会，没找到相关内容，回想起我们的dump脚本中记录了jstack，打开看看，如下：
可以发现，这个线程正在做json序列化，但我仔细找了好一会，也没有找到相关接口的Controller，这是因为线程已经执行完了Controller里面的逻辑，之后返回接口响应数据时分配的大对象。
可是，线程栈中没有业务代码，就没法定位是哪个接口有问题了。。。
考虑到分配大对象的接口肯定会很慢，于是我转向查看tomcat的accesslog日志，如下：
终于，找到了问题接口，这个接口是用来查询商品数据的，当输入3时会查询出所有3开头的商品，而这有20w+数据，解决问题很简单，加个limit完事。
然而，我一直有个习惯，就是解决一个问题后，我会反思一下问题解决过程中有多少运气成分。
如果你经常阅读排查问题类的技术文章，就会发现不少文章，中间突然有一步定位到了问题根因，可能是突然发现了一个线索，或是硬看代码看出来的，或是猜测某处有问题，我觉得这种排查过程都有不少运气成分，我希望问题是通过多年理论基础的积累和对诊断工具的熟练使用，而有章法的一步步查出来的。
而上面通过accesslog能够定位到问题，有一定的运气成分，因为本次内存问题不极端，如果此接口请求量大，那就会瞬间触发多次FGC，进而会影响其它接口也变慢，进而无法分辨出哪个是导致问题的接口！
我想，从理论上来说，Java堆文件里面，应该有线程栈以及线程栈上的参数，因为线程是对象，参数也是对象，它们理应都在堆里，于是我找了个空闲时间，又摸索起MAT这个工具了。
摸索了一会，我就发现有这样一个按钮，可以查看线程信息，如下：
找到前面说的线程http-nio-8088-exec-6，展开后，就可以发现线程栈以及栈上的参数，如下：
这就找到了请求的Request参数对象，再将Request对象多次展开后，就可以找到接口url信息，如下：
考虑到不少同学习惯用VisualVM分析heapdump，这里也放一下VisualVM的使用方法。
首先，加载heapdump文件，如下：
然后选择相应对象，右键选择Select in Threads，如下：
定位到线程栈后，找到要查看的Request对象，点击进入，如下：
同样，展开Request对象后，可找到url信息，如下：
到此，关于“java获取到heapdump文件后怎么快速分析”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注亿速云网站，小编会继续努力为大家带来更多实用的文章！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
