一次排查Java项目内存泄漏的过程
发现问题
公司自己维护的服务三四个，有的服务还分多个节点，自己也有几个私人服务器，所以为了能实时知道各个服务器的情况，就使用ServerStatus做了个云探针，功能很简单，能实时的监控每个服务器的内存、cpu、硬盘、流量的使用情况，如下
实时监控图
虽然只有几个指标，但是已经能让我全面的掌握各服务的性能，再搭配chrome插件iChrome，每天打开浏览器就能第一时间看到监控界面，
iChrome.png
我始终相信一句话：
工欲善其事必先利其器
最近一段时间，我发现我的一个服务所在的两台服务器内存处于不停的增长状态，8g内存，直接超过65%，这让我很郁闷，为什么会酱紫，就在昨天，我在一个服务器上做测试(不是普通的测试，而是去验证某正逻辑在线上是否正确的测试)，然后整个服务直接宕机了，赶紧找公司的运维人员(你可能会问既然公司有运维，为什么还要自己捣鼓监控，我想说，作为一个开发，最好能在第一时间发现任何问题，还有一句话“求人不如求几”)看下服务器宕机前的状态，果然是内存突然暴增，所以我就很有必要去找出导致服务内存持续增长原因。
jmap
网上找了一些命令，感觉jmap最好用
命令行输入：jmap -histo <pid> | head -20，就可以查看某个pid的java服务占用内存排名前20的类。注：该命令不适用于Windows系统里
jmap -dump:format=b,file=filename.bin <pid>, 将整个内存情况保存到文件里，然后导出使用MAT(Memory Analyse Tool)分析
注意：堆转储文件可能比较大，我的有2.5个G
MAT
Memory Analyse Tool 内存分析工具，直接下载,下载解压之后，可以修改下配置文件MemoryAnalyzer.ini，修改里面的参数如-Xmx5120m(最好要大于你的堆转储文件)
微信截图_20180817134945.png
点击“Leak Suspects"一般会显示MAT它自己认为有问题的内容，如下
微信截图_20180817135050.png
同时会在堆转储文件的同级目录下生成一个压缩文件filename_Leak_Suspects.zip，里面是一个html静态页面，我们也可以在浏览器去分析
点击“Accumulated Objects in Dominator Tree”
就可以看到问题所在了
微信截图_20180817135301.png
发现WordDictionary中HashMap的数量异常，然后一层一层的网上找，发现了这句代码
public class xxx {
private JiebaSegmenter segmenter = new JiebaSegmenter(); // 分词
}
然而项目里对这个xxx类依赖较多，每次使用xxx的时候，都要重新去创建JiebaSegmenter对象。。。。
赶紧将其改为
private static JiebaSegmenter segmenter = new JiebaSegmenter(); // 分词
因为这个分词程序是直接在github上面找的代码，所以没有认真去看，真的是应了那句话“该来的迟早会来~~~”
最后
以上就是自己通过内存分析定为到具体代码的整个过程，之类MAT用的很简单，只是简单的分析，也可以参考这篇https://blog.csdn.net/wanghuiqi2008/article/details/50724676，整个过程很顺畅，当然了还需要对自己代码非常熟才行，否则半天都不会定位到问题。
今天是七夕，祝各位程序员早早下班，陪女友吃好喝好玩好为爱鼓掌到天明~~~~
