内存溢出&内存泄露

一、概念

内存溢出：简单地说内存溢出就是指程序运行过程中申请的内存大于系统能够提供的内存，导致无法申请到足够的内存，于是就发生了内存溢出。
内存泄漏：内存泄漏指程序运行过程中分配内存给临时变量，用完之后却没有被GC回收，始终占用着内存，既不能被使用也不能分配给其他程序，于是就发生了内存泄漏。
内存溢出 out of memory，是指程序在申请内存时，没有足够的内存空间供其使用，出现out of memory；
内存泄露 memory leak，是指程序在申请内存后，无法释放已申请的内存空间，一次内存泄露危害可以忽略，但内存泄露堆积后果很严重，无论多少内存，迟早会被占光。
memory leak会最终会导致out of memory！

二、内存溢出的常见情况

1、java.lang.OutOfMemoryError: PermGen space (持久带溢出)

我们知道jvm通过持久带实现了java虚拟机规范中的方法区，而运行时常量池就是保存在方法区中的，因此发生这种溢出可能是运行时常量池溢出，或是由于程序中使用了大量的jar或class，使得方法区中保存的class对象没有被及时回收或者class信息占用的内存超过了配置的大小。

2、java.lang.OutOfMemoryError: Java heap space (堆溢出)

发生这种溢出的原因一般是创建的对象太多，在进行垃圾回收之前对象数量达到了最大堆的容量限制。
解决这个区域异常的方法一般是通过内存映像分析工具对Dump出来的堆转储快照进行分析，看到底是内存溢出还是内存泄漏。如果是内存泄漏，可进一步通过工具查看泄漏对象到GC Roots的引用链，定位出泄漏代码的位置，修改程序或算法；如果不存在泄漏，就是说内存中的对象确实都还必须存活，那就应该检查虚拟机的堆参数-Xmx(最大堆大小)和-Xms(初始堆大小)，与机器物理内存对比看是否可以调大。

3、虚拟机栈和本地方法栈溢出

如果线程请求的栈深度大于虚拟机所允许的最大深度，将抛出StackOverflowError。
如果虚拟机在扩展栈时无法申请到足够的内存空间，则抛出OutOfMemoryError。

三、内存泄露

内存泄漏的根本原因是长生命周期的对象持有短生命周期对象的引用，尽管短生命周期的对象已经不再需要，但由于长生命周期对象持有它的引用而导致不能被回收。
以发生的方式来分类，内存泄漏可以分为4类：

• 1、常发性内存泄漏。发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄漏。
• 2、偶发性内存泄漏。发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。常发性和偶发性是相对的。对于特定的环境，偶发性的也许就变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要。
• 3、一次性内存泄漏。发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷，导致总会有一块仅且一块内存发生泄漏。比如，在类的构造函数中分配内存，在析构函数中却没有释放该内存，所以内存泄漏只会发生一次。
• 4、隐式内存泄漏。程序在运行过程中不停的分配内存，但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏，因为最终程序释放了所有申请的内存。但是对于一个服务器程序，需要运行几天，几周甚至几个月，不及时释放内存也可能导致最终耗尽系统的所有内存。所以，我们称这类内存泄漏为隐式内存泄漏。

从用户使用程序的角度来看，内存泄漏本身不会产生什么危害，作为一般的用户，根本感觉不到内存泄漏的存在。真正有危害的是内存泄漏的堆积，这会最终消耗尽系统所有的内存。从这个角度来说，一次性内存泄漏并没有什么危害，因为它不会堆积，而隐式内存泄漏危害性则非常大，因为较之于常发性和偶发性内存泄漏它更难被检测到。

下面总结几种常见的内存泄露：

1、静态集合类引起的类存泄露

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

