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

1. 该应用程序将创建一个长期运行的线程（或使用线程池更快地泄漏）。
2. 线程通过（可选，自定义）加载类ClassLoader。
3. 该类分配大量的内存（例如new byte[1000000]），在静态字段中存储对它的强引用，然后在中存储对自身的引用ThreadLocal。分配额外的内存是可选的（泄漏类实例就足够了），但是它将使泄漏工作快得多。
4. 应用程序清除对自定义类或ClassLoader从中加载的所有引用。
5. 重复。

由于该方法ThreadLocal是在Oracle的JDK中实现的，因此会造成内存泄漏：

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

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

Thread对象→ threadLocals地图→示例类的实例→示例类→静态ThreadLocal字段→ ThreadLocal对象。

（ClassLoader在创建泄漏中并没有真正起作用，它只是由于以下附加引用链而使泄漏更糟：示例类→→ ClassLoader它已加载的所有类。在许多JVM实现中，甚至更糟，尤其是在之前Java 7，因为类和ClassLoaders是直接分配到permgen中的，并且根本不会被垃圾回收。）

这种模式的一个变种是，如果你频繁地重新部署碰巧使用ThreadLocals的应用程序，而应用程序容器（例如Tomcat）像sieve 那样以某种方式指向自身，那么它可以像筛子一样泄漏内存。发生这种情况的原因很多，通常很难调试和/或修复。

更新：由于很多人一直在要求它，因此以下示例代码展示了这种行为。

静态字段保存对象参考[特别是最终字段]

class MemorableClass {
    static final ArrayList list = new ArrayList(100);
}

调用String.intern()冗长的字符串

String str=readString(); // read lengthy string any source db,textbox/jsp etc..
// This will place the string in memory pool from which you can't remove
str.intern();

（未关闭）打开的流（file , network etc…）

try {
    BufferedReader br = new BufferedReader(new FileReader(inputFile));
    ...
    ...
} catch (Exception e) {
    e.printStacktrace();
}

未封闭的连接

try {
    Connection conn = ConnectionFactory.getConnection();
    ...
    ...
} catch (Exception e) {
    e.printStacktrace();
}

JVM的垃圾收集器无法访问的区域，例如通过本机方法分配的内存

在Web应用程序中，某些对象存储在应用程序范围内，直到明确停止或删除该应用程序为止。

getServletContext().setAttribute("SOME_MAP", map);

错误或不适当的JVM选项，例如noclassgc防止未使用的类垃圾回收的IBM JDK上的选项