如果你是从一个需要手动内存管理的程序员(c/c++)转到一个由自动内存管理的程序员(java)，你的工作会更加简单。因为你需要的对象会自动再生当你想要使用它的时候。这看起来很魔幻当你第一次体验自动内存管理，他很很容易给人一种你需要记住内存管理这件事的印象。但是，这肯定是不正确的！
思考这样一段栈实现的代码:
// Can you spot the "memory leak"?
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];
}
/*
Ensure space for at least one more element, roughly doubling the capacity each time the array needs to grow.
* /
private void ensureCapacity() { if (elements.length == size)
elements = Arrays.copyOf(elements, 2 size + 1);
}
}
这段程序完全没有错误(但是看一看条目29中类的版本)。你应该尽可能地测试一下它，它将顺利的通过所有的测试，但是这里仍然有一个潜在的问题。宽泛地说，这个程序有一个“内存泄漏”的问题，他可能导致提高垃圾回收的行为而静悄悄地减少性能，在极端的情况下，他会导致OutOfMemoryError，但是这样一个失败是很少见的！
那这里真的有内存泄漏吗？如果一个栈增长然后又收缩，这些本来被pop掉的对象仍然在栈中，他们没有被垃圾回收清理掉，尽管这个程序使用的栈不会再使用这些对象。这是因为栈包括类这些对象的引用，一个废弃的引用简单来说是没有地方再引用它，在这个问题上，在任何活动部分之外的引用是废弃的，而活动范围则是在这个栈的size小的部分!
内存泄漏在垃圾回收语言（更是当地说是不关注对象保留）总是潜在的。如果一个对象引用不关注它是否保存，不只是这个对象被垃圾回收排除掉，同时也关注一个对象的引用等等。甚至吐过很少的对象引用不小心被保存类，许多对象可能会由于高好费的垃圾回收而无法创建！
这个问题的固定解法很简单：只要一个引用被标记为nul就可以类。在这个栈的例子中，当这个对象从栈中pop之后，那么这个兑现个引用到这个对象就被废弃！这个正确的pop方法的版本是这样：
public Object pop() {
if (size == 0)
throw new EmptyStackException();
Object result = elements[--size];
elements[size] = null; // Eliminate obsolete reference
return result;
}
一个赋予null值的额外的好处是这个废弃的引用不会因为失误而被关联到对象上！这段程序将会立马通过空指针异常失败，而不是静静地保持错误。这样做总是对尽可能地找到程序中的错误是有好处的！
当程序员第一次被这种错误伤害，他们可能过度地将在每次使用完一个对象之后将每一个对象引用赋予Null值，但是这样做既不必要，也不是令人满意的！赋予Null值的对象引用应该是一种例外而不是一种标准。最好的方式来排除一个废弃的对象，是改变来控制引用不会调出一个范围内，这通常发生在当你每次你在你将对象定义在一个最狭隘的范围中（条目57）。
所以什么时候你应该将一个引用赋值为null呢？又是这个栈类的哪一个方面影响出内存泄露呢？简单来说，这是因为，栈中数组的内存是由它自己管理！这个存储池由一个有多个element的数组组成，这些element在数组被分配的活动范围之内，然后剩余的数组部分就是空的。但是垃圾回收不知道这些事情！对于垃圾回收器来说，数组中所有的element都是相等的，只有程序员才知道哪些活动范围内的element是不重要的。所以程序员需要在这数组中的element变得不重要了就要将他们赋予null值。
通常来说，无论是不是一个类管理它自己的内存，程序员都应该注意到内存泄露的问题。无论什么时候，一个element不会再使用了，所有包含他的对象引用都应该被赋予null值。
另一个常见的内存泄露是缓存。一旦你放了一个对象的引用到一个缓存，很容易就会忘记它在缓存中而导致这个对象在没有用之后还长时间留在缓存中。这里对这个问题有几个方案。如果你很幸运可以去实现一个缓存，你确定这个缓存会有一些缓存在废弃之后还会存在缓存之内，使用WeakHashMap来实现这个缓存。这些Map中的实体将会在废弃之后被自动移除。记住这个WeakHashMap将会非常有用，但是仅当确定这个缓存的键可能会废弃，而Map中的值。
更常见的是，这个缓存变得没有价值之前的使用时间很少被定义，在某些状况之下，可能偶尔会很清楚地知道一个缓存的实体已经变得不可用了。这个可能会是在后台线程需要做的工作。LinkedHashMap使用它的removeEldestEntry 提供了一个的方案。但是，对于很多复杂的缓存你可能需要首先使用java.lang.ref来解决问题。
第三个可能内存泄露的地方是监听器和回调函数，如果你实现了这个客户端注册回调函数的API，但是没有明确地将他们撤销注册，他们将会堆砌起来除非你对它们做一些事。一个方式是敏捷地确认这些回调函数已经被垃圾回收器标记为弱引用。例如对于实例，将他们以键的形式存储在WeakHashMap。因为内存泄露通常不会因为完全的程序出错而表现出来，他们通常会存在一个系统几年，它们通常只会在仔细的代码检查中或者借用有机制的代码调试工具（比如说heap profiler）才会被发现。因此，在这种问题出现之前预先去学习知道这个问题通常是很让人满意的！