public class Test01 {
   public static void main(String[] args) {
      Vector<Object> v = new Vector<Object>(100);
      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。

2、修改HashSet中对象的参数值，且参数时计算哈希值的字段

当一个对象被存储到HashSet集合中以后，修改了这个对象中那些参与计算哈希值的字段后，这个对象的哈希值与最初存储在集合中的就不同了，这种情况下，用contains方法在集合中检索对象是找不到的，这将会导致无法从HashSet中删除当前对象，造成内存泄漏，举例如下：

public class Test02 {
   public static void main(String[] args) {
      Set<Person> set = new HashSet<Person>();
      Person p1 = new Person("张三","1",25);
      Person p2 = new Person("李四","2",26);
      Person p3 = new Person("王五","3",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);
      }
   }
}
//需要重写hashCode方法，默认的实现并不会有如下效果
public class Person {
   private String name;
   private String no;
   private int age;

   public Person(String name, String no, int age) {
      this.name = name;
      this.no = no;
      this.age = age;
   }
   
   @Override
   public boolean equals(Object o) {
      if (this == o) return true;
      if (!(o instanceof Person)) return false;

      Person person = (Person) o;

      if (getAge() != person.getAge()) return false;
      if (getName() != null ? !getName().equals(person.getName()) : person.getName() != null) return false;
      return getNo() != null ? getNo().equals(person.getNo()) : person.getNo() == null;
   }

   @Override
   public int hashCode() {
      int result = getName() != null ? getName().hashCode() : 0;
      result = 31 * result + (getNo() != null ? getNo().hashCode() : 0);
      result = 31 * result + getAge();
      return result;
   }
}

3、监听器

在java 编程中，我们都需要和监听器打交道，通常一个应用当中会用到很多监听器，我们会调用一个控件的诸如addXXXListener()等方法来增加监听器，但往往在释放对象的时候却没有记住去删除这些监听器，从而增加了内存泄漏的机会。

4、各种连接

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

5、单例模式

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

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

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

避免内存泄露的几点建议：

• 1、尽早释放无用对象的引用。
• 2、避免在循环中创建对象。
• 3、使用字符串处理时避免使用String，应使用StringBuffer。
• 4、尽量少使用静态变量，因为静态变量存放在永久代，基本不参与垃圾回收。

四、常见的几种内存溢出及解决方法

1、JVM Heap（堆）溢出：java.lang.OutOfMemoryError: Java heap space

JVM在启动的时候会自动设置JVM Heap的值， 可以利用JVM提供的-Xmn -Xms -Xmx等选项可进行设置。Heap的大小是Young Generation 和Tenured Generaion 之和。在JVM中如果98%的时间是用于GC,且可用的Heap size 不足2%的时候将抛出此异常信息。
解决方法：手动设置JVM Heap（堆）的大小。
Java堆用于储存对象实例。当需要为对象实例分配内存，而堆的内存占用又已经达到-Xmx设置的最大值。将会抛出OutOfMemoryError异常。

/**
 * VM Args: -Xms5m -Xmx5m
 */
public class HeapOOM {
   public static void main(String[] args) {
      int count = 0;
      List<Object> list = new ArrayList<Object>();
      while(true){
         list.add(new Object());
         System.out.println(++count);
      }
   }
}

2、PermGen space 溢出： java.lang.OutOfMemoryError: PermGen space

PermGen space的全称是Permanent Generation space，是指内存的永久保存区域。为什么会内存溢出，这是由于这块内存主要是被JVM存放Class和Meta信息的，Class在被Load的时候被放入PermGen space区域，它和存放Instance的Heap区域不同，sun的 GC不会在主程序运行期对PermGen space进行清理，所以如果你的APP会载入很多CLASS的话，就很可能出现PermGen space溢出。一般发生在程序的启动阶段。
解决方法： 通过-XX:PermSize和-XX:MaxPermSize设置永久代大小即可。
方法区用于存放java类型的相关信息，如类名、访问修饰符、常量池、字段描述、方法描述等。在类装载器加载class文件到内存的过程中，虚拟机会提取其中的类型信息，并将这些信息存储到方法区。当需要存储类信息而方法区的内存占用又已经达到-XX:MaxPermSize设置的最大值，将会抛出OutOfMemoryError异常。对于这种情况的测试，基本的思路是运行时产生大量的类去填满方法区，直到溢出。这里需要借助CGLib直接操作字节码运行时，生成了大量的动态类。
无法复现：

/**
 * VM Args: -XX:PermSize=10M -XX:MaxPermSize=10M
 */
public class MethodAreaOOM {
   public static void main(String[] args) {
      int count = 0;
      while (true) {
         Enhancer enhancer = new Enhancer();
         enhancer.setSuperclass(MethodAreaOOM.class);
         enhancer.setUseCache(false);
         enhancer.setCallback(new MethodInterceptor() {
            public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable {
               return proxy.invoke(obj, args);
            }
         });
         enhancer.create();
         System.out.println(++count);
      }
   }
}

运行结果

Caused by: java.lang.OutOfMemoryError: PermGen space
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:792)
    ... 8 more

