您可以通过在类的finalize方法中创建类的新实例来创建移动内存泄漏。如果终结器创建多个实例，则会获得加分。下面是一个简单的程序，它可以在几秒钟到几分钟内泄漏整个堆，具体取决于堆的大小：

class Leakee {
    public void check() {
        if (depth > 2) {
            Leaker.done();
        }
    }
    private int depth;
    public Leakee(int d) {
        depth = d;
    }
    protected void finalize() {
        new Leakee(depth + 1).check();
        new Leakee(depth + 1).check();
    }
}

public class Leaker {
    private static boolean makeMore = true;
    public static void done() {
        makeMore = false;
    }
    public static void main(String[] args) throws InterruptedException {
        // make a bunch of them until the garbage collector gets active
        while (makeMore) {
            new Leakee(0).check();
        }
        // sit back and watch the finalizers chew through memory
        while (true) {
            Thread.sleep(1000);
            System.out.println("memory=" +
                    Runtime.getRuntime().freeMemory() + " / " +
                    Runtime.getRuntime().totalMemory());
        }
    }
}

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

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

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

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

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

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

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

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

什么是内存泄漏：

这是由错误或不良设计引起的。这是在浪费记忆。随着时间的推移，情况会变得更糟。垃圾收集器无法清理它。

典型示例：

对象缓存是一个很好的起点，可以让事情变得一团糟。

private static final Map<String, Info> myCache = new HashMap<>();

public void getInfo(String key)
{
    // uses cache
    Info info = myCache.get(key);
    if (info != null) return info;

    // if it's not in cache, then fetch it from the database
    info = Database.fetch(key);
    if (info == null) return null;

    // and store it in the cache
    myCache.put(key, info);
    return info;
}

您的缓存不断增长。很快整个数据库就被吸进了内存。更好的设计使用LRUMap（仅将最近使用的对象保存在缓存中）。

当然，你可以让事情变得更加复杂：

使用ThreadLocal构造。添加更复杂的参考树。或由第三方库引起的泄漏。

经常发生的情况：

如果此Info对象引用了其他对象，则这些对象也引用了其他的对象。在某种程度上，您也可以认为这是某种内存泄漏（由糟糕的设计导致）。

每个人都会忘记本机代码路径。以下是泄漏的简单公式：

声明本机方法。在本机方法中，调用malloc。不要打免费电话。调用本机方法。

记住，本机代码中的内存分配来自JVM堆。

我觉得有趣的是，没有人使用内部类示例。如果您有内部类；它固有地维护对包含类的引用。当然，从技术上讲，这不是内存泄漏，因为Java最终会清理掉它；但这会导致类停留的时间比预期的长。

public class Example1 {
  public Example2 getNewExample2() {
    return this.new Example2();
  }
  public class Example2 {
    public Example2() {}
  }
}

现在，如果您调用Example1并得到一个Example2丢弃Example1，那么您本质上仍然有一个到Example1对象的链接。

public class Referencer {
  public static Example2 GetAnExample2() {
    Example1 ex = new Example1();
    return ex.getNewExample2();
  }

  public static void main(String[] args) {
    Example2 ex = Referencer.GetAnExample2();
    // As long as ex is reachable; Example1 will always remain in memory.
  }
}

我还听到一个传言，如果你有一个变量存在的时间超过了一个特定的时间；Java假设它将永远存在，并且如果代码中无法访问它，它实际上永远不会尝试清理它。但这完全未经证实。