如果你从手动管理内存的编程语言如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，但是这样的故障相对较少。
所以，哪里内存泄漏了？如果栈增长然后收缩，被栈弹出去的对象将不会被垃圾回收器给回收，即使使用这个栈的程序对它们没有更多的引用。这是因为栈仍旧维护着对这些对象的过时引用。过时引用是一个永远不会再被解除引用的引用。在这种情况下，元素数组的“活动部分”以外的任何引用都是过时的。活动部分由索引小于大小的元素组成。
垃圾收集语言中的内存泄漏（更恰当地称为无意识的对象保留）是隐秘的。如果一个对象引用被无意中保留，不仅该对象被垃圾回收排除，而且任何被该对象引用的对象也被排除，以此类推。即使无意中保留了少量的对象引用，也会阻止大量对象被垃圾回收，潜在地大量影响性能。
解决这类问题的方法很简单：一旦它们变得过时，将它们指向null。在我们的例子Stack类的情况下，当项目被栈弹出时，它的引用就过时了。pop方法的更正版本如下：
public Object pop() {
if (size == 0) throw new EmptyStackException();
Object result = elements[--size];
elements[size] = null; // Eliminate obsolete reference
return result;
}
将过时引用置null的另一个好处是如果它们随后被错误地取消引用，程序将立即失败并抛出NullPointerException，而不是安静地执行错误操作。尽可能快地检测编程错误总是有益的。当程序员第一次被这个问题所困扰时，他们可能在程序使用完后尽快清空每个对象引用而过度补偿。这既没有必要也不可取；它不必要地混乱了程序。取消对象引用应该是例外而不是规范。最好的方式来清除过时引用就是让包含引用的变量超出范围。如果你在尽可能窄的范围内定义每个变量，这自然会发生（item57）。
所以什么时候你应该将引用置空？Stack类的什么方面容易导致内存泄漏？简单地说，当它自己管理自己的内存的时候。存储池由元素数组的元素组成（对象引用单元格而不是对象本身），数组（如前所述）活动部分中的元素被分配，数组中的其余部分是空闲的。垃圾回收器没有办法知道这一点；对于垃圾回收器来说，所有在元素数组中的对象引用都同样有效。只有程序员知道数组的不活动部分是不重要的。程序员通过在数组元素成为非活动部分时立即手动清空元素数组，有效地传递这个信息给垃圾回收器。
总体上说，只要一个类管理了它自己的内存，程序员就该警惕内存泄漏，只要一个元素被释放，任何包含这个元素的对象引用就该被清除掉。
另一个内存泄漏的常见原因是缓存。当你将对象引用放入缓存后，很容易忘记它在那里，并且它变得无关紧要后就一直保留在缓存里。这种问题由几种解决办法。如果你足够幸运来实现一个条目相关的缓存，只要在缓存之外有对其key的引用，就将缓存表示为WeakHashMap（https://www.cnblogs.com/skywang12345/p/3311092.html）。条目将在过时后被自动删除。请记住，只有当缓存条目的所需生存期的key被外部引用 时WeakHashMap才有用，而不是值。
更常见的是，缓存条目的有用生存周期很难定义，随着时间的推移条目变得不那么有价值。在这种情况下，缓存应该偶尔清除那些已经废弃的条目。这可以通过后台线程（可能是ScheduledThreadPoolExecutor）或添加新条目到缓存中的副作用来完成。LinkedHashMap使用removeEldestEntry方法促进后一种方法。对于更复杂的缓存，你可能需要直接使用java.lang.ref（https://www.ibm.com/developerworks/cn/java/j-lo-langref/index.html） 。
内存泄漏的第三种普遍来源是监听器和其他回调。如果你实现了一个API，客户端注册了回调，但是并未明确注销回调，除非你采取一些措施，否则它们将累积。确保回调函数被及时垃圾回收的一个办法是只是存储它们的弱引用，例如，仅存储它们作为WeakHashMap的键（key）。
因为通常内存泄漏并不会表现为明显的故障，它们可能会在系统中保留多年。它们通常只有当仔细的代码检查或借助称为堆分析器的调试工具的情况下被发现。所以，非常需要学会预测这些问题，并防止它们发生。
本文写于2019.1.11，历时3天