3、栈溢出： java.lang.StackOverflowError : Thread Stack space

栈溢出了，JVM依然是采用栈式的虚拟机，这个和C和Pascal都是一样的。函数的调用过程都体现在堆栈和退栈上了。调用构造函数的 “层”太多了，以致于把栈区溢出了。 通常来讲，一般栈区远远小于堆区的，因为函数调用过程往往不会多于上千层，而即便每个函数调用需要 1K的空间（这个大约相当于在一个C函数内声明了256个int类型的变量），那么栈区也不过是需要1MB的空间。通常栈的大小是1-2MB的。通俗一点讲就是单线程的程序需要的内存太大了。 通常递归也不要递归的层次过多，很容易溢出。
解决方法：1：修改程序。2：通过 -Xss: 来设置每个线程的Stack大小即可。
在Java虚拟机规范中，对这个区域规定了两种异常状况：StackOverflowError和OutOfMemoryError异常。

（1）StackOverflowError异常

每当java程序代码启动一个新线程时，Java虚拟机都会为它分配一个Java栈。Java栈以帧为单位保存线程的运行状态。当线程调用java方法时，虚拟机压入一个新的栈帧到该线程的java栈中。只要这个方法还没有返回，它就一直存在。如果线程的方法嵌套调用层次太多(如递归调用)，随着java栈中帧的逐渐增多，最终会由于该线程java栈中所有栈帧大小总和大于-Xss设置的值，而产生StackOverflowError内存溢出异常。例子如下：

public class JavaVMStackSOF {
   private int count = 0;
   public static void main(String[] args) {
      new JavaVMStackSOF().method();
   }
   public void method() {
      System.out.println(++count);
      method();
   }
}

运行结果：

961Exception in thread "main" java.lang.StackOverflowError
    at sun.nio.cs.UTF_8.updatePositions(UTF_8.java:77)
    at sun.nio.cs.UTF_8.access$200(UTF_8.java:57)
    at sun.nio.cs.UTF_8$Encoder.encodeArrayLoop(UTF_8.java:636)
    at sun.nio.cs.UTF_8$Encoder.encodeLoop(UTF_8.java:691)
    at java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:579)
    at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:271)
    at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:125)
    at java.io.OutputStreamWriter.write(OutputStreamWriter.java:207)
    at java.io.BufferedWriter.flushBuffer(BufferedWriter.java:129)
    at java.io.PrintStream.newLine(PrintStream.java:545)
    at java.io.PrintStream.println(PrintStream.java:737)
    at com.payn.base.jvm.outleak.JavaVMStackSOF.method(JavaVMStackSOF.java:16)

随着-Xss参数值的增大，可以嵌套的方法调用层次也相应增加。综上所述，StackOverflowError异常是由于方法调用的层次太深，最终导致为某个线程分配的所有栈帧大小总和大于-Xss设置的值，从而发生StackOverflowError异常。

（2）OutOfMemoryError异常

java程序代码启动一个新线程时，没有足够的内存空间为该线程分配java栈(一个线程java栈的大小由-Xss参数确定)，jvm则抛出OutOfMemoryError异常。例子如下：

/**
 * VM Args: -Xss128k
 */
public class JavaVMStackOOM {
   public static void main(String[] args) {
      int count = 0;
      while (true) {
         Thread thread = new Thread(new Runnable() {
            public void run() {
               while (true) {
                  try {
                     Thread.sleep(5000);
                  } catch (Exception e) {
                  }
               }
            }
         });
         thread.start();
         System.out.println(++count);
      }
   }
}

