java内存泄露

Posted 2020-08-06 一行代码、一个梦想

上一篇提到的是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关闭。