??当你从手工管理内存的语言(比如C或者C++)转换到具有垃圾回收功能的语言的时候，程序猿的工作就会变得更加容易，因为当你用完了对象之后，他们就会被自动回收。当你第一次经历对象回收功能的时候，会觉得这简直有点不可思议。这很容易给你留下这样的印象，认为自己不再需要考虑内存管理的事情了，其实不然。
??考虑下面这个简单的栈实现的例子：
// 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项)。无论如何测试，它都会成功地通过每一项测试，但是这个程序中隐藏着一个问题。简而言之，改程序存在“内存泄漏”，由于垃圾收集器的活动增加或者内存占用增加，程序性能的降低会逐渐表现出来。在极端的情况下，这种内存泄漏会导致磁盘分页(Disk Paging)，甚至导致程序失败并出现OutOfMemoryError，但这种失败情形相对比较少见。
??那么，程序中哪里发生了内存泄漏呢？如果一个栈先是增长，然后再收缩，那么，从栈中弹出来的对象将不会被当做垃圾回收，即使使用栈的程序不再引用这些对象，它们也不会回收，因为，栈内部维护着对这些对象的过期引用(obsolete references)，所谓的过期引用，是指永远也不会再被解除的引用。在本例中，凡是在element数组的“活动部分”(active portion)之外的任何引用都是过期的。活动部分是指element中下标小于size的那些元素。
??具有垃圾收集功能的编程语言中的内存泄漏(更恰当地称为无意识的对象保留)是隐蔽的。如果无意中保留了对象引用，则不仅将该对象从垃圾回收中排除，而且该对象引用的任何对象也是如此，依此类推。即使无意中保留了少量对象引用，也会阻止许多对象被垃圾回收器收集，对性能可能产生很大影响。
??这类问题的修复方法很简单：一旦对象引用已经过期，只需要清空这些引用即可。对于上述例子中的Stack类而言，只要一个单元被弹出栈，指向它的引用就过期了，pop方法的修订版本如下所示：
public Object pop() {
if (size == 0)
throw new EmptyStackException();
Object result = elements[--size];
elements[size] = null; // Eliminate obsolete reference
return result;
}??清空过期引用的另一个好处是，如果它们以后又被错误地解除引用，程序就会立即抛出NullPointerException异常，而不是悄悄地错误运行下去。尽快检测出程序中的错误总是有益的。
??当程序员第一次被类似这样的问题困扰的时候，它们往往会过分小心：对于每一个对象的引用，一旦程序不再用到它，就把它清空。其实这样做即没必要，也不是我们所期望的，因为这样做会把程序代码弄得很乱。清空对象引用应该是一种例外，而不是一种规范行为。消除过期引用最好的方法是让包含该引用的变量结束其生命周期。如果你是在最紧凑的作用域范围内定义每一个变量(第57项)，这种情形就会自然而然地发生。
??那么，何时应该清空引用呢？Stack类的哪方面特性使它易于遭受内存泄漏的影响呢？简而言之，问题在于，Stack类自己管理内存(manage its own memory)、存储池(storage pool)包含了elements数组(对象引用单元，而不是对象本身)的元素。数组活动区域(同前面的定义)中的元素是已分配的(allocated)，而数组其余部分的元素则是自由的(free)。但是垃圾回收器无法知道这一点；对于垃圾回收器而言，elements数组中的所有对象引用都同等有效。只有程序猿知道数组的非活动部分是不重要的。程序猿可以把这个情况告知垃圾回收器，做法很简单：一旦数组元素变成了非活动部分的一部分，程序猿就手动清空这些数组元素。
??通常来说，只要类是自己管理内存，程序猿就应该警惕内存泄漏问题。一旦元素被释放掉，则该元素中包含的任何对象引用都应该被清空。
??内存泄漏的另一个常见来源是缓存。一旦你把对象引用放到缓存中，它就很容易被遗忘掉，从而使得它在很长一段时间没有使用，但是却仍然留在缓存中。对于这个问题，这里有好几种解决方案。如果你正好要实现这样的缓存，只要在缓存之外存在对某个项的键的引用，该项就有意义，那么就可以用WeakHashMap代表缓存，当缓存中的项过期之后，它们就会自动被删除。记住只有当所要的缓存项的生命周期是由该键的外部引用而不是由值决定时，WeakHashMap才有用处。
??更为常见的情形则是，“缓存项的生命周期是否有意义”并不是很容易确定，随着时间的推移，其中的项会变得越来越没有价值。在这种情况下，缓存应该时不时地清除掉没用的项。这项清除工作可以由一个后台线程(可能是Timer或者ScheduledThreadPoolExecutor)来完成，或者也可以在给缓存添加新项的时候顺便进行清理。LinkedHashMap类利用它的removeEldestEntry方法可以很容易地实现后一种方案。对于更加复杂的缓存，必须直接使用java.lang.ref。
??内存泄漏的第三个常见来源是监听器和其他回调。如果你实现了一个API，客户端在这个API中注册回调，却没有显示地取消注册，那么除非你采取某些动作，否则他们就会积累下来。确保回调立即被当做垃圾回收的最佳方法是只保存他们的弱引用(weak reference)，例如，只将它们保存成WeakHashMap中的键。
??由于内存泄漏通常不会表现出明显的失败迹象，所以他们可以在一个系统中存在很多年。往往只有通过仔细检查代码，或者借助于Heap剖析工具(Heap Profiler)才能发现内存泄漏问题。因此，如果能在内存泄漏发生之前就知道如何预测此类问题，并阻止它们发生，那是最好不过的了。
关注个人公众号获取更新！
原文地址：https://www.cnblogs.com/coloured_glaze/p/10661854.html