运行结果：

Exception in thread "main" java.lang.OutOfMemoryError: unable to create new native thread
    at java.lang.Thread.start0(Native Method)
    at java.lang.Thread.start(Thread.java:693)
    at com.demo.test.JavaVMStackOOM.main(JavaVMStackOOM.java:21)

4、所以Server 容器启动的时候需要关心设置JVM的几个参数如下

-Xms：java Heap初始大小， 默认是物理内存的1/64。
-Xmx：java Heap最大值，不可超过物理内存。
-Xmn：young generation的heap大小，一般设置为Xmx的3、4分之一 。增大年轻代后，将会减小年老代大小，可以根据监控合理设置。
-Xss：每个线程的Stack大小，而最佳值应该是128K,默认值好像是512k。
-XX:PermSize：设定内存的永久保存区初始大小，缺省值为64M。
-XX:MaxPermSize：设定内存的永久保存区最大大小，缺省值为64M。
-XX:SurvivorRatio：Eden区与Survivor区的大小比值，设置为8，则两个Survivor区与一个Eden区的比值为2:8，一个Survivor区占整个年轻代的1/10。
-XX:+UseParallelGC：F年轻代使用并发收集，而年老代仍旧使用串行收集。
-XX:+UseParNewGC：设置年轻代为并行收集，JDK5.0以上，JVM会根据系统配置自行设置，所无需再设置此值。
-XX:ParallelGCThreads：并行收集器的线程数，值最好配置与处理器数目相等 同样适用于CMS。
-XX:+UseParallelOldGC：年老代垃圾收集方式为并行收集(Parallel Compacting)。
-XX:MaxGCPauseMillis：每次年轻代垃圾回收的最长时间(最大暂停时间)，如果无法满足此时间，JVM会自动调整年轻代大小，以满足此值。
-XX:+ScavengeBeforeFullGC：Full GC前调用YGC,默认是true。
实例如：JAVA_OPTS=”-Xms4g -Xmx4g -Xmn1024m -XX:PermSize=320M -XX:MaxPermSize=320m -XX:SurvivorRatio=6″

第一种OutOfMemoryError： PermGen space

发生这种问题的原意是程序中使用了大量的jar或class，使java虚拟机装载类的空间不够，与Permanent Generation space有关。解决这类问题有以下两种办法：
1、增加java虚拟机中的XX:PermSize和XX:MaxPermSize参数的大小，其中XX:PermSize是初始永久保存区域大 小，XX:MaxPermSize是最大永久保存区域大小。如针对tomcat6.0，在catalina.sh 或catalina.bat文件中一系列环境变量名说明结束处（大约在70行左右） 增加一行： JAVA_OPTS=" -XX:PermSize=64M -XX:MaxPermSize=128m" 如果是windows服务器还可以在系统环境变量中设置。感觉用tomcat发布sprint+struts+hibernate架构的程序时很容易发生这种内存溢出错误。使用上述方法，我成功解决了部署ssh项目的tomcat服务器经常宕机的问题。
2、清理应用程序中web-inf/lib下的jar，如果tomcat部署了多个应用，很多应用都使用了相同的jar，可以将共同的jar移到 tomcat共同的lib下，减少类的重复加载。这种方法是网上部分人推荐的，我没试过，但感觉减少不了太大的空间，最靠谱的还是第一种方法。

第二种OutOfMemoryError： Java heap space

发生这种问题的原因是java虚拟机创建的对象太多，在进行垃圾回收之间，虚拟机分配的到堆内存空间已经用满了，与Heap space有关。解决这类问题有两种思路：
1、检查程序，看是否有死循环或不必要地重复创建大量对象。找到原因后，修改程序和算法。 我以前写一个使用K-Means文本聚类算法对几万条文本记录（每条记录的特征向量大约10来个）进行文本聚类时，由于程序细节上有问题，就导致了 Java heap space的内存溢出问题，后来通过修改程序得到了解决。
2、增加Java虚拟机中Xms（初始堆大小）和Xmx（最大堆大小）参数的大小。如：set JAVA_OPTS= -Xms256m -Xmx1024m 。