也许通过JNI使用外部本机代码？

使用纯Java，这几乎是不可能的。

但这是一种“标准”类型的内存泄漏，即您无法再访问内存，但它仍然属于应用程序。相反，您可以保留对未使用对象的引用，或者打开流而不关闭它们。

也许通过JNI使用外部本机代码？

使用纯Java，这几乎是不可能的。

但这是一种“标准”类型的内存泄漏，即您无法再访问内存，但它仍然属于应用程序。相反，您可以保留对未使用对象的引用，或者打开流而不关闭它们。

这很简单：

Object[] o = new Object[]{};
while(true) {
    o = new Object[]{o};
}

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

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

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

我最近遇到了由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保持活动状态，从而导致内存泄漏。

我认为还没有人说过这一点：你可以通过重写finalize（）方法来复活一个对象，这样finalize）就可以在某个地方存储对它的引用。垃圾回收器只会在对象上调用一次，因此在此之后，对象将永远不会被销毁。