当你从手工管理内存的语言（比如C或C++）转换到具有垃圾回收功能的语言的时候，你的工作会变得更加容易，因为当你用完了这些对象以后，它们会被自动回收。当你第一次经历对象回收功能的时候，会觉得这简直不可思议。这很容易给你留下这样的印象：认为自己不需要考虑内存管理的事情了。但事实上并非如此。
看下面这个简单的栈实现的例子：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
|
public
class
Stack {
private
Object elms[];
private
int
size =
0
;
private
static
final
int
DEFAULT_CAPACITY =
16
;
public
Stack(){
elms =
new
Object[DEFAULT_CAPACITY];
}
//模拟进栈
public
void
push(Object o) {
checkCapacity();
elms[size++] = o;
}
//模拟出栈
public
Object pop() {
if
(size ==
0
) {
throw
new
EmptyStackException();
}
return
elms[--size];
//取最后一个元素
}
//检查数组长度，确保够用
private
void
checkCapacity(){
if
(elms.length == size) {
elms = Arrays.copyOf(elms,
2
* size +
1
);
}
}
}
|
这段程序中并没有很明显的错误，但是这个程序中隐藏着一个问题。随着栈中元素的增加，内存占用将不断增加，程序性能的降低会主键表现出来。在极端的情况下，这种内存泄漏会导致磁盘交换，甚至引发OutOfMemoryError错误。但这种情况相对比较少见。
那么，程序中哪里发生了内存泄漏呢？想象一下，如果一个栈线增长，后收缩，那么从栈中弹出的对象将不会被当作垃圾回收，及时使用栈的程序不再引用这些对象，它们也不会被回收。这是因为，栈内部维护着对这些对象的过期引用。所谓过期引用是指永远也不会再被解除的引用。在本例中，凡是在elms数组“活动部分”之外的任何引用都是过期的。活动部份是指elms中，下标小于size的那些元素。
在支持垃圾回收的语言中，内存泄漏是很隐蔽的（称这类内存泄漏为“无意识的对象保持”更为恰当）。如果一个对象引用被无意识的保留起来了，那么垃圾回收机制不仅不会处理这个对象，还不会处理被这个对象引用的所有其他对象。即使只有少量的几个对象引用被无意识的保留了下来，也会有许许多多的对象被排除在垃圾回收机制以外，从而对性能和安全造成潜在的影响。
这类问题的修复办法很简单：一旦发现引用已经过期，清空他们就行了。对于本例而言，只要一个对象被弹出（这里其实仅仅是返回了一个引用，这个对象其实不在数组中），那么它指向的这个对象就应该为空，而不仅仅是简单的return。本例中的pop方法修复如下：
|
1
2
3
4
5
6
7
8
|
public
Object pop() {
if
(size ==
0
) {
throw
new
EmptyStackException();
}
Object result = elms[--size];
elms[size] =
null
;
//取消对过期对象的引用
return
result;
}
|
清空过期引用的另一个好处是，如果他们以后又被错误的解除引用，程序会立即抛出NullPointerException异常，而不是悄悄错误的运行下去。尽快检测出程序中的错误是有益的。
当程序员第一次被这样的问题困扰的时候，他们往往会过分小心：对于每一个对象引用，一旦程序不再用到，就会手动将其清空。其实这样做没有必要，也不是我们所期望的，因为这样做会把程序弄得很乱。清空对象引用应该是一种例外，而不是一种规范行为。消除过期引用的做好办法是让包含该引用的变量结束其生命周期。
那么何时应该清空引用呢？Stack类的哪些方面的特性使它容易遭受内存泄漏的影响呢？问题在于：Stack类自己管理内存。存储池包含了elms数组的元素。数组的活动区（前文有定义）中的元素是已分配的，而数组其余部分的元素则是自由的。但是垃圾回收器并不知道这一点。对于垃圾回收器而言，emls数组中的所有对象引用都是同等有效的，只有当程序员知道数组的非活动区是不重要的。程序员可以把这个情况告知垃圾回收器，做法很简单：一旦数组元素变成了非活动区的一部分，程序员就手工清空这些数组元素。
一般而言，只要类是自己管理内存，程序员就应该警惕内存泄漏的问题。一旦元素被释放掉，则该元素中包含的任何引用对象都应该被清空。
内存泄漏的另一个常见来源是缓存。一旦你把对象的引用防盗缓存中，它就很容易被遗忘掉，从而使得它不再有用。之后很长一段时间内仍然留在缓存中。对于这个问题，有几种可能的解决方案。如果你正好要实现这样的缓存：只要缓存之外存在对某个项的键的引用，该项就有意义，那么就可以用WeakHashMap（java.util下面的类）代表缓存；当缓存中的项过期之后，他们就会被自动删除（这是WeakHashMap自带的功能）。记住只有当所要的缓存项的生命周期是由该键的外部引用而不是由值决定时，WeakHashMap才有用处。
更为常见的情形是：“缓存项的生命周期是否有意义”并不是很容易确定，随着时间的推移，其中的项会变得越来越没有价值。在这种情况下，缓存应该时不时的清除掉没用的项。这项清除工作可以由一个后台线程（可能是Timer或是ScheduledThreadPoolExecutor）来完成，或者也可以在缓存添加新条目的时候顺便进行清理工作。LinkedHashMap类利用它的removeEldestEntry方法可以很容易地实现后一种方案。对于更加复杂的缓存，必须直接使用java.lang.ref。
内存泄漏的第三个常见来源是监听器和其他回调。如果你实现了一个API，客户端在这个API中注册回调，却没有显式的取消注册，那么除非你采取某些动作，否则它们就会积累。确保回调立即被当作垃圾回收的最佳方法是只保存他们的弱引用。例如：只将它们保存成WeakHashMap中的键。
由于内存泄漏通常不会表现成明显的失败，所以它们可以在一个系统中存在多年。往往只有通过仔细检查代码，或者借助于Heap剖析工具，才能发现内存泄漏的问题。因此，如果能够在使用内存泄漏发生之前就知道如何预测此类问题，并阻止它们发生，那是最好不过的了。
