我在javax.swing.JPopupMenu中遇到了非常真实的内存泄漏。

我有一个GUI应用程序，它显示多个选项卡式文档。关闭文档后，如果在选项卡上的任何组件上使用了右键单击上下文菜单，它就会在内存中停留。这些菜单在选项卡之间共享，结果是，在调用popupMenu.show（component invoker，int x，int y）后，组件会作为菜单的“调用程序”静静地存在，直到下一次更改或被setInvoker（null）清除。间接地，调用者引用持久化了整个文档以及与之相关的所有内容。

值得注意的是，菜单只能以这种方式保存对旧组件的一个引用，因此这种内存泄漏不会在没有绑定的情况下增长。

要做的一件简单的事情是使用带有不正确（或不存在）hashCode（）或equals（）的HashSet，然后继续添加“重复项”。而不是像应该的那样忽略重复项，集合只会增长，您将无法删除它们。

如果你想让这些坏键/元素到处乱动，你可以使用一个静态字段，比如

class BadKey {
   // no hashCode or equals();
   public final String key;
   public BadKey(String key) { this.key = key; }
}

Map map = System.getProperties();
map.put(new BadKey("key"), "value"); // Memory leak even if your threads die.

我最近修复的一个示例是创建新的GC和Image对象，但忘记调用dispose（）方法。

GC javadoc代码段：

应用程序代码必须显式调用GC.dispose（）方法以在以下情况下释放每个实例管理的操作系统资源不再需要这些实例。这一点尤为重要在Windows95和Windows98上可用的设备上下文数。

图像javadoc片段：

应用程序代码必须显式调用Image.dispose（）方法在以下情况下释放每个实例管理的操作系统资源不再需要这些实例。

import sun.misc.Unsafe;
import java.lang.reflect.Field;

public class Main {
    public static void main(String args[]) {
        try {
            Field f = Unsafe.class.getDeclaredField("theUnsafe");
            f.setAccessible(true);
            ((Unsafe) f.get(null)).allocateMemory(2000000000);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

我认为，一个有效的例子可能是在线程集中的环境中使用ThreadLocal变量。

例如，使用Servlet中的ThreadLocal变量与其他web组件通信，让容器创建线程，并在池中维护空闲线程。ThreadLocal变量如果没有正确清理，将一直存在，直到同一个web组件覆盖它们的值。

当然，一旦确定，问题很容易解决。

Java中有很多内存泄漏的好例子，我将在这个答案中提到其中两个。

示例1：

以下是《有效Java，第三版》（第7项：消除过时的对象引用）一书中的一个内存泄漏的好例子：

// Can you spot the "memory leak"?
public class Stack {
    private static final int DEFAULT_INITIAL_CAPACITY = 16;
    private Object[] elements;
    private int size = 0;

    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);
    }
}

本书的这一段描述了为什么此实现会导致内存泄漏：

如果堆栈增长然后收缩即使程序使用堆栈没有对它们的更多引用。这是因为堆栈维护对这些对象的过时引用。一个过时的引用只是一个永远不会被取消引用的引用再一次在这种情况下元素数组已过时。活动部分包括索引小于大小的元素

以下是本书解决此内存泄漏的解决方案：

解决这类问题的方法很简单：null out引用一旦过时。在Stack类的情况下，对项目的引用一经弹出就过时从堆栈中删除。pop方法的修正版本如下所示：

public Object pop() {
    if (size == 0) throw new EmptyStackException();
    Object result = elements[--size];
    elements[size] = null; // Eliminate obsolete reference
    return result;
}

但我们如何防止内存泄漏的发生？这是本书中一个很好的警告：

一般来说，每当类管理自己的内存时，程序员应该警惕内存泄漏。每当元素元素中包含的任何对象引用都应该为空。

示例2：

观察者模式也会导致内存泄漏。您可以在以下链接中阅读此模式：观察者模式。

这是观察者模式的一种实现：

class EventSource {
    public interface Observer {
        void update(String event);
    }

    private final List<Observer> observers = new ArrayList<>();

    private void notifyObservers(String event) {
        observers.forEach(observer -> observer.update(event)); //alternative lambda expression: observers.forEach(Observer::update);
    }

    public void addObserver(Observer observer) {
        observers.add(observer);
    }

    public void scanSystemIn() {
        Scanner scanner = new Scanner(System.in);
        while (scanner.hasNextLine()) {
            String line = scanner.nextLine();
            notifyObservers(line);
        }
    }
}

在这个实现中，EventSource（在Observer设计模式中是可观察的）可以保存到Observer对象的链接，但这个链接从未从EventSource的Observer字段中删除。所以垃圾收集器永远不会收集它们。解决这一问题的一个解决方案是向客户提供另一种方法，当他们不再需要这些观察员时，将上述观察员从观察员字段中删除：

public void removeObserver(Observer observer) {
    observers.remove(observer);
}