我记得在有一次面试中，面试官问我本人实现的一个栈中会不会有内存泄露的问题，我致力搜寻可能的问题，就是感触不到可能呈现的问题。过后突然意识到，内存泄露这个问题始终被我疏忽，因为用的是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》