JAVA内存泄露、溢出的检查方法、工具介绍
问题发现：
在我们运行的一个项目上线运营后发现运行两天左右就会报内存溢出，只有重启tomcat才能恢复服务，异常信息如下：
ng.OutOfMemoryError: GC overhead limit exceeded
ng.OutOfMemoryError: Java heap space
原因分析：
在此之前必须先介绍一下关于jvm的内存控制，JVM即java虚拟机，它运行时候占用一定的内存，其大小是有限定的，如果程序在运行时jvm占用的内存大于某个限度，则会产生内存溢出，也就是“ng.outofmemoryerror”。如果jvm内存的没有限度，并且有无限大的内存，那jvm就永远不会出现内存溢出了。很明显无限的内存是不现实的，但是一般情况下我们程序运行过程所需要的内存应该是一个基础固定的值，如果仅是因为我们的项目所需内存超过了jvm设置内存值导致内存溢出，那么我们可以通过增大jvm的参数设置来解决内存溢出的问题。详细处理可参考java jvm的如下参数设置：-Xms -Xmx -Xmn -Xss
-Xms: 设置JVM初始内存，此值可以设置与-Xmx相同,以避免每次垃圾回收完成后JVM重新分配内存。
-Xmx:设置JVM最大可用内存。
-Xmn:设置年轻代大小，整个堆大小=年轻代大小+年老代大小+持久代大小.持久代一般固定大小为64m,所以增大年轻代后,将会减小年老代大小.此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8.
-Xss:设置每个线程的堆栈大小.在相同物理内存下,减小这个值能生成更多的线程.但是操作系统对一个进程内的线程数还是有限制的,不能无限生成。
在jvm参数调试过程中，发现分配最大内存数超过1G后，仍然会产生内存溢出的现象，而估计其正常分配使用的内存应该不会超过1G，那么由此可以基本断定其存在内存泄露现象，也就是一些原来分配的不再使用的内存不能被java的垃圾回归所回收，导致不断占用原分配的内存而不释放，导致不断申请更多的内存直到超过内存设置而导致内存溢出。
内存泄露的基本原理：
在C++语言程序中，使用new操作符创建的对象，在使用完毕后应该通过delete 操作符显示地释放，否则，这些对象将占用堆空间，永远没有办法得到回收，从而引起内存空间的泄漏。如下的简单代码就可以引起内存的泄漏:
void function(){
Int[] vec = new int[5];
}
在function()方法执行完毕后，vec数组已经是不可达对象，在C++语言中，这样的对象永远也得不到释放，称这种现象为内存泄漏。
而Java是通过垃圾收集器(Garbage Collection，GC)自动管理内存的回收，程序员不需要通过调用函数来释放内存，但它只能回收无用并且不再被其它对象引用的那些对象所占用的空间。在下面的代码中，循环申请Object对象，并将所申请的对象放入一个Vector中，如果仅仅释放对象本身，但是因为Vector仍然引用该对象，所以这个对象对GC来说是不可回收的。因此，如果对象加入到Vector后，还必须从Vector中删除，最简单的方法就是将Vector对象设置为null。
Vector v = new Vector(10);
for (int i = 1; i < 100; i++){
Object o = new Object();
v.add(o);
o = null;
}//此时，所有的Object对象都没有被释放，因为变量v引用这些对象。
实际上无用，而还被引用的对象，GC就无能为力了(事实上GC认为它还有用)，这一点是导致内存泄漏最重要的原因。
而我们的项目可能是存在着内存泄露问题而导致内存溢出。
解决过程：
如何查找引起内存泄漏的原因呢?一般有两种思路:第一种，安排有经验的编程人员对代码进行走查和分析，找出内存泄漏发生的位置;第二种，就是利用一些内存检查分析工具来分析，找出内存泄露的具体位置可以快速解决。
软件测试的理论告诉我们，系统中永远存在一些没有暴露出来的问题，而且，系统的稳定性问题也不仅仅只是内存泄漏的问题，代码走查是提高系统的整体代码质量乃至解决潜在问题的有效手段。但在此仅总结一下本次问题解决所应用的有关内存检查和分析命令以及工具的相关介绍。
第一阶段通过jdk的GC输出进行测试
可以在 JAVA_OPTS增加以下参数打开jdk的GC输出日志：
-verbose:gc -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError
打开输出日志，jdk会在每一次的垃圾回收时打印相关日志，参考格式如下：
[GC [: -> , secs] -> , secs] GC收集器的名称
新生代在GC前占用的内存
新生代在GC后占用的内存
新生代局部收集时jvm暂停处理的时间
JVM Heap 在GC前占用的内存
JVM Heap 在GC后占用的内存
GC过程中jvm暂停处理的总时间
例：[GC [PSYoungGen: 131072K->10667K(152896K)] 137699K->17295K(1551040K), 0.0210980 secs] [Times: user=0.06 sys=0.01, real=0.02 secs]
注意短时间内关注GC的内存回收日志是没有什么作用的，重点需要关注的是Full 级别的新生代和年老代的内存情况。
如下表中，发现年老代内存是不断增长的，基本可以确定是年老代内存泄露，有许多长时间未使用的分配内存得不到回收。
[PSYoungGen: 6735K->0K(152896K)] [PSOldGen: 000000K->6627K(1398144K)] 6735K->6627K(1551040K) [PSPermGen: 17676K->17676K(262144K)], 0.1521720 secs] [Times: user=0.15 sys=0.01, real=0.16 secs] [PSYoungGen: 4754K->0K(153600K)] [PSOldGen: 201914K->86024K(1398144K)] 206668K->86024K(1551744K) [PSPermGen: 33065K->33065K(262144K)], 0.5517640 secs] [Times: user=0.56 sys=0.00, real=0.55 secs] [PSYoungGen: 5495K->0K(164096K)] [PSOldGen: 166076K->99609K(1398144K)] 171571K->99609K(1562240K) [PSPermGen: 33680K->33680K(262144K)], 0.5221250 secs] [Times: user=0.52 sys=0.00, real=0.52 secs] [PSYoungGen: 2584K->0K(164736K)] [PSOldGen: 194684K->76213K(1398144K)] 197268K->76213K(1562880K)
