可能是潜在内存泄漏以及如何避免它的最简单示例之一，是ArrayList.remove（int）的实现：

public E remove(int index) {
    RangeCheck(index);

    modCount++;
    E oldValue = (E) elementData[index];

    int numMoved = size - index - 1;
    if (numMoved > 0)
        System.arraycopy(elementData, index + 1, elementData, index,
                numMoved);
    elementData[--size] = null; // (!) Let gc do its work

    return oldValue;
}

如果您是自己实现的，您是否想过清除不再使用的数组元素（elementData[-size]=null）？该引用可能会使一个巨大的对象保持活力。。。

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

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

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

另一种可能造成巨大内存泄漏的方法是保存对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中，“内存泄漏”主要是因为您使用了太多内存，这与在C中不同，在C中，您不再使用内存，而是忘记返回（释放）内存。当面试官询问Java内存泄漏时，他们询问的是JVM内存使用情况，但似乎一直在增加，他们认为定期重新启动JVM是最好的解决方案（除非面试官非常精通技术）。

所以，回答这个问题，就像他们问JVM内存使用量随时间增长的原因一样。好的答案是在HttpSessions中存储太多数据，超时时间过长，或者内存缓存（singleton）实现不佳，从不刷新旧条目。另一个可能的答案是拥有大量JSP或动态生成的类。类被加载到一个名为PermGen的内存区域，该区域通常很小，大多数JVM不实现类卸载。

创建一个只包含while true循环的JNI函数，并用另一个线程的大型对象调用它。GC不太喜欢JNI，并且会将对象永久保存在内存中。

就像这样！

public static void main(String[] args) {
    List<Object> objects = new ArrayList<>();
    while(true) {
        objects.add(new Object());
    }
}