基于head dump和 Thread dump 分析故障原因
1现象
最近碰到一个线上奇怪线上的问题，平时业务正常，但最近突然大数据、高并发的时候，会出现内存飙升，长时间无法回收，且给人一种不可用的感觉，平台重启之后，又可以正常使用，日志中没有报错信息，只有数据库连接超时的错误。
最终原因：存在慢SQL。
2利用dump分析
2.1 dump的基础概念
在故障定位(尤其是out of memory)和性能分析的时候，经常会用到一些文件来帮助我们排除代码问题。这些文件记录了JVM运行期间的内存占用、线程执行等情况，这就是我们常说的dump文件。常用的有heap dump和thread dump（也叫javacore，或java dump）。我们可以这么理解：heap dump记录内存信息的，thread dump是记录CPU信息的。
2.1.1 heap dump
heap dump文件是一个二进制文件，它保存了某一时刻JVM堆中对象使用情况。HeapDump文件是指定时刻的Java堆栈的快照，是一种镜像文件。Heap Analyzer工具通过分析HeapDump文件，哪些对象占用了太多的堆栈空间，来发现导致内存泄露或者可能引起内存泄露的对象。本文中使用jdk自带的工具jvisualvm分析。
2.1.2 thread dump
thread dump文件主要保存的是java应用中各线程在某一时刻的运行的位置，即执行到哪一个类的哪一个方法哪一个行上。thread dump是一个文本文件，打开后可以看到每一个线程的执行栈，以stacktrace的方式显示。通过对thread dump的分析可以得到应用是否“卡”在某一点上，即在某一点运行的时间太长，如数据库查询，长期得不到响应，最终导致系统崩溃。单个的thread dump文件一般来说是没有什么用处的，因为它只是记录了某一个绝对时间点的情况。比较有用的是，线程在一个时间段内的执行情况。
两个以上thread dump文件在分析时特别有效，困为它可以看出在先后两个时间点上，线程执行的位置，如果发现先后两组数据中同一线程都执行在同一位置，则说明此处可能有问题，因为程序运行是极快的，如果两次均在某一点上，说明这一点的耗时是很大的。通过对这两个文件进行分析，查出原因，进而解决问题。
2.2获取dump文件
2.2.1获取heap dump 文件
windows下切换到JDK_HOME/bin/，执行以下命令：jmap -dump:format=b,file=heap.hprof pid
linux下切换到JDK_HOME/bin/，执行以下命令：./jmap -dump:format=b,file=heap.hprof pid
这样就会在当前目录下生成heap.hprof文件，这就是heap dump文件。其中pid为进程，以下是win环境下怎么获取这个pid。
打开jdk自带工具，jvisualvm如下图：
Pid就出现了。
2.2.2获取thread dump文件
windows下执行：jstack pid> thread.txt
linux下执行：./jstack pid> thread.txt
indows/linux则会将命令执行结果转储到thread.txt，这就是thread dump文件。有了dump文件后，我们就能借助性能分析工具获取dump文件中的信息。
2.3分析dump文件
2.3.1分析heap dump
使用自带工具打开dump，步骤如下图：
点击文件-》装入，选择导出的文件。
打开之后，如上图。
在类菜单中可以看到当前时刻存在内存中的类：上图中明显可以看到，char[]和String两个类占用内存绝大部分空间，直接点击查看是谁。
实例情况
双击类之后，跳转到实例数。如上图，按实例大小打一下序，可以看到大量存在的内容，算是找到占用内存的元凶，此处这个dump完成作用，需要借助另外一个dump查看，这些实例对应线程状态状态，当然本案例中线程和这些实例关系不大，属性间接关系，分析需要一定的JVM知识。
2.3.2分析Thread dump
线程的状态，科普一下，如下图：
打开thread.txt,最好是打开多个文件，比较相同线程的状态，如下图：
找堵塞和死锁的线程，最终发现好几个线程堵塞，堵塞在获取数据库连接这一步。
注：给线程标识命中真的很重要，有名字的话，一眼就能看出是那个线程出了问题。
Ok，到这一步基本上可以确认是什么问题了，只需要配合代码，review一下即可定位原因。
当然，这些只是辅助信息，具体的情况需要具体分析，欢迎各位与博主交流。