Effective Java —— 消除过期的对象引用
本文参考
本篇文章参考自《Effective Java》第三版第七条"Eliminate obsolete object references"
Memory leaks in garbage-collected languages (more properly known as unintentional object retentions) are insidious
在具备垃圾回收器的语言中，内存泄漏（或称无意识对象保留）往往十分隐蔽，看下面一个自定义栈程序的例子
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);
}
}
}
尽管能够实现我们需要的LIFO的功能，但是在栈指针size先增长再收缩的情况下，栈的内部却始终保留着下标大于size的过期引用（obsolete references），过期引用不会被GC识别并进行回收，而实际上，我们只需要保留下标小于size 的活动部分（active portion）
注意，过期引用和活动部分只是我们自己定义的概念，GC是无法辨认的，只有我们知道过期引用是不重要的部分，所以Stack类的内存也就需要手动进行管理
我们可以看Java自己的Stack类是如何应对垃圾回收的
public synchronized E pop() {
E obj;
int len = size();
obj = peek();
removeElementAt(len - 1);
return obj;
}
peek()方法只是读取了栈顶的元素，主要是在removeElementAt()方法
public synchronized void removeElementAt(int index) {
modCount++;
if (index >= elementCount) {
throw new ArrayIndexOutOfBoundsException(index + " >= " + elementCount);
}
else if (index < 0) {
throw new ArrayIndexOutOfBoundsException(index);
}
int j = elementCount - index - 1;
if (j > 0) {
System.arraycopy(elementData, index + 1, elementData, index, j);
}
elementCount--;
elementData[elementCount] = null; /* to let gc do its work */
}
可以看到最后一行代码elementData[elementCount] = null将栈顶的元素设置为null，这样就能清空过期引用，让GC自动清理"堆"上的内存空间
Nulling out object references should be the exception rather than the norm
清空对象引用应该是一种例外而不是规范，因为在程序运行到超过某些引用的作用域（或生命周期）后，引用会被自动清除
The best way to eliminate an obsolete reference is to let the variable that contained the reference fall out of scope. This occurs naturally if you define each variable in the narrowest possible scope
上述的自定义栈就是一种例外，需要Stack类自己管理内存
Another common source of memory leaks is caches
为了防止我们遗忘缓存中的引用的清理，第一种解决方案是使用WeakHashMap，WeakHashMap含有一个继承了WeakReference弱引用类的Entry静态内部类，当某个键不再被正常使用时，该键会从WeakHashMap中被自动移除。更精确地说，对于一个给定的键，其映射的存在并不阻止垃圾回收器对该键的丢弃
Hash table based implementation of the Map interface, with weak keys. An entry in a WeakHashMap will automatically be removed when its key is no longer in ordinary use. More precisely, the presence of a mapping for a given key will not prevent the key from being discarded by the garbage collector, that is, made finalizable, finalized, and then reclaimed. When a key has been discarded its entry is effectively removed from the map
注意，只被弱引用指向的对象只能存活到下一次 JVM 执行垃圾回收动作之前，即JVM的每一次垃圾回收动作都会回收那些只被弱引用指向的对象
因此只要在缓存之外存在对某个项的键的引用（如强引用和软引用），该项就有意义，那么就可以用 WeakHashMap 代表缓存，当缓存中的项不再被引用（或称过期）之后，它们就会自动被GC删除
有关WeakHashMap的介绍可以参考这篇博文：https://blog.csdn.net/u014294681/article/details/86522487
另一种解决方案是使用LinkedHashMap，他的removeEldestEntry()方法会在插入新映射时被调用，用来移除旧的映射
This method is invoked by put and putAll after inserting a new entry into the map. It provides the implementor with the opportunity to remove the eldest entry each time a new one is added. This is useful if the map represents a cache: it allows the map to reduce memory consumption by deleting stale entries.
A third common source of memory leaks is listeners and other callbacks
如果你实现了一个 API，客户端在这个API中注册回调，却没有显式地取消注册，那么除非你采取某些动作，否则它们就会不断地堆积起来。确保回调立即被当作垃圾回收的最佳方法是只保存它们的弱引用（weak reference），例如，只将它们保存成 WeakHashMap 中的键
下面代码参考自stack overflow上的回答：https://stackoverflow.com/questions/2859464/how-to-avoid-memory-leaks-in-callback
public interface ChangeHandler {
void handleChange();
}
public class FileMonitor {
private File file;
private Set<ChangeHandler> handlers = new HashSet<ChangeHandler>();
// private WeakHashMap<ChangeHandler, ?> weakHandler = new WeakHashMap<>();
public FileMonitor(File file) {
this.file = file;
}
public void registerChangeHandler(ChangeHandler handler) {
this.handlers.add(handler);
}
public void unregisterChangeHandler(ChangeHandler handler) {
this.handlers.remove(handler);
}
}
public class MyClass {
File myFile = new File("somewhere");
FileMonitor monitor = new FileMonitor(myFile);
public void something() {
// do something ...
// strong reference declaration
// the reference will be expired after the scope of something() method ended
ChangeHandler myHandler = getChangeHandler();
monitor.registerChangeHandler(myHandler);
// if MyClass forgets to call unregisterChangeHandler() when it's done with the handler,
// the FileMonitor's HashSet will forever reference the instance that was registered,
// causing it to remain in memory until the FileMonitor is destroyed or the application quits.
// do something ...
}
private ChangeHandler getChangeHandler() {
return new ChangeHandler() {
@Override
public void handleChange() {
// do something ...
}
};
}
}
