这里有一个非常简单的Java程序，它将耗尽空间

public class OutOfMemory {

    public static void main(String[] arg) {

        List<Long> mem = new LinkedList<Long>();
        while (true) {
            mem.add(new Long(Long.MAX_VALUE));
        }
    }
}

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

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

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

Swing使用对话框非常简单。创建一个JDialog，显示它，用户关闭它，然后泄漏！

您必须调用dispose（）或配置setDefaultCloseOperation（dispose_ON_CLOSE）。

重叠侦听器是内存泄漏的一个很好的例子：对象被添加为侦听器。当不再需要对象时，对象的所有引用都为空。然而，忘记从侦听器列表中删除对象会使对象保持活动状态，甚至对事件做出响应，从而浪费内存和CPU。看见http://www.drdobbs.com/jvm/java-qa/184404011

如果不使用压缩垃圾收集器，则可能会由于堆碎片而发生某种内存泄漏。

这里的大多数例子都“过于复杂”。它们是边缘案例。在这些例子中，程序员犯了一个错误（比如不要重新定义equals/hashcode），或者被JVM/JAVA的一个极端情况（用静态加载类…）所咬。我认为这不是面试官想要的例子，甚至不是最常见的例子。

但内存泄漏的情况确实更简单。垃圾收集器只释放不再引用的内容。我们作为Java开发人员并不关心内存。我们在需要时分配它，并让它自动释放。好的

但任何长寿命的应用程序都倾向于共享状态。它可以是任何东西，静态的，单态的。。。通常，非平凡的应用程序倾向于生成复杂的对象图。只是忘记将引用设置为null，或者更经常地忘记从集合中删除一个对象，就足以造成内存泄漏。

当然，如果处理不当，所有类型的侦听器（如UI侦听器）、缓存或任何长期共享状态都会产生内存泄漏。应该理解的是，这不是Java角落的情况，也不是垃圾收集器的问题。这是一个设计问题。我们设计为向长寿命对象添加侦听器，但在不再需要时不删除侦听器。我们缓存对象，但我们没有从缓存中删除它们的策略。

我们可能有一个复杂的图来存储计算所需的先前状态。但前一状态本身与前一状态相关联，依此类推。

就像我们必须关闭SQL连接或文件一样。我们需要设置对null的正确引用，并从集合中删除元素。我们应该有适当的缓存策略（最大内存大小、元素数量或计时器）。所有允许通知侦听器的对象必须同时提供addListener和removeListener方法。当这些通知器不再使用时，它们必须清除侦听器列表。

内存泄漏确实是可能的，而且完全可以预测。无需特殊的语言功能或角盒。内存泄漏要么是某些东西可能丢失的指示，甚至是设计问题。