我可以从这里复制我的答案：在Java中导致内存泄漏的最简单方法

“在计算机科学中，当计算机程序消耗内存但无法将其释放回操作系统时，就会发生内存泄漏。”（维基百科）

简单的答案是：你不能。Java执行自动内存管理，并将释放您不需要的资源。你无法阻止这种情况的发生。它将始终能够释放资源。在具有手动内存管理的程序中，这是不同的。可以使用malloc（）在C中获得一些内存。要释放内存，您需要malloc返回的指针并对其调用free（）。但是，如果您不再拥有指针（被覆盖或超过生存期），那么很遗憾，您无法释放此内存，因此会出现内存泄漏。

到目前为止，所有其他答案在我的定义中都不是真正的内存泄漏。他们的目标都是快速用毫无意义的东西填满记忆。但在任何时候，您仍然可以取消引用创建的对象，从而释放内存-->无泄漏。尽管我不得不承认，acconrad的答案非常接近，因为他的解决方案实际上是通过强制垃圾收集器进入一个无休止的循环来“崩溃”垃圾收集器）。

长时间的答案是：通过使用JNI为Java编写库，可以获得内存泄漏，JNI可以进行手动内存管理，从而产生内存泄漏。如果调用此库，Java进程将泄漏内存。或者，JVM中可能存在bug，从而导致JVM丢失内存。JVM中可能存在bug，甚至可能存在一些已知的bug，因为垃圾收集并不是那么简单，但它仍然是一个bug。根据设计，这是不可能的。您可能需要一些受此类错误影响的Java代码。很抱歉，我不知道，而且在下一个Java版本中，它可能不再是一个bug。

我曾经有过一次关于PermGen和XML解析的“内存泄漏”。我们使用的XML解析器（我记不清是哪一个）对标记名执行String.intern（），以加快比较速度。我们的一位客户有一个好主意，不将数据值存储在XML属性或文本中，而是将其存储为标记名，因此我们有了这样一个文档：

<data>
   <1>bla</1>
   <2>foo</>
   ...
</data>

事实上，他们没有使用数字，而是使用更长的文本ID（约20个字符），这些ID是唯一的，每天的使用率为1000万至1000万。这使得每天有200 MB的垃圾，而这些垃圾再也不需要了，也永远不会被GCed（因为它在PermGen中）。我们将permagen设置为512MB，因此内存不足异常（OOME）需要大约两天的时间才能到达。。。

面试官可能在寻找一个循环引用，比如下面的代码（顺便说一下，这只会在使用引用计数的非常旧的JVM中泄漏内存，而现在情况已经不是这样了）。但这是一个非常模糊的问题，因此这是展示您对JVM内存管理理解的绝佳机会。

class A {
    B bRef;
}

class B {
    A aRef;
}

public class Main {
    public static void main(String args[]) {
        A myA = new A();
        B myB = new B();
        myA.bRef = myB;
        myB.aRef = myA;
        myA=null;
        myB=null;
        /* at this point, there is no access to the myA and myB objects, */
        /* even though both objects still have active references. */
    } /* main */
}

然后您可以解释，使用引用计数，上面的代码会泄漏内存。但大多数现代JVM不再使用引用计数。大多数都使用一个清理垃圾收集器，它实际上会收集这些内存。

接下来，您可能会解释创建一个具有底层本机资源的Object，如下所示：

public class Main {
    public static void main(String args[]) {
        Socket s = new Socket(InetAddress.getByName("google.com"),80);
        s=null;
        /* at this point, because you didn't close the socket properly, */
        /* you have a leak of a native descriptor, which uses memory. */
    }
}

然后您可以解释这在技术上是内存泄漏，但实际上泄漏是由JVM中的本机代码分配底层本机资源造成的，而Java代码没有释放这些资源。

最后，对于现代JVM，您需要编写一些Java代码来分配JVM感知范围之外的本地资源。

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

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

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

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

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

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

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

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

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

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

我想就如何使用JVM中可用的工具监视应用程序的内存泄漏提供建议。它没有显示如何生成内存泄漏，但解释了如何使用最少的可用工具检测内存泄漏。

您需要首先监视Java内存消耗。

最简单的方法是使用JVM附带的jstat实用程序：

jstat -gcutil <process_id> <timeout>

它将报告每一代（年轻、老年和老年）的内存消耗和垃圾收集时间（年轻和完整）。

一旦您发现一个完整的垃圾收集执行得太频繁并且花费了太多时间，您就可以假设应用程序正在泄漏内存。

然后需要使用jmap实用程序创建内存转储：

jmap -dump:live,format=b,file=heap.bin <process_id>

然后需要使用内存分析器（例如Eclipse memory Analyzer（MAT））分析heap.bin文件。

MAT将分析内存并向您提供有关内存泄漏的可疑信息。