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

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

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

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

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

我在javax.swing.JPopupMenu中遇到了非常真实的内存泄漏。

我有一个GUI应用程序，它显示多个选项卡式文档。关闭文档后，如果在选项卡上的任何组件上使用了右键单击上下文菜单，它就会在内存中停留。这些菜单在选项卡之间共享，结果是，在调用popupMenu.show（component invoker，int x，int y）后，组件会作为菜单的“调用程序”静静地存在，直到下一次更改或被setInvoker（null）清除。间接地，调用者引用持久化了整个文档以及与之相关的所有内容。

值得注意的是，菜单只能以这种方式保存对旧组件的一个引用，因此这种内存泄漏不会在没有绑定的情况下增长。

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

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

每个人都会忘记本机代码路径。以下是泄漏的简单公式：

声明本机方法。在本机方法中，调用malloc。不要打免费电话。调用本机方法。

记住，本机代码中的内存分配来自JVM堆。

这里有一个非常简单的Java程序，它将耗尽空间

public class OutOfMemory {

    public static void main(String[] arg) {

        List<Long> mem = new LinkedList<Long>();
        while (true) {
            mem.add(new Long(Long.MAX_VALUE));
        }
    }
}

GUI代码中的一个常见示例是创建小部件/组件并向某个静态/应用程序范围的对象添加侦听器，然后在小部件被破坏时不删除侦听器。不仅会出现内存泄漏，而且性能也会受到影响，因为无论你听什么都会引发事件，所有的老听众都会被调用。