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

这里有一个非常简单的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));
        }
    }
}

我在Java中看到的大多数内存泄漏都与进程不同步有关。

进程A通过TCP与B对话，并告诉进程B创建一些东西。B向资源发出一个ID，比如432423，A将其存储在一个对象中，并在与B对话时使用。在某些情况下，A中的对象会被垃圾收集回收（可能是由于错误），但A从不告诉B这一点（可能是另一个错误）。

现在A不再拥有它在B的RAM中创建的对象的ID，B也不知道A不再引用该对象。实际上，对象是泄漏的。

什么是内存泄漏：

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

典型示例：

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

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对象引用了其他对象，则这些对象也引用了其他的对象。在某种程度上，您也可以认为这是某种内存泄漏（由糟糕的设计导致）。

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

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

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

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

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

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

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

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