Java虚拟机(六)——内存溢出和内存泄露分析

关于内存溢出和内存泄露在我以前的博文Java 内存溢出（java.lang.OutOfMemoryError）的常见情况和处理方式中做过大概介绍，此处在进行补充。
1、内存溢出
内存溢出：OOM（OutOfMemoryError）异常，即程序需要内存超出了虚拟机可以分配内存的最大范围。在Java 虚拟机规范的描述中，除了程序计数器外，虚拟机内存的其他区域都可能发生异常。

2、内存溢出区域
常见的内存溢出分为以下几种：
2.1 Java堆溢出
Java 堆用于存储对象实例，只要不断地创建对象，并且保证垃圾回收机制清除这些对象，那么在对象数量达到最大堆限制就会产生内存溢出异常。

测试方案：无限循环new对象实例出来，在List中保存引用，防止GC回收，最终会产生OOM ,异常堆栈信息并提示Java heap space。

2.2 虚拟机栈和本地方法栈溢出
关于虚拟机栈和本地方法栈，Java虚拟机规范中定义了两种异常：
如果线程请求的栈深度大于虚拟机所允许的最大深度，将抛出StackOverflowError 异常。
如果虚拟机在扩展栈时无法申请到足够的内存空间，则抛出OutOfMemoryError异常。
测试方案： 单线程条件下，通过不断递归调用方法，如不断累加的方法，如下所示：

public class JavaVMStackSOF{    private int stackLength=1;    public void stackLeak(){        stackLength++;//累加变量        stackLeak();//调用自身    }}

最终会产生StackOverflowError栈溢出异常；

多线程条件下，无限循环地创建线程，并为每个线程无限循环的增加内存，最终会导致OutOfMemoryError异常。

这里有一点要重点说明，在多线程情况下，给每个线程的栈分配的内存越大，反而越容易产生内存产生内存溢出一场。操作系统为每个进程分配的内存是有限制的，虚拟机提供了参数来控制Java堆和方法区这两部分内存的最大值，忽略掉程序计数器消耗的内存（很小），以及进程本身消耗的内存，剩下的内存便给了虚拟机栈和本地方法栈，每个线程分配到的栈容量越大，可以建立的线程数量自然就越少。因此，如果是建立过多的线程导致的内存溢出，在不能减少线程数的情况下，就只能通过减少最大堆和每个线程的栈容量来换取更多的线程。

2.3 方法区和运行时常量池溢出
运行时常量池是方法区的一部分。方法区用于存放Class的相关信息，如类名，访问修饰符，常量池，字段描述，方法描述等。测试方法：
（1）对于非常量池部分，运行时生成大量的动态类填满方法区;
（2）对于常量池部分，无限循环调用String的intern()方法产生不同的String对象实例，并在List中保存其引用，以防止被GC回收，最终会产生溢出。

2.4 本机直接内存溢出
此类内存溢出一个明显的特征是在Heap Dump文件中不会看见明显的异常，如果发现OOM之后Dump文件很小，而程序中又直接或间接使用了NIO,可以考虑一下是不是这方面原因。

3、内存泄露
内存泄漏是指无用对象（不再使用的对象）持续占有内存或无用对象的内存得不到及时释放，从而造成内存空间的浪费称为内存泄漏。内存泄露有时不严重且不易察觉，这样开发者就不知道存在内存泄露，但有时也会很严重，会提示你OOM。
Java内存泄漏的根本原因是长生命周期的对象持有短生命周期对象的引用就很可能发生内存泄漏，尽管短生命周期对象已经不再需要，但是因为长生命周期持有它的引用而导致不能被回收。

3.1 内存泄露场景：具体主要有如下几大类：

3.1.1 静态集合类引起内存泄漏
像HashMap、Vector等的使用最容易出现内存泄露，这些静态变量的生命周期和应用程序一致，他们所引用的所有的对象Object也不能被释放，因为他们也将一直被Vector等引用着。

Static Vector v = new Vector(10);for (int i = 1; i<100; i++){    Object o = new Object();    v.add(o);    o = null;}

在这个例子中，循环申请Object 对象，并将所申请的对象放入一个Vector 中，如果仅仅释放引用本身（o=null），那么Vector 仍然引用该对象，所以这个对象对GC 来说是不可回收的。因此，如果对象加入到Vector 后，还必须从Vector 中删除，最简单的方法就是将Vector对象设置为null。

3.1.2 集合里面的对象属性被修改，再调用remove()方法不生效，如：

public static void main(String[] args){    Set<Person> set = new HashSet<Person>();    Person p1 = new Person("唐僧","pwd1",25);    Person p2 = new Person("孙悟空","pwd2",26);    Person p3 = new Person("猪八戒","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.1.3 监听器
在java 编程中，我们都需要和监听器打交道，通常一个应用当中会用到很多监听器，我们会调用一个控件的诸如addXXXListener()等方法来增加监听器，但往往在释放对象的时候却没有记住去删除这些监听器，从而增加了内存泄漏的机会。

3.1.4 各种连接
比如数据库连接（dataSourse.getConnection()），网络连接(socket)和io连接，除非其显式的调用了其close（）方法将其连接关闭，否则是不会自动被GC 回收的。对于Resultset 和Statement 对象可以不进行显式回收，但Connection 一定要显式回收，因为Connection 在任何时候都无法自动回收，而Connection一旦回收，Resultset 和Statement 对象就会立即为NULL。但是如果使用连接池，情况就不一样了，除了要显式地关闭连接，还必须显式地关闭Resultset Statement 对象（关闭其中一个，另外一个也会关闭），否则就会造成大量的Statement 对象无法释放，从而引起内存泄漏。这种情况下一般都会在try里面去的连接，在finally里面释放连接。

3.1.5 内部类和外部模块的引用
内部类的引用是比较容易遗忘的一种，而且一旦没释放可能导致一系列的后继类对象没有释放。此外程序员还要小心外部模块不经意的引用，例如程序员A 负责A 模块，调用了B 模块的一个方法如： public void registerMsg(Object b); 这种调用就要非常小心了，传入了一个对象，很可能模块B就保持了对该对象的引用，这时候就需要注意模块B 是否提供相应的操作去除引用。

3.1.6 单例模式
不正确使用单例模式是引起内存泄漏的一个常见问题，单例对象在初始化后将在JVM的整个生命周期中存在（以静态变量的方式），如果单例对象持有外部的引用，那么这个对象将不能被JVM正常回收，导致内存泄漏，考虑下面的例子：

class A{    public A(){        B.getInstance().setA(this);    }    ....}//B类采用单例模式class B{    private A a;    private static B instance=new B();    public B(){}    public static B getInstance(){        return instance;    }    public void setA(A a){     this.a=a;    }    //getter...} 

显然B采用singleton模式，它持有一个A对象的引用，而这个A类的对象将不能被回收。想象下如果A是个比较复杂的对象或者集合类型会发生什么情况。