不终止的线程（比如在其运行方法中无限期休眠）。即使我们丢失了对它的引用，它也不会被垃圾收集。您可以添加字段以使线程对象变大。

目前排名靠前的答案列出了更多的技巧，但这些似乎是多余的。

创建一个静态映射并不断添加硬引用。这些永远不会被垃圾收集。

public class Leaker {
    private static final Map<String, Object> CACHE = new HashMap<String, Object>();

    // Keep adding until failure.
    public static void addToCache(String key, Object value) { Leaker.CACHE.put(key, value); }
}

我可以从这里复制我的答案：在Java中导致内存泄漏的最简单方法

“在计算机科学中，当计算机程序消耗内存但无法将其释放回操作系统时，就会发生内存泄漏。”（维基百科）

简单的答案是：你不能。Java执行自动内存管理，并将释放您不需要的资源。你无法阻止这种情况的发生。它将始终能够释放资源。在具有手动内存管理的程序中，这是不同的。可以使用malloc（）在C中获得一些内存。要释放内存，您需要malloc返回的指针并对其调用free（）。但是，如果您不再拥有指针（被覆盖或超过生存期），那么很遗憾，您无法释放此内存，因此会出现内存泄漏。

到目前为止，所有其他答案在我的定义中都不是真正的内存泄漏。他们的目标都是快速用毫无意义的东西填满记忆。但在任何时候，您仍然可以取消引用创建的对象，从而释放内存-->无泄漏。尽管我不得不承认，acconrad的答案非常接近，因为他的解决方案实际上是通过强制垃圾收集器进入一个无休止的循环来“崩溃”垃圾收集器）。

长时间的答案是：通过使用JNI为Java编写库，可以获得内存泄漏，JNI可以进行手动内存管理，从而产生内存泄漏。如果调用此库，Java进程将泄漏内存。或者，JVM中可能存在bug，从而导致JVM丢失内存。JVM中可能存在bug，甚至可能存在一些已知的bug，因为垃圾收集并不是那么简单，但它仍然是一个bug。根据设计，这是不可能的。您可能需要一些受此类错误影响的Java代码。很抱歉，我不知道，而且在下一个Java版本中，它可能不再是一个bug。

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

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

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

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

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

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

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

线程在终止之前不会被收集。它们是垃圾收集的根源。它们是少数几个不能简单地通过忘记它们或清除对它们的引用来回收的对象之一。

考虑：终止工作线程的基本模式是设置线程看到的一些条件变量。线程可以定期检查变量，并将其作为终止的信号。如果变量未声明为volatile，那么线程可能看不到对变量的更改，因此它不知道终止。或者想象一下，如果一些线程想要更新共享对象，但在试图锁定该对象时出现死锁。

如果您只有少数线程，这些错误可能会很明显，因为您的程序将停止正常工作。如果您有一个线程池，可以根据需要创建更多线程，那么过时/卡住的线程可能不会被注意到，并且会无限累积，从而导致内存泄漏。线程可能会在应用程序中使用其他数据，因此也会阻止收集它们直接引用的任何数据。

作为玩具示例：

static void leakMe(final Object object) {
    new Thread() {
        public void run() {
            Object o = object;
            for (;;) {
                try {
                    sleep(Long.MAX_VALUE);
                } catch (InterruptedException e) {}
            }
        }
    }.start();
}

可以任意调用System.gc（），但传递给leakMe的对象永远不会死。

要做的一件简单的事情是使用带有不正确（或不存在）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.