记录一次内存使用过高问题分析过程
背景
现在记录这次内存使用已经记不得处于什么问题来排查的了，我是无意之中发现我们的测试环境内存使用率达到70%以上，监控软件已经开始标红，如下：
之前排查过cpu过高的问题，今天看到有个内存标高的现象，心里很是开心，因为平时很少能遇到这种异常，于是开始着手进行分析如下
- 先使用top命令查看是哪个进程占用内存过高 先top 后M（P表示按cpu进行排序）内存进行排序
- top -H -p pid (在linux中查看指定进程的线程的-H参数用法)
观察看这一个进程有多个线程，每个线程占用的内存多差不多为14.9%
3.随便找个线程，看线程堆栈信息
使用 jstack -l 25086 > jstack_25086.log jstack用于打印出给定的java进程ID堆栈信息
这时候同事说 老版本的日志在 /tmp 目录下，tailf application.log 日志，如下图：
日志频繁的数链接上级MC链接失败，超时，问了下同事这个是什么服务，说是直调的服务，说是直调的ip删除掉了，或者已经下线了，所以连不上，本地也ping了下 ，也ping不通，我也就回工位了，看了日志 只是连不上不至于导致 内存被占用这么高吧（接着往下看。。。）
4：获取dump文件
根据上面的线程堆栈信息看不出来什么，于是拉dump文件，同时也拉了hprof文件，因为本地有IBM和MAT两个工具，IBM用的是dump文件 ，MAT分析用hprof文件
4.1：生成hprof文件：jmap -dump:format=b,file=test.hprof 25086
4.2：生成dump文件：jmap -dump:file=heap_25086.dump 25086
4.3：生成javacore文件：jstack 25086 > 25086.txt(.log)一样
5：使用jdk java visualVM分析 hprof文件
分析了半天，也没有发现跟sql有关系的
也看不出来跟sql有关系的信息，不知道什么情况，一点没有思路了，不知道怎么继续往下查了。
先回家吧 （前一天晚上已经八点半了，同事都走完了，就我一个在办公室）
7：早晨来继续分析
网上查了一篇文章，说看下线程堆栈的信息，用jstack pid 看了下，还是昨天看到的nio的问题，难道是链接上级MC失败导致的，也坚信了我的想法，先梳理下业务如下：
分析完找同事问了下，这个是上个版本，那后面版本有解决这个问题嘛，说这个问题采用job的方式解决，如果上级管理中心或者直调不存在就不会再掉了。分析后决定重启服务再看。
重启后服务的内存如下：
直到我写到这，我再看环境上的内存使用情况还是很稳定，没有什么问题，可以判断这次内存飙升的原因是因为job任务不断发请求导致的，底层用的是netty实现。
总结：
1：以后再遇到查内存问题，不在没有思路的去处理了
3：还需要多多的进行实践，希望有天能做个分享者。
