从一个栈引出的内存泄露问题

我记得在有一次面试中，面试官问我自己实现的一个栈中会不会有内存泄露的问题，我努力搜索可能的问题，就是感受不到可能出现的问题。当时忽然意识到，内存泄露这个问题一直被我忽略，因为用的是java/C#,这些语言中都有内存自动回收的机制，我突然发现自己对这个问题竟然一无所知。面试中的栈就是下面这个：

// 你能检查出"内存泄露"吗？
public class Stack {
    private Object[] elements;
    private int size = 0;
    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, 2 * size + 1);
    }
}

这段程序不管你怎么测试都是没有问题的，但是他确实可能引起“内存泄露”。定位到pop()函数，在return语句中，当我们弹出一个元素时，只是简单的让栈顶指针（size）-1。逻辑上，栈中的这个元素已经弹出，已经没有用了。但是事实上，被弹出的元素依然存在于elements数组中，它依然被elements数组所引用，GC是无法回收被引用着的对象的。也许你期望等这整个栈失去引用（将被GC回收时），栈内的elements数组一起被GC回收。但是实际的使用过程中，又有谁能够预料到这个栈会存活多长时间。为了保险起见，我们需要在弹出一个元素的时候，就让这个元素失去引用，便于GC回收。我们只需要让Pop()函数弹出时，同时解除对弹出元素的引用即可。

public Object pop() {

if (size == 0)
            throw new EmptyStackException();
        Object result = elements[--size];
        elements[size] = null; // 消除过期的引用

        return result;
    }

从上面的例子中，我们可以发现当类中持有过期的元素的引用时，就有可能造成内存泄露问题。而且通常这种内存泄露问题都是我们无意识造成的，上面的栈中，逻辑上我们认为弹出的元素就应该被GC回收掉，但事实上GC没有办法回收，因此elements数组依然持有它。这种问题很隐蔽，通常只要类自己管理内存（如类中有一个Array或List型的结构），那么我们就应该警惕内存泄露的问题。

内存泄露来源及解决

    内存泄露可能来源于缓存。我们为了让下次的程序的处理速度更快，常常需要将一些信息缓存在内存中，但是这些过期的缓存又很容易被遗忘，从而使得它不再有用之后很长一段时间内仍然留在缓存中。例如像一个要显示图片墙的程序，我们需要缓存图片和相关的信息，为了方便GC回收过期的缓存，我们可以使用WeakHashMap来实现缓存，当界面显示图片的时候，界面持有相关图片的引用，这些引用同时也存在于WeakHashMap中。而其他不被界面持有的过期缓存，则WeakHashMap会自动将这些剔除。

    总的说来，只要在缓存之外存在对某个项的键的引用，该项就有意义，那么就可以用WeakHashMap代表缓存；当缓存中的项过期之后，它们就自动被删除。记住只有当所有的缓存项的生命周期是由该键的外部引用而不是由值决定时，WeakHashMap才有用处。

    更为常见的情景则是,"缓存项的生命周期是否有意义"并不是非常容易确定，随着时间推移，其中的项会变得越来越没有价值。在这种情况下，缓存应该是不是地清除掉没有的项。这项清除工作可以由一个后台线程（可能是Timer或者ScheduledThreadPoolExecutor）来完成，或者也可以在给缓存添加新条目的时候顺便进行清理。LinkedHashMap类利用它的removeEldestEntry方法可以很容易地实现后一种方案。对于更加复杂的缓存，必须直接使用java.lang.ref.
    内存泄露的第三个常见来源是监听器和其他回调。如果你实现了一个API，客户端在这个API中注册回调，却没有显式地取消注册，那么除非你采取某些动作，否则他们就会积聚。确保回调立即被当成垃圾回收的最佳方法是只保存它们的弱引用（weak reference），例如，只将它们保存成WeakHashMap中的键。

部分文字直接截取自《Effective Java》