8、内存泄露和溢出场景及预防措施
内存泄露（memory leak），是指程序在申请内存后，无法释放已申请的内存空间，即分配出去的内存无法回收（不再使用的对象或者变量仍占内存空间），在Java中内存泄漏就是存在一些被分配的对象（可达的，却是无用的）无法被gc回收。
内存溢出（out of memory），是指程序在申请内存时，没有足够的内存空间供其使用，出现out of memory；比如申请了一个integer，但给它存了long才能存下的数，那就是内存溢出。可以看出内存泄漏是内存溢出的一种诱因，但不是唯一因素。
memory leak会最终会导致out of memory！
Java判断内存空间是否符合垃圾回收标准有两个：给对象赋null且不再使用；给对象赋新值，重新分配内存。
内存泄漏的两种情况：一是堆中申请的内存没释放；二是对象已不再使用，但还在内存中保留着。
GC可以有效的解决第一种情况，但是无法保证情况二，所以Java存在的内存泄漏主要是第二种。
以发生的方式来分类，内存泄漏可以分为4类：
1. 常发性内存泄漏。发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄漏。
2. 偶发性内存泄漏。发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。常发性和偶发性是相对的。对于特定的环境，偶发性的也许就变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要。
3. 一次性内存泄漏。发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷，导致总会有一块仅且一块内存发生泄漏。比如，在类的构造函数中分配内存，在析构函数中却没有释放该内存，所以内存泄漏只会发生一次。
4. 隐式内存泄漏。程序在运行过程中不停的分配内存，但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏，因为最终程序释放了所有申请的内存。但是对于一个服务器程序，需要运行几天，几周甚至几个月，不及时释放内存也可能导致最终耗尽系统的所有内存。所以，我们称这类内存泄漏为隐式内存泄漏。
从用户使用程序的角度来看，内存泄漏本身不会产生什么危害，作为一般的用户，根本感觉不到内存泄漏的存在。真正有危害的是内存泄漏的堆积，这会最终消耗尽系统所有的内存。从这个角度来说，一次性内存泄漏并没有什么危害，因为它不会堆积，而隐式内存泄漏危害性则非常大，因为较之于常发性和偶发性内存泄漏它更难被检测到。
Java内存泄漏的根本原因是什么呢？长生命周期的对象持有短生命周期对象的引用就很可能发生内存泄漏，尽管短生命周期对象已经不再需要，但是因为长生命周期持有它的引用而导致不能被回收，这就是Java中内存泄漏的发生场景。
具体主要有如下几大类：
1、静态集合类引起内存泄露：
像HashMap、Vector等的使用最容易出现内存泄露，这些静态变量的生命周期和应用程序一致，他们所引用的所有的对象Object也不能被释放，因为他们也将一直被Vector等引用着。
Static Vector v = new Vector(10);
for (int i = 1; i<100; i++)
{
Object o = newObject();
v.add(o);
o = null;
}
在这个例子中，循环申请Object 对象，并将所申请的对象放入一个Vector 中，如果仅仅释放引用本身（o=null），那么Vector 仍然引用该对象，所以这个对象对GC 来说是不可回收的。因此，如果对象加入到Vector 后，还必须从Vector 中删除，最简单的方法就是将Vector对象设置为null。
2、当集合里面的对象属性被修改后，再调用remove（）方法时不起作用。
public class MainTest
{
public static void main(String[] args)
{
MainTestmain = new MainTest();
Setset = newHashSet<Person>();
Personp1 = main.new Person("唐僧", 25);
Personp2 = main.new Person("孙悟空", 26);
Personp3 = main.new Person("猪八戒", 27);
set.add(p1);
set.add(p2);
set.add(p3);
System.out.println("总共有:" + set.size() + " 个元素!"); // 结果：总共有:3 个元素!
p3.setAge(2); // 修改p3的年龄,此时p3元素对应的hashcode值发生改变
set.remove(p3); // 此时remove不掉，造成内存泄漏
set.add(p3); // 重新添加，居然添加成功
System.out.println("总共有:" + set.size() + " 个元素!"); // 结果：总共有:4 个元素!
}
class Person
{
private String name;
private int age;
publicPerson(String name, int age)
{
super();
this.name = name;
this.age = age;
}
public String getName()
{
return name;
}
public void setName(Stringname)
{
this.name = name;
}
public int getAge()
{
return age;
}
public void setAge(int age)
{
this.age = age;
}
@Override
public String toString()
{
return "Person [name=" + name + ", age=" + age + "]";
}
@Override
public int hashCode()
{
final int prime = 31;
int result = 1;
result = prime * result + getOuterType().hashCode();
result = prime * result + age;
result = prime * result + ((name == null) ? 0 : name.hashCode());
return result;
}
@Override
public booleanequals(Object obj)
{
if (this == obj)
return true;
if (obj == null)
return false;
if (getClass() !=obj.getClass())
return false;
Personother = (Person) obj;
if(!getOuterType().equals(other.getOuterType()))
return false;
if (age != other.age)
return false;
if (name == null)
{
if (other.name != null)
return false;
}
else if (!name.equals(other.name))
return false;
return true;
}
privateMainTest getOuterType()
{
returnMainTest.this;
}
}
}
3、变量不合理的作用域
如果变量的定义范围大于使用范围，并且在使用完后没有赋值为null的话，会出现内存泄露。定义变量的时候，能定义为局部变量就不要定义为成员变量，或者定义为成员变量的话，在使用完变量后，把变量赋值为null。
4、使用非静态内部类
非静态内部类对象的构建依赖于其外部类，内部类对象会持有外部类对象的this引用，即时外部类对象不再被使用了，其占用的内存可能不会被GC回收，因为内部类的生命周期可能比外部类的生命周期要长，从而造成外部类对象不能被及时回收。解决办法是尽量使用静态内部类，静态内部类只是形式上在外部类的里面，静态内部类不会持有外部类的引用，可以把静态内部类理解成是一个独立的类，和外部类没什么关系。
5、单例模式可能会造成内存泄露
单例模式只允许应用程序存在一个实例对象，并且这个实例对象的生命周期和应用程序的生命周期一样长，如果单例对象中拥有另一个对象的引用的话，这个被引用的对象就不能被及时回收。解决办法是单例对象中持有的其他对象使用弱引用，弱引用对象在GC线程工作时，其占用的内存会被回收掉，如下示例：
public class SingleTon1 {
private static finalSingleTon1 mInstance = null;
privateWeakReference mContext;
privateSingleTon1(WeakReference context) {
mContext = context;
}
public static SingleTon1getInstance(WeakReference context) {
if (mInstance ==null) {
synchronized(SingleTon1.class) {
if(mInstance == null) {
mInstance = new SingleTon1(context);
}
}
}
returnmInstance;
}
}
public class MyActivity extents Activity {
public void onCreate(Bundle savedInstanceState){
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
SingleTon1 singleTon1= SingleTon1.getInstance(new WeakReference(this));
}
}
6、监听器
在java 编程中，我们都需要和监听器打交道，通常一个应用当中会用到很多监听器，我们会调用一个控件的诸如addXXXListener()等方法来增加监听器，但往往在释放对象的时候却没有记住去删除这些监听器，从而增加了内存泄漏的机会。
7、各种连接
比如数据库连接（dataSourse.getConnection()），网络连接(socket)和io连接，除非其显式的调用了其close（）方法将其连接关闭，否则是不会自动被GC 回收的。对于Resultset 和Statement 对象可以不进行显式回收，但Connection 一定要显式回收，因为Connection 在任何时候都无法自动回收，而Connection一旦回收，Resultset 和Statement 对象就会立即为NULL。但是如果使用连接池，情况就不一样了，除了要显式地关闭连接，还必须显式地关闭Resultset Statement 对象（关闭其中一个，另外一个也会关闭），否则就会造成大量的Statement 对象无法释放，从而引起内存泄漏。这种情况下一般都会在try里面去的连接，在finally里面释放连接。
如何排查
（1）通过jps查找java进程id。
（2）通过top -p [pid]发现内存占用达到了最大值
（3）jstat -gccause pid 20000 每隔20秒输出Full GC结果
（4）发现Full GC次数太多，基本就是内存泄露了。生成dump文件，借助工具分析是哪个对象太多了。基本能定位到问题在哪。
Full GC的原因
我们知道Full GC的触发条件大致情况有以下几种情况：
1. 程序执行了System.gc() //建议jvm执行fullgc，并不一定会执行
2. 执行了jmap -histo:live pid命令 //这个会立即触发fullgc
3. 在执行minor gc的时候进行的一系列检查
*执行Minor GC的时候，JVM会检查老年代中最大连续可用空间是否大于了当前新生代所有对象的总大小。
*如果大于，则直接执行Minor GC（这个时候执行是没有风险的）。
*如果小于了，JVM会检查是否开启了空间分配担保机制，如果没有开启则直接改为执行Full GC。
*如果开启了，则JVM会检查老年代中最大连续可用空间是否大于了历次晋升到老年代中的平均大小，如果小于则执行改为执行Full GC。
*如果大于则会执行Minor GC，如果Minor GC执行失败则会执行Full GC
对于我们的情况，可以初步排除1，2两种情况，最有可能是4和5这两种情况。为了进一步排查原因，我们在线上开启了 -XX:+HeapDumpBeforeFullGC。
注意：
JVM在执行dump操作的时候是会发生stop the word事件的，也就是说此时所有的用户线程都会暂停运行。
为了在此期间也能对外正常提供服务，建议采用分布式部署，并采用合适的负载均衡算法。
内存溢出种类：
引起内存溢出的原因有很多种，常见的有以下几种：
1.内存中加载的数据量过于庞大，如一次从数据库取出过多数据；
2.集合类中有对对象的引用，使用完后未清空，使得JVM不能回收；
3.代码中存在死循环或循环产生过多重复的对象实体；
4.使用的第三方软件中的BUG；
5.启动参数内存值设定的过小
内存溢出的解决方案：
第一步，修改JVM启动参数，直接增加内存。(-Xms，-Xmx参数一定不要忘记加。)
第二步，检查错误日志，查看“OutOfMemory”错误前是否有其它异常或错误。
第三步，对代码进行走查和分析，找出可能发生内存溢出的位置。
重点排查以下几点：
1.检查对数据库查询中，是否有一次获得全部数据的查询。一般来说，如果一次取十万条记录到内存，就可能引起内存溢出。这个问题比较隐蔽，在上线前，数据库中数据较少，不容易出问题，上线后，数据库中数据多了，一次查询就有可能引起内存溢出。因此对于数据库查询尽量采用分页的方式查询。
2.检查代码中是否有死循环或递归调用。
3.检查是否有大循环重复产生新对象实体。
4.检查对数据库查询中，是否有一次获得全部数据的查询。一般来说，如果一次取十万条记录到内存，就可能引起内存溢出。这个问题比较隐蔽，在上线前，数据库中数据较少，不容易出问题，上线后，数据库中数据多了，一次查询就有可能引起内存溢出。因此对于数据库查询尽量采用分页的方式查询。
5.检查List、MAP等集合对象是否有使用完后，未清除的问题。List、MAP等集合对象会始终存有对对象的引用，使得这些对象不能被GC回收。
第四步，使用内存查看工具动态查看内存使用情况
内存不同区域溢出情况：
1，堆内存溢出
场景：
1）设置的jvm内存太小，对象所需内存太大，创建对象时分配空间，就会抛出这个异常。
堆内存中主要存放对象、数组等，只要不断地创建这些对象，并且保证GC Roots到对象之间有可达路径来避免垃圾收集回收机制清除这些对象，当这些对象所占空间超过最大堆容量时，就会产生java.lang.OutOfMemoryError:Java heap space的异常。
2）流量/数据峰值，应用程序自身的处理存在一定的限额，比如一定数量的用户或一定数量的数据。而当用户数量或数据量突然激增并超过预期的阈值时，那么就会在峰值停止前正常运行的操作将停止并触发java . lang.OutOfMemoryError:Java heap space错误。
堆内存异常示例如下：
/**
*设置最大堆最小堆：-Xms20m -Xmx20m
*运行时，不断在堆中创建OOMObject类的实例对象，且while执行结束之前，GC Roots(代码中的oomObjectList)到对象(每一个OOMObject对象)之间有可达路径，垃圾收集器就无法回收它们，最终导致内存溢出。
*/
public class HeapOOM {
static class OOMObject {
}
public static voidmain(String[] args) {
List oomObjectList = new ArrayList<>();
while (true) {
oomObjectList.add(new OOMObject());
}
}
}
运行后会报异常，在堆栈信息中可以看到 java.lang.OutOfMemoryError: Java heap space 的信息，说明在堆内存空间产生内存溢出的异常。
常见的原因 ：
内存加载的数据量太大：一次性从数据库取太多数据
集合类中有对对象的引用，使用后未清空，GC不能进行回收。
代码中存在循环产生过多的重复对象
启动参数堆内存值小
解决方法：
首先，如果代码没有什么问题的情况下，可以适当调整-Xms和-Xmx两个jvm参数，使用压力测试来调整这两个参数达到最优值。
其次，尽量避免大的对象的申请，像文件上传，大批量从数据库中获取，这是需要避免的，尽量分块或者分批处理，有助于系统的正常稳定的执行。
最后，尽量提高一次请求的执行速度，垃圾回收越早越好，否则，大量的并发来了的时候，再来新的请求就无法分配内存了，就容易造成系统的雪崩。
2，虚拟机栈/本地方法栈溢出
（1）StackOverflowError：当线程请求的栈的深度大于虚拟机所允许的最大深度，则抛出StackOverflowError，简单理解就是虚拟机栈中的栈帧数量过多（一个线程嵌套调用的方法数量过多）时，就会抛出StackOverflowError异常。最常见的场景就是方法无限递归调用，
如下：
/**
*设置每个线程的栈大小：-Xss256k
*运行时，不断调用doSomething()方法，main线程不断创建栈帧并入栈，导致栈的深度越来越大，最终导致栈溢出。
*/
public class StackSOF {
private intstackLength=1;
public void doSomething(){
stackLength++;
doSomething();
}
public static voidmain(String[] args) {
StackSOFstackSOF=new StackSOF();
try {
stackSOF.doSomething();
}catch (Throwablee){//注意捕获的是Throwable
System.out.println("栈深度："+stackSOF.stackLength);
throw e;
}
}
}
上述代码执行后抛出：Exception in thread “Thread-0” java.lang.StackOverflowError的异常。
常见原因：
栈内存溢出，一般由栈内存的局部变量过爆了，导致内存溢出，出现在递归方法，参数个数过多，递归过深，递归没有出口。
（2）OutOfMemoryError：如果虚拟机在扩展栈时无法申请到足够的内存空间，则抛出OutOfMemoryError。我们可以这样理解，虚拟机中可以供栈占用的空间≈可用物理内存 - 最大堆内存 - 最大方法区内存，比如一台机器内存为4G，系统和其他应用占用2G，虚拟机可用的物理内存为2G，最大堆内存为1G，最大方法区内存为512M，那可供栈占有的内存大约就是512M，假如我们设置每个线程栈的大小为1M，那虚拟机中最多可以创建512个线程，超过512个线程再创建就没有空间可以给栈了，就报OutOfMemoryError异常了。
栈上能够产生OutOfMemoryError的示例如下：
/**
*设置每个线程的栈大小：-Xss2m
*运行时，不断创建新的线程（且每个线程持续执行），每个线程对一个一个栈，最终没有多余的空间来为新的线程分配，导致OutOfMemoryError
*/
public class StackOOM {
private static intthreadNum = 0;
public voiddoSomething() {
try {
Thread.sleep(100000000);
} catch(InterruptedException e) {
e.printStackTrace();
}
}
public static voidmain(String[] args) {
final StackOOMstackOOM = new StackOOM();
try {
while (true) {
threadNum++;
Threadthread = new Thread(new Runnable() {
@Override
publicvoid run() {
stackOOM.doSomething();
}
});
thread.start();
}
} catch (Throwablee) {
System.out.println("目前活动线程数量：" + threadNum);
throw e;
}
}
}
上述代码运行后会报异常，在堆栈信息中可以看到 java.lang.OutOfMemoryError: unable to create new native thread的信息，无法创建新的线程，说明是在扩展栈的时候产生的内存溢出异常。
总结：在线程较少的时候，某个线程请求深度过大，会报StackOverflow异常，解决这种问题可以适当加大栈的深度（增加栈空间大小），也就是把-Xss的值设置大一些，但一般情况下是代码问题的可能性较大；在虚拟机产生线程时，无法为该线程申请栈空间了，会报OutOfMemoryError异常，解决这种问题可以适当减小栈的深度，也就是把-Xss的值设置小一些，每个线程占用的空间小了，总空间一定就能容纳更多的线程，但是操作系统对一个进程的线程数有限制，经验值在3000~5000左右。在jdk1.5之前-Xss默认是256k，jdk1.5之后默认是1M，这个选项对系统硬性还是蛮大的，设置时要根据实际情况，谨慎操作。
3，方法区溢出
前面说到，方法区主要用于存储虚拟机加载的类信息、常量、静态变量，以及编译器编译后的代码等数据，所以方法区溢出的原因就是没有足够的内存来存放这些数据。
由于在jdk1.6之前字符串常量池是存在于方法区中的，所以基于jdk1.6之前的虚拟机，可以通过不断产生不一致的字符串（同时要保证和GC Roots之间保证有可达路径）来模拟方法区的OutOfMemoryError异常；但方法区还存储加载的类信息，所以基于jdk1.7的虚拟机，可以通过动态不断创建大量的类来模拟方法区溢出。
/**
*设置方法区最大、最小空间：-XX:PermSize=10m -XX:MaxPermSize=10m
*运行时，通过cglib不断创建JavaMethodAreaOOM的子类，方法区中类信息越来越多，最终没有可以为新的类分配的内存导致内存溢出
*/
public class JavaMethodAreaOOM {
public static voidmain(final String[] args){
try {
while (true){
Enhancerenhancer=new Enhancer();
enhancer.setSuperclass(JavaMethodAreaOOM.class);
enhancer.setUseCache(false);
enhancer.setCallback(newMethodInterceptor() {
@Override
publicObject intercept(Object o, Method method, Object[] objects, MethodProxymethodProxy) throws Throwable {
return methodProxy.invokeSuper(o,objects);
}
});
enhancer.create();
}
}catch (Throwable t){
t.printStackTrace();
}
}
}
上述代码运行后会报“java.lang.OutOfMemoryError: PermGen space”的异常，说明是在方法区出现了内存溢出的错误。
4，Metaspace内存溢出
问题描述：
元空间的溢出，系统会抛出java.lang.OutOfMemoryError: Metaspace。出现这个异常的问题的原因是系统的代码非常多或引用的第三方包非常多或者通过动态代码生成类加载等方法，导致元空间的内存占用很大。
以下是用循环动态生成class的方式来模拟元空间的内存溢出的。
解决方法：
默认情况下，元空间的大小仅受本地内存限制。但是为了整机的性能，尽量还是要对该项进行设置，以免造成整机的服务停机。
1）优化参数配置，避免影响其他JVM进程
-XX:MetaspaceSize，初始空间大小，达到该值就会触发垃圾收集进行类型卸载，同时GC会对该值进行调整：如果释放了大量的空间，就适当降低该值；如果释放了很少的空间，那么在不超过MaxMetaspaceSize时，适当提高该值。
-XX:MaxMetaspaceSize，最大空间，默认是没有限制的。
除了上面两个指定大小的选项以外，还有两个与 GC 相关的属性：
-XX:MinMetaspaceFreeRatio，在GC之后，最小的Metaspace剩余空间容量的百分比，减少为分配空间所导致的垃圾收集 。
-XX:MaxMetaspaceFreeRatio，在GC之后，最大的Metaspace剩余空间容量的百分比，减少为释放空间所导致的垃圾收集。
2）慎重引用第三方包
对第三方包，一定要慎重选择，不需要的包就去掉。这样既有助于提高编译打包的速度，也有助于提高远程部署的速度。
3）关注动态生成类的框架
对于使用大量动态生成类的框架，要做好压力测试，验证动态生成的类是否超出内存的需求会抛出异常。
5，本机直接内存溢出
本机直接内存（DirectMemory）并不是虚拟机运行时数据区的一部分，也不是Java虚拟机规范中定义的内存区域，但Java中用到NIO相关操作时（比如ByteBuffer的allocteDirect方法申请的是本机直接内存），也可能会出现java.lang.OutOfMemoryError:Direct buffer memory异常。
如果你在直接或间接使用了ByteBuffer中的allocateDirect方法的时候，而不做clear的时候就会出现类似的问题。
解决方法：如果经常有类似的操作，可以考虑设置参数：-XX:MaxDirectMemorySize，并及时clear内存。
6，栈内存溢出
问题描述
当一个线程执行一个Java方法时，JVM将创建一个新的栈帧并且把它push到栈顶。此时新的栈帧就变成了当前栈帧，方法执行时，使用栈帧来存储参数、局部变量、中间指令以及其他数据。
当一个方法递归调用自己时，新的方法所产生的数据(也可以理解为新的栈帧)将会被push到栈顶，方法每次调用自己时，会拷贝一份当前方法的数据并push到栈中。因此，递归的每层调用都需要创建一个新的栈帧。这样的结果是，栈中越来越多的内存将随着递归调用而被消耗，如果递归调用自己一百万次，那么将会产生一百万个栈帧。这样就会造成栈的内存溢出StackOverflowError。
解决方法：
如果程序中确实有递归调用，出现栈溢出时，可以调高-Xss大小，就可以解决栈内存溢出的问题了。递归调用防止形成死循环，否则就会出现栈内存溢出。
Full GC分析定位过程：
1，如何发现是否发生FULL GC和FULL GC是否频繁
使用JDK自带的轻量级小工具jstat
语法结构：
Usage: jstat -help|-options
jstat- [-t] [-h] [[]]
参数解释：
Options — 选项，我们一般使用 -gcutil 查看gc情况
vmid — VM的进程号，即当前运行的java进程号
interval– 间隔时间，单位为秒或者毫秒
count —打印次数，如果缺省则打印无数次
比如/opt/taobao/java/bin/jstat –gcutil pid 5000
输出结果：
S0 S1 E O P YGC YGCT FGC FGCT GCT
0.00 90.63 100.00 58.82 3.51 183 2.059 0 0.000 2.059
0.00 15.48 7.80 60.99 3.51 185 2.092 1 0.305 2.397
0.00 15.48 18.10 47.90 3.51 185 2.092 2 0.348 2.440
S0 — Heap上的 Survivor space 0 区已使用空间的百分比
S1 — Heap上的 Survivor space 1 区已使用空间的百分比
E — Heap上的 Eden space 区已使用空间的百分比
O — Heap上的 Old space 区已使用空间的百分比
P — Perm space区已使用空间的百分比
YGC — 从应用程序启动到采样时发生 Young GC 的次数
YGCT– 从应用程序启动到采样时 Young GC 所用的时间(单位秒)
FGC — 从应用程序启动到采样时发生 Full GC 的次数
FGCT– 从应用程序启动到采样时 Full GC 所用的时间(单位秒)
GCT — 从应用程序启动到采样时用于垃圾回收的总时间(单位秒)
通过FGC我们可以发现系统是否发生FULL GC和FULL GC的频率
2，FULL GC分析和问题定位
a. GC log收集和分析
(1)在JVM启动参数增加："-verbose:gc-Xloggc: -XX:+PrintGCDetails -XX:+PrintGCDateStamps"
PrintGCTimeStamp只能获得相对时间，建议使用PrintGCDateStamps获得full gc 发生的绝对时间
(2)如果采用CMS GC,仔细分析jstat FGC输出和GC 日志会发现， CMS的每个并发GC周期则有两个stop-the-world阶段——initial mark与final re-mark，使得CMS的每个并发GC周期总共会更新full GC计数器两次，initial mark与final re-mark各一次
b. Dump JVM 内存快照
/opt/taobao/java/bin/jmap -dump:format=b,file=dump.bin pid
这里有一个问题是什么时候进行dump?
一种方法是前面提到的用jstat工具观察，当OLD区到达比较高的比例如60%，一般会很快触发一次FULL GC,可以进行一次DUMP,在FULL GC发生以后再DUMP一次，这样比较就可以发现到底是哪些对象导致不停的FULL GC
另外一种方法是通过配置JVM参数
-XX:+HeapDumpBeforeFullGC -XX:+HeapDumpAfterFullGC分别用于指定在full GC之前与之后生成heap dump
c. 利用MAT((Memory
Analyzer Tool)工具分析dump文件
关于MAT具体使用方法网上有很多介绍，这里不做详细展开，这里需要注意的是：
(1) MAT缺省只分析reachable的对象，unreachable的对象（将被收集掉的对象）被忽略，而分析FULL GC频繁原因时unreachable
object也应该同时被重点关注。如果要显示unreachable的对象细节必须用mat 1.1以上版本并且打开选项“keep unreachable object”
(2) 通常dump文件会好几个G，无法在windows上直接进行分析，我们可以先把dump文件在linux上进行分析，再把分析好的文件拷贝到windows上，在windows上用MAT打开分析文件。
内存泄露主要有如下几大类：
1）静态集合类引起内存泄漏：
像HashMap、Vector等的使用最容易出现内存泄露，这些静态变量的生命周期和应用程序一致，他们所引用的所有的对象Object也不能被释放，因为他们也将一直被Vector等引用着。
static Vector v = new Vector();
for (int i = 1; i<100; i++)
{
Object o = new Object();
v.add(o);
o = null;
}
在这个例子中，代码栈中存在Vector 对象的引用 v 和 Object 对象的引用 o 。在 For 循环，我们不断的生成新的对象，然后将其添加到 Vector 对象中，之后将 o 引用置空。问题是当 o 引用被置空后，如果发生 GC，我们创建的 Object 对象是否能够被 GC 回收呢？答案是否定的。因为， GC 在跟踪代码栈中的引用时，会发现 v 引用，而继续往下跟踪，就会发现 v 引用指向的内存空间中又存在指向 Object 对象的引用。也就是说尽管o 引用已经被置空，但是 Object 对象仍然存在其他的引用，是可以被访问到的，所以 GC 无法将其释放掉。如果在此循环之后， Object 对象对程序已经没有任何作用，那么我们就认为此 Java 程序发生了内存泄漏。
2）当集合里面的对象属性被修改后，再调用remove()方法时不起作用。
public static void main(String[] args)
{
Set set =new HashSet();
Person p1 = newPerson("唐僧","pwd1",25);
Person p2 = newPerson("孙悟空","pwd2",26);
Person p3 = newPerson("猪八戒","pwd3",27);
set.add(p1);
set.add(p2);
set.add(p3);
System.out.println("总共有:"+set.size()+"个元素!"); //结果：总共有:3 个元素!
p3.setAge(2); //修改p3的年龄,此时p3元素对应的hashcode值发生改变
set.remove(p3); //此时remove不掉，造成内存泄漏
set.add(p3); //重新添加，居然添加成功
System.out.println("总共有:"+set.size()+"个元素!"); //结果：总共有:4 个元素!
for (Person person :set)
{
System.out.println(person);
}
}
3）各种连接
比如数据库连接（dataSourse.getConnection()），网络连接(socket)和io连接，除非其显式的调用了其close（）方法将其连接关闭，否则是不会自动被GC回收的。对于Resultset和Statement 对象可以不进行显式回收，但Connection一定要显式回收，因为Connection 在任何时候都无法自动回收，而Connection一旦回收，Resultset和Statement 对象就会立即为null。但是如果使用连接池，情况就不一样了，除了要显式地关闭连接，还必须显式地关闭Resultset Statement 对象（关闭其中一个，另外一个也会关闭），否则就会造成大量的Statement 对象无法释放，从而引起内存泄漏。这种情况下一般都会在try里面去的连接，在finally里面释放连接。
4）内部类和外部模块的引用
内部类的引用是比较容易遗忘的一种，而且一旦没释放可能导致一系列的后继类对象没有释放。此外程序员还要小心外部模块不经意的引用，例如程序员A负责A模块，调用了B模块的一个方法如：
public void registerMsg(Object b);
这种调用就要非常小心了，传入了一个对象，很可能模块B就保持了对该对象的引用，这时候就需要注意模块B 是否提供相应的操作去除引用。
5）单例模式
不正确使用单例模式是引起内存泄漏的一个常见问题，单例对象在初始化后将在JVM的整个生命周期中存在（以静态变量的方式），如果单例对象持有外部的引用，那么这个对象将不能被JVM正常回收，导致内存泄漏，考虑下面的例子：
class A{
public A(){
B.getInstance().setA(this);
}
....
}
//B类采用单例模式
class B{
private A a;
private static Binstance=new B();
public B(){}
public static BgetInstance(){
return instance;
}
public void setA(A a){
this.a=a;
}
//getter...
}
显然B采用singleton模式，它持有一个A对象的引用，而这个A类的对象将不能被回收。
6）监听器
在java编程中，我们都需要和监听器打交道，通常一个应用当中会用到很多监听器，我们会调用一个控件的诸如addXXXListener()等方法来增加监听器，但往往在释放对象的时候却没有记住去删除这些监听器，从而增加了内存泄漏的机会。
ThreadLocal 内存泄漏问题
ThreadLocal的实现是这样的：每个Thread 维护一个 ThreadLocalMap映射表，这个映射表的 key 是 ThreadLocal实例本身，value 是真正需要存储的 Object。
也就是说 ThreadLocal 本身并不存储值，它只是作为一个 key 来让线程从 ThreadLocalMap获取 value。值得注意的是图中的虚线，表示 ThreadLocalMap 是使用 ThreadLocal 的弱引用作为 Key 的，弱引用的对象在 GC 时会被回收。
ThreadLocal为什么会内存泄漏
ThreadLocalMap使用ThreadLocal的弱引用作为key，通常弱引用都会和引用队列配合清理机制使用，但是ThreadLocalMap是个例外，它并没有这么做。这意味着，废弃项目的回收依赖于显式的触发，否则就要等线程结束，今儿回收相应的ThreadLocalMap。如果一个ThreadLocal没有外部强引用来引用它，那么系统 GC 的时候，这个ThreadLocal势必会被回收，这样一来，ThreadLocalMap中就会出现key为null的Entry，就没有办法访问这些key为null的Entry的value，如果当前线程再迟迟不结束的话，这些key为null的Entry的value就会一直存在一条强引用链：Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value永远无法回收，造成内存泄漏。
其实，ThreadLocalMap的设计中已经考虑到这种情况，也加上了一些防护措施：在ThreadLocal的get(),set(),remove()的时候都会清除线程ThreadLocalMap里所有key为null的value。
但是这些被动的预防措施并不能保证不会内存泄漏：
使用static的ThreadLocal，延长了ThreadLocal的生命周期，可能导致的内存泄漏（参考ThreadLocal 内存泄露的实例分析）。
分配使用了ThreadLocal又不再调用get(),set(),remove()方法，那么就会导致内存泄漏。
综合上面的分析，我们可以理解ThreadLocal内存泄漏的前因后果，那么怎么避免内存泄漏呢？
每次使用完ThreadLocal，都调用它的remove()方法，清除数据。
在使用线程池的情况下，没有及时清理ThreadLocal，不仅是内存泄漏的问题，更严重的是可能导致业务逻辑出现问题。所以，使用ThreadLocal就跟加锁完要解锁一样，用完就清理。
参考书目：《深入理解JVM虚拟机》、《Java性能调优指南》
