如果最大堆大小为X.Y1….Yn实例数

因此，总内存=每个实例的实例数X字节。如果X1……Xn是每个实例的字节数，则总内存（M）=Y1*X1++Yn*Xn。因此，如果M>X，它将超过堆空间。

以下可能是代码中的问题

使用更多实例变量，然后使用局部变量。每次都创建实例，而不是共享对象。未按需创建对象。操作完成后使对象引用为空。再次，在程序中需要时重新创建。

对前面的答案有一点改进（为了更快地生成内存泄漏），就是使用从大型XML文件加载的DOM文档实例。

我最近修复的一个示例是创建新的GC和Image对象，但忘记调用dispose（）方法。

GC javadoc代码段：

应用程序代码必须显式调用GC.dispose（）方法以在以下情况下释放每个实例管理的操作系统资源不再需要这些实例。这一点尤为重要在Windows95和Windows98上可用的设备上下文数。

图像javadoc片段：

应用程序代码必须显式调用Image.dispose（）方法在以下情况下释放每个实例管理的操作系统资源不再需要这些实例。

我最近遇到了由log4j引起的内存泄漏情况。

Log4j有一种称为嵌套诊断上下文（NDC）的机制，它是一种区分不同来源的交织日志输出的工具。NDC工作的粒度是线程，因此它区分不同线程的日志输出。

为了存储线程特定的标记，log4j的NDC类使用一个Hashtable，该Hashtable由thread对象本身（而不是线程id）键控，因此直到NDC标记保留在内存中，挂在线程对象上的所有对象也保留在内存。在我们的web应用程序中，我们使用NDC标记带有请求id的登录，以将日志与单个请求区分开来。将NDC标记与线程关联的容器在返回请求响应时也会将其删除。在处理请求的过程中，产生了一个子线程，类似于以下代码：

pubclic class RequestProcessor {
    private static final Logger logger = Logger.getLogger(RequestProcessor.class);
    public void doSomething()  {
        ....
        final List<String> hugeList = new ArrayList<String>(10000);
        new Thread() {
           public void run() {
               logger.info("Child thread spawned")
               for(String s:hugeList) {
                   ....
               }
           }
        }.start();
    }
}    

因此，NDC上下文与派生的内联线程相关联。这个NDC上下文的关键线程对象是一个内联线程，它挂着hugeList对象。因此，即使线程完成了它正在做的事情，对hugeList的引用也会被NDC上下文Hastable保持活动状态，从而导致内存泄漏。

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

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

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

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

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

以在任何servlet容器（Tomcat、Jetty、GlassFish等）中运行的任何web应用程序为例。连续重新部署应用程序10或20次（只需在服务器的autodeploy目录中触摸WAR即可）。

除非有人真的测试过，否则在重新部署几次之后，很可能会出现OutOfMemoryError，因为应用程序没有注意自己的清理。通过此测试，您甚至可以在服务器中发现错误。

问题是，容器的生存期比应用程序的生存期长。您必须确保容器对应用程序的对象或类的所有引用都可以被垃圾收集。

如果只有一个引用在web应用程序的取消部署后仍然存在，则相应的类加载器以及web应用程序中的所有类都不能被垃圾收集。

应用程序启动的线程、ThreadLocal变量、日志附加器是导致类加载器泄漏的常见原因。