java内存泄露

上一篇提到的是java垃圾回收,今天谈谈java的内存泄露。

首先谈下java的内存管理机制:

在Java程序中,我们通常使用new为对象分配内存,而这些内存空间都在堆(Heap)上。

public class Test {
    public static void main(String args[]){
        Object object1 = new Object();//obj1
        Object object2 = new Object();//obj2
        object2 = object1;  
    }
}

在上面的代码中,创建了两个对象obj1和obj2,这两个对象各占用了一部分内存,然而,两个对象引用变量object1和object2同时指向obj1的那块内存,而obj2是不可达的,由于java垃圾回收的目标,是清理那些不可达的对象所占内存,释放对象的根本原则就是对象不会再被使用(也就是没有引用变量指向该对象所占内存空间),所以obj2是可以被清理的。

下面通过讲解几个例子来说明java的内存泄露:

内存泄露的定义:当某些对象不再被应用程序所使用,但是由于仍然被引用而导致垃圾收集器不能释放(Remove,移除)他们.

首先,使用一个简单实现栈的例子类分析: 

public class Stack {

    private  Object[] elements;
    private int size;
    private static final  int DEFAULT_INITIAL_CAPACITY = 16;

    public Stack(){
        elements = new Object[DEFAULT_INITIAL_CAPACITY];
    }
    public void push(Object e){
        ensureCapacity();
        elements[size++] = e;
    }
    public Object pop(){
        if (size == 0){
            throw new EmptyStackException();
        }
        return elements[--size];
    }
    private void ensureCapacity(){
        if (elements.length == size){
            elements = Arrays.copyOf(elements,size*2+1);
        }
    }

场景分析:这段程序看上去没有任何的错误,但是,里面隐藏着一个问题,也就是存在一个"内存泄露",随着垃圾回收器活动的增加以及内存占用的不断增加,程序性能会逐渐表现出来,极端情况下,会引发OutOfMemoryError导致程序崩溃。

原因分析:程序是模仿栈的功能,如果一个栈先增长,后缩减,那么,从栈弹出的对象所占用的内存空间将不会被垃圾回收器回收,因为栈内部维护着这些对象的过期引用,也就是指永远也不会被解除的引用,在本段代码中,凡是在elements数组的"活动部分(指elements中下标小于size的那些元素)"之外的任何引用都是过期的。

解决方法:一旦对象引用已经过期,只需要将之清空即可,否则,如果一个对象引用被无意识的保留下来,那么垃圾回收器不仅不会处理这个对象,而且也不会处理被这个对象所引用的所有其他对象,在本例中,只需将弹出元素的方法pop(),改为以下逻辑

public Object pop(){
        if (size == 0){
            throw new EmptyStackException();
        }
        Object element =  elements[--size];
        elements[size] = null;
        return element;
 }

接下来列出几种常见而又不易被发现的"内存泄露"

 1.长生命周期的对象持有短生命周期的引用,就很可能会出现内存泄露

public class Test {
    Object object;
    public void test(){
        object = new Object();
        //...其他代码
    }
}

这个例子中,Test类中的test方法结束后,创建出来的object所占用的内存不会马上被认为是可以被释放,严格意义上已经导致了垃圾回收。有两种解决办法:在test方法结束处,显示给object ==null,将其打上可被回收的标志;将object作为test方法内部的局部变量。

2.静态集合类像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 程序发生了内存泄漏。

3.当集合里面的对象属性被修改后,再调用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); 
    } 
}    

4.各种连接,数据库连接,网络连接,IO连接等没有显示调用close关闭,不被GC回收导致内存泄露,对于Resultset 和Statement 对象可以不进行显式回收,但Connection 一定要显式回收,因为Connection 在任何时候都无法自动回收,而Connection一旦回收,Resultset 和Statement 对象就会立即为NULL;

5.内部类和外部模块的引用;

6.单例对象在被初始化后将在JVM的整个生命周期中存在(以静态变量的方式),如果单例对象持有外部对象的引用,那么这个外部对象将不能被jvm正常回收,导致内存泄露;

7.监听器的使用,在释放对象的同时没有相应删除监听器的时候也可能导致内存泄露。

内存泄露解决的原则:

1.尽量减少使用静态变量,类的静态变量的生命周期和类同步的。  

2.声明对象引用之前,明确内存对象的有效作用域,尽量减小对象的作用域,将类的成员变量改写为方法内的局部变量;

3.减少长生命周期的对象持有短生命周期的引用;

4.使用StringBuilder和StringBuffer进行字符串连接,Sting和StringBuilder以及StringBuffer等都可以代表字符串,其中String字符串代表的是不可变的字符串,后两者表示可变的字符串。如果使用多个String对象进行字符串连接运算,在运行时可能产生大量临时字符串,这些字符串会保存在内存中从而导致程序性能下降。  

5.对于不需要使用的对象手动设置null值,不管GC何时会开始清理,我们都应及时的将无用的对象标记为可被清理的对象;

6.各种连接(数据库连接,网络连接,IO连接)操作,务必显示调用close关闭。

posted @ 2016-09-05 00:28  yehx  阅读(6426)  评论(0编辑  收藏  举报