一 、内存泄漏
于是赶快登陆探测服务器，首先是top free df三连，结果还真发现了些异常。
我们的探测进程CPU占用率特别高，达到了900%。
我们的Java进程，并不做大量CPU运算，正常情况下，CPU应该在100~200%之间，出现这种CPU飙升的情况，要么走到了死循环，要么就是在做大量的GC。
使用jstat -gc pid [interval]命令查看了java进程的GC状态，果然，FULL GC达到了每秒一次。
这么多的FULL GC，应该是内存泄漏没跑了，于是使用jstack pid > jstack.log保存了线程栈的现场，使用jmap -dump:format=b,file=heap.log pid保存了堆现场，然后重启了探测服务，报警邮件终于停止了。
jstat
jstat是一个非常强大的JVM监控工具，一般用法是：jstat [-options] pid interval
它支持的查看项有：
class查看类加载信息
compile编译统计信息
gc垃圾回收信息
gcXXX各区域GC的详细信息，如-gcold
使用它，对定位JVM的内存问题很有帮助。
二、排查
问题虽然解决了，但为了防止它再次发生，还是要把根源揪出来。
分析栈
栈的分析很简单，看一下线程数是不是过多，多数栈都在干嘛。
才四百多线程，并无异常。
线程状态好像也无异常，接下来分析堆文件。
下载堆dump文件
堆文件都是一些二进制数据，在命令行查看非常麻烦，Java为我们提供的工具都是可视化的，Linux服务器上又没法查看，那么首先要把文件下载到本地。
由于我们设置的堆内存为4G，所以dump出来的堆文件也很大，下载它确实非常费事，不过我们可以先对它进行一次压缩。
gzip是个功能很强大的压缩命令，特别是我们可以设置-1-9来指定它的压缩级别，数据越大压缩比率越大，耗时也就越长，推荐使用-67，-9实在是太慢了，且收益不大，有这个压缩的时间，多出来的文件也下载好了。
使用MAT分析jvm heap
MAT是分析Java堆内存的利器，使用它打开我们的堆文件（将文件后缀改为 .hprof）, 它会提示我们要分析的种类，对于这次分析，果断选择memory leak suspect。
从上面的饼图中可以看出，绝大多数堆内存都被同一个内存占用了，再查看堆内存详情，向上层追溯，很快就发现了罪魁祸首。
分析代码
找到内存泄漏的对象了，在项目里全局搜索对象名，它是一个Bean对象，然后定位到它的一个类型为Map的属性。
这个Map根据类型用ArrayList存储了每次探测接口响应的结果，每次探测完都塞到ArrayList里去分析，由于Bean对象不会被回收，这个属性又没有清除逻辑，所以在服务十来天没有上线重启的情况下，这个Map越来越大，直至将内存占满。
内存满了之后，无法再给HTTP响应结果分配内存了，所以一直卡在readLine那。而我们那个大量I/O的接口报警次数特别多，估计跟响应太大需要更多内存有关。
