内存泄露和内存溢出

内存溢出 out of memory，是指程序在申请内存时，没有足够的内存空间供其使用，出现out of memory；

内存泄露 memory leak，是指程序在申请内存后，无法释放已申请的内存空间，一次内存泄露危害可以忽略，但内存泄露堆积后果很严重，无论多少内存,迟早会被占光。

内存泄露会最终会导致内存溢出！

内存溢出的原因分析：

内存泄露是指无用对象（不再使用的对象）持续占有内存或无用对象的内存得不到及时释放，从而造成的内存空间的浪费称为内存泄露。内存泄露有时不严重且不易察觉，这样开发者就不知道存在内存泄露，但有时也会很严重，会提示你Out of memory。

 

那么，Java内存泄露根本原因是什么呢？长生命周期的对象持有短生命周期对象的引用就很可能发生内存泄露，尽管短生命周期对象已经不再需要，但是因为长生命周期对象持有它的引用而导致不能被回收，这就是java中内存泄露的发生场景。具体主要有如下几大类：
1、静态集合类引起内存泄露：
像HashMap、Vector等的使用最容易出现内存泄露，这些静态变量的生命周期和应用程序一致，他们所引用的所有的对象Object也不能被释放，因为他们也将一直被Vector等引用着。

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

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

2、当集合里面的对象属性被修改后，再调用remove方法时不起作用。比如set中的元素，是根据哈希值进行添加。

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

4、单例模式

如果单例对象持有外部对象的引用，那么这个外部对象将不能被jvm正常回收，导致内存泄露。

不正确使用单例模式是引起内存泄露的一个常见问题，单例对象在被初始化后将在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是个比较复杂的对象或者集合类型会发生什么情况。

避免内存泄露的措施：

1、尽早释放无用对象的引用
2、使用字符串处理，避免使用String，应大量使用StringBuffer，每一个String对象都得独立占用内存一块区域
3、尽量少用静态变量，因为静态变量存放在永久代（方法区），永久代基本不参与垃圾回收
4、避免在循环中创建对象

内存泄露怎么查找？

使用Jconsole：JConsole 是一个内置 Java 性能分析器，可以从命令行中运行

查看工具栏中的Memory：显示内存使用信息，如果内存的大小持续地增长，则说明系统存在内存泄漏。

Jconsole相关博客：http://jiajun.iteye.com/blog/810150

内存溢出的场景：（OOM异常）

除了程序计数器外，虚拟机内存的其他几个运行时区域都有发生OOM异常的可能。

1.堆区：对象实例和数组。

2.方法区：类信息，常量、静态变量等。如果程序加载的类过多，或者使用反射、gclib等这种动态代理生成类的技术，就可能导致该区发生内存溢出。

3.线程栈溢出：递归太深或方法调用层数过多（可解决的办法：减少内存，比如堆）

内存泄露Or内存溢出：
通过Eclipse Memory Analyzer（内存映象分析工具MAT）得到堆转储快照分析（假如为堆溢出）：

如果为内存泄露，可通过工具查看泄露对象到GC Roots的引用链。于是就能找到泄露对象时通过怎样的路径与GC Roots相关联并导致垃圾回收器无法自动回收他们的。掌握了泄露对象的类型信息及GC Roots引用链信息，就可以比较准确地定位出泄露代码的位置。

如果不存在内存泄露，则说明内存中的对象确实都还必须存活着，则考虑优化配置参数。

如果是内存溢出，则说明内存中的对象确实都还必须存活着，则考虑优化配置参数。

5、优化配置，设置参数

  1) 设置-Xms（小）、-Xmx相等；（设置两者相等即可避免堆自动扩展）

  2) 设置NewSize、MaxNewSize相等；（设置新生代大小）

  3) 设置PermSize、MaxPermSize。