内存泄漏是一种资源泄漏，当计算机程序错误地管理内存分配，导致不再需要的内存无法释放时，就会发生这种情况=>维基百科定义

这是一种相对基于上下文的主题，你可以根据自己的喜好创建一个主题，只要未使用的引用永远不会被客户使用，但仍然存在。

第一个例子应该是一个自定义堆栈，而不取消有效Java第6项中过时的引用。

当然，只要你愿意，还有很多，但如果我们看看Java内置类，它可能是

子列表（）

让我们检查一些超级愚蠢的代码来产生泄漏。

public class MemoryLeak {
    private static final int HUGE_SIZE = 10_000;

    public static void main(String... args) {
        letsLeakNow();
    }

    private static void letsLeakNow() {
        Map<Integer, Object> leakMap = new HashMap<>();
        for (int i = 0; i < HUGE_SIZE; ++i) {
            leakMap.put(i * 2, getListWithRandomNumber());
        }
    }



    private static List<Integer> getListWithRandomNumber() {
        List<Integer> originalHugeIntList = new ArrayList<>();
        for (int i = 0; i < HUGE_SIZE; ++i) {
            originalHugeIntList.add(new Random().nextInt());
        }
        return originalHugeIntList.subList(0, 1);
    }
}

实际上，还有另一个技巧，我们可以利用HashMap的查找过程，使用HashMap造成内存泄漏。实际上有两种类型：

hashCode（）始终相同，但equals（）不同；使用随机hashCode（）和equals（）始终为true；

Why?

hashCode（）->bucket=>equals（）来定位该对

我打算先提到substring（），然后再提到subList（），但这个问题似乎已经解决了，因为它的源代码在JDK8中。

public String substring(int beginIndex, int endIndex) {
    if (beginIndex < 0) {
        throw new StringIndexOutOfBoundsException(beginIndex);
    }
    if (endIndex > value.length) {
        throw new StringIndexOutOfBoundsException(endIndex);
    }
    int subLen = endIndex - beginIndex;
    if (subLen < 0) {
        throw new StringIndexOutOfBoundsException(subLen);
    }
    return ((beginIndex == 0) && (endIndex == value.length)) ? this
            : new String(value, beginIndex, subLen);
}

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

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

Java中不存在内存泄漏。内存泄漏是从C等人那里借来的一个短语。Java借助GC在内部处理内存分配。存在内存浪费（即留下滞留对象），但没有内存泄漏。

任何时候，只要您保留对不再需要的对象的引用，就会出现内存泄漏。请参阅处理Java程序中的内存泄漏，以了解内存泄漏如何在Java中表现出来以及您可以如何处理它。

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

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

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

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

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

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

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

重叠侦听器是内存泄漏的一个很好的例子：对象被添加为侦听器。当不再需要对象时，对象的所有引用都为空。然而，忘记从侦听器列表中删除对象会使对象保持活动状态，甚至对事件做出响应，从而浪费内存和CPU。看见http://www.drdobbs.com/jvm/java-qa/184404011