您可以使用sun.misc.Unsafe类进行内存泄漏。事实上，这个服务类用于不同的标准类（例如java.nio类）。不能直接创建此类的实例，但可以使用反射来获取实例。

代码不会在EclipseIDE中编译-使用javac命令编译代码（编译期间，您会收到警告）

import java.lang.reflect.Constructor;
import java.lang.reflect.Field;
import sun.misc.Unsafe;

public class TestUnsafe {

    public static void main(String[] args) throws Exception{
        Class unsafeClass = Class.forName("sun.misc.Unsafe");
        Field f = unsafeClass.getDeclaredField("theUnsafe");
        f.setAccessible(true);
        Unsafe unsafe = (Unsafe) f.get(null);
        System.out.print("4..3..2..1...");
        try
        {
            for(;;)
                unsafe.allocateMemory(1024*1024);
        } catch(Error e) {
            System.out.println("Boom :)");
            e.printStackTrace();
        }
    }
}

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

我觉得有趣的是，没有人使用内部类示例。如果您有内部类；它固有地维护对包含类的引用。当然，从技术上讲，这不是内存泄漏，因为Java最终会清理掉它；但这会导致类停留的时间比预期的长。

public class Example1 {
  public Example2 getNewExample2() {
    return this.new Example2();
  }
  public class Example2 {
    public Example2() {}
  }
}

现在，如果您调用Example1并得到一个Example2丢弃Example1，那么您本质上仍然有一个到Example1对象的链接。

public class Referencer {
  public static Example2 GetAnExample2() {
    Example1 ex = new Example1();
    return ex.getNewExample2();
  }

  public static void main(String[] args) {
    Example2 ex = Referencer.GetAnExample2();
    // As long as ex is reachable; Example1 will always remain in memory.
  }
}

我还听到一个传言，如果你有一个变量存在的时间超过了一个特定的时间；Java假设它将永远存在，并且如果代码中无法访问它，它实际上永远不会尝试清理它。但这完全未经证实。

这是一个简单/险恶的http://wiki.eclipse.org/Performance_Bloopers#String.substring.28.29.

public class StringLeaker
{
    private final String muchSmallerString;

    public StringLeaker()
    {
        // Imagine the whole Declaration of Independence here
        String veryLongString = "We hold these truths to be self-evident...";

        // The substring here maintains a reference to the internal char[]
        // representation of the original string.
        this.muchSmallerString = veryLongString.substring(0, 1);
    }
}

因为子字符串指的是原始字符串的内部表示，所以原始字符串会保留在内存中。因此，只要你有一个StringLeaker在玩，你的记忆中也有整个原始字符串，即使你可能认为你只是在保存一个字符串。

避免存储对原始字符串的不需要的引用的方法如下：

...
this.muchSmallerString = new String(veryLongString.substring(0, 1));
...

为了增加坏处，您还可以.intern（）子字符串：

...
this.muchSmallerString = veryLongString.substring(0, 1).intern();
...

这样做将在内存中保留原始的长字符串和派生的子字符串，即使在StringLeaker实例被丢弃之后也是如此。

我想就如何使用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将分析内存并向您提供有关内存泄漏的可疑信息。

正如许多人所建议的那样，资源泄漏很容易造成，就像JDBC示例一样。实际的内存泄漏有点困难——尤其是如果您不依赖JVM中的碎片来为您进行泄漏。。。

创建占地面积非常大的对象，然后无法访问这些对象的想法也不是真正的内存泄漏。如果没有东西可以访问它，那么它将被垃圾收集，如果有东西可以访问，那么它就不是泄漏。。。

然而，一种曾经有效的方法——我不知道它是否仍然有效——是有一条三深的环形链。正如在对象A中有对对象B的引用，对象B有对对象C的引用，而对象C有对对象A的引用。GC足够聪明，知道如果A和B不能被任何其他对象访问，但不能处理三方链，则可以安全地收集两个深链（如在A<-->B中）。。。