另一种可能造成巨大内存泄漏的方法是保存对TreeMap的Map.Entry＜K，V＞的引用。

很难理解为什么这只适用于TreeMaps，但通过查看实现，原因可能是：TreeMap.Entry存储了对其同级的引用，因此，如果TreeMaps准备好被收集，但其他类保存了对其Map.Intry的引用，则整个Map将保留在内存中。

现实生活场景：

想象一下，有一个数据库查询返回一个大的TreeMap数据结构。人们通常使用TreeMaps作为元素插入顺序。

public static Map<String, Integer> pseudoQueryDatabase();

如果查询被多次调用，并且对于每个查询（因此，对于返回的每个Map），您在某个地方保存了一个条目，那么内存将不断增长。

考虑以下包装类：

class EntryHolder {
    Map.Entry<String, Integer> entry;

    EntryHolder(Map.Entry<String, Integer> entry) {
        this.entry = entry;
    }
}

应用程序：

public class LeakTest {

    private final List<EntryHolder> holdersCache = new ArrayList<>();
    private static final int MAP_SIZE = 100_000;

    public void run() {
        // create 500 entries each holding a reference to an Entry of a TreeMap
        IntStream.range(0, 500).forEach(value -> {
            // create map
            final Map<String, Integer> map = pseudoQueryDatabase();

            final int index = new Random().nextInt(MAP_SIZE);

            // get random entry from map
            for (Map.Entry<String, Integer> entry : map.entrySet()) {
                if (entry.getValue().equals(index)) {
                    holdersCache.add(new EntryHolder(entry));
                    break;
                }
            }
            // to observe behavior in visualvm
            try {
                Thread.sleep(500);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        });

    }

    public static Map<String, Integer> pseudoQueryDatabase() {
        final Map<String, Integer> map = new TreeMap<>();
        IntStream.range(0, MAP_SIZE).forEach(i -> map.put(String.valueOf(i), i));
        return map;
    }

    public static void main(String[] args) throws Exception {
        new LeakTest().run();
    }
}

在每次pseudoQueryDatabase（）调用之后，映射实例应该准备好进行收集，但这不会发生，因为至少有一个Entry存储在其他地方。

根据您的jvm设置，应用程序可能会在早期因OutOfMemoryError而崩溃。

您可以从这个可视化虚拟机图中看到内存是如何保持增长的。

哈希数据结构（HashMap）不会发生同样的情况。

这是使用HashMap时的图形。

解决方案？只需直接保存键/值（您可能已经这样做了），而不是保存Map.Entry。

我在这里写了一个更广泛的基准。

这里有一个在纯Java中创建真正的内存泄漏（运行代码无法访问但仍存储在内存中的对象）的好方法：

应用程序创建一个长时间运行的线程（或者使用线程池更快地泄漏）。线程通过（可选的自定义）ClassLoader加载类。该类分配一大块内存（例如新字节[10000000]），在静态字段中存储对它的强引用，然后在ThreadLocal中存储对自身的引用。分配额外的内存是可选的（泄漏类实例就足够了），但这会使泄漏工作得更快。应用程序清除对自定义类或从中加载该类的ClassLoader的所有引用。重复

由于ThreadLocal在Oracle的JDK中的实现方式，这会造成内存泄漏：

每个线程都有一个私有字段threadLocals，它实际上存储线程本地值。此映射中的每个键都是对ThreadLocal对象的弱引用，因此在ThreadLocal对象被垃圾收集后，其条目将从映射中删除。但每个值都是一个强引用，因此当一个值（直接或间接）指向作为其键的ThreadLocal对象时，只要线程存在，该对象既不会被垃圾收集，也不会从映射中删除。

在本例中，强引用链如下所示：

线程对象→ threadLocals映射→ 示例类的实例→ 示例类→ 静态ThreadLocal字段→ ThreadLocal对象。

（ClassLoader在创建泄漏时并没有真正发挥作用，它只是因为这个额外的引用链而使泄漏变得更糟：example类→ 类加载器→ 它加载的所有类。在许多JVM实现中，尤其是在Java7之前，情况更糟，因为类和ClassLoader被直接分配到permagen中，根本不会被垃圾收集。）

这种模式的一个变体是，如果您经常重新部署碰巧使用ThreadLocal的应用程序，而这些应用程序在某种程度上指向自己，那么应用程序容器（如Tomcat）会像筛子一样泄漏内存。这种情况可能有许多微妙的原因，并且通常很难调试和/或修复。

更新：由于很多人一直在要求它，这里有一些示例代码显示了这种行为。

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

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

考虑：终止工作线程的基本模式是设置线程看到的一些条件变量。线程可以定期检查变量，并将其作为终止的信号。如果变量未声明为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的对象永远不会死。

一种可能是为ArrayList创建一个包装器，该包装器只提供一个方法：一个向ArrayList添加内容的方法。将ArrayList本身设为私有。现在，在全局范围中构造这些包装器对象之一（作为类中的静态对象），并用final关键字限定它（例如，public static final ArrayListWrapper wrapperClass=new ArrayListWrapper（））。因此，现在不能更改引用。也就是说，wrapperClass=null不起作用，不能用于释放内存。但是除了向wrapperClass中添加对象之外，也没有办法对wrapperClass进行任何操作。因此，添加到wrapperClass中的任何对象都不可能被回收。

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