关于如何在Java中创建内存泄漏，有很多答案，但请注意采访中提出的问题。

“如何使用Java创建内存泄漏？”是一个开放式问题，其目的是评估开发人员的经验程度。

如果我问你“你有解决Java内存泄漏的经验吗？”，你的答案很简单：“是”。然后，我会继续说“你能给我举个例子来解决内存泄漏问题吗？”，你会给我一两个例子。

然而，当面试官问“如何用Java创建内存泄漏？”时，预期答案应该是以下几行：

我遇到了内存泄漏。。。（说什么时候）[这显示了我的经验]导致它的代码是。。。（解释代码）[你自己修的]我应用的修复基于。。。（解释修复）[这让我有机会询问修复的细节]我做的测试是。。。[让我有机会询问其他测试方法]我是这样记录的。。。[额外加分。如果你记录下来，那就好了]因此，有理由认为，如果我们按照相反的顺序执行，也就是说，得到我修复的代码，然后删除我的修复，我们就会出现内存泄漏。

当开发人员未能遵循这一思路时，我试图引导他/她问“你能给我一个Java如何泄漏内存的例子吗？”，然后问“你曾经修复过Java中的内存泄漏吗？”

请注意，我并不是在询问如何在Java中泄漏内存的示例。那太傻了。谁会对一个能够有效编写泄漏内存的代码的开发人员感兴趣？

GUI代码中的一个常见示例是创建小部件/组件并向某个静态/应用程序范围的对象添加侦听器，然后在小部件被破坏时不删除侦听器。不仅会出现内存泄漏，而且性能也会受到影响，因为无论你听什么都会引发事件，所有的老听众都会被调用。

JDK 1.7之前内存泄漏的实时示例：

假设您读取了一个包含1000行文本的文件，并将其保存在String对象中：

String fileText = 1000 characters from file
fileText = fileText.subString(900, fileText.length());

在上面的代码中，我最初读取了1000个字符，然后执行了子字符串，只获得最后100个字符。现在，fileText应该只引用100个字符，所有其他字符都应该被垃圾收集，因为我丢失了引用，但是在JDK1.7之前，substring函数间接引用了最后100个字符的原始字符串，并阻止了整个字符串的垃圾收集，而整个1000个字符将一直保存在内存中，直到您丢失了对子字符串的引用。

您可以创建一个类似于上述的内存泄漏示例。

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

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

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

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

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

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

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

GC javadoc代码段：

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

图像javadoc片段：

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