从finalize方法引发未处理的异常。

如果您不了解JDBC，下面是一个毫无意义的示例。或者至少是JDBC希望开发人员在丢弃Connection、Statement和ResultSet实例或丢失对它们的引用之前关闭它们，而不是依赖于实现finalize方法。

void doWork() {
    try {
        Connection conn = ConnectionFactory.getConnection();
        PreparedStatement stmt = conn.preparedStatement("some query");
        // executes a valid query
        ResultSet rs = stmt.executeQuery();
        while(rs.hasNext()) {
            // ... process the result set
        }
    } catch(SQLException sqlEx) {
        log(sqlEx);
    }
}

上面的问题是Connection对象没有关闭，因此物理Connection将保持打开状态，直到垃圾回收器返回并发现它不可访问为止。GC将调用finalize方法，但有些JDBC驱动程序没有实现finalize，至少与Connection.close的实现方式不同。由此产生的行为是，尽管JVM将由于收集不可访问的对象而回收内存，但与Connection对象关联的资源（包括内存）可能不会被回收。

因此，Connection的最终方法并不能清除所有内容。人们可能会发现，到数据库服务器的物理连接将持续几个垃圾收集周期，直到数据库服务器最终发现该连接不活动（如果存在），应该关闭。

即使JDBC驱动程序实现了finalize，编译器也可以在finalize期间抛出异常。由此产生的行为是，与现在“休眠”对象关联的任何内存都不会被编译器回收，因为finalize保证只被调用一次。

上述在对象完成过程中遇到异常的场景与另一种可能导致内存泄漏的场景有关——对象复活。对象复活通常是通过创建一个从另一个对象最终确定的对象的强引用来实现的。当对象复活被误用时，它将与其他内存泄漏源一起导致内存泄漏。

还有很多例子你可以想象出来

管理列表实例，其中您只添加到列表中，而不从列表中删除（尽管您应该删除不再需要的元素），或者打开套接字或文件，但不再需要时不关闭它们（类似于上面涉及Connection类的示例）。在关闭Java EE应用程序时不卸载Singleton。加载单例类的Classloader将保留对该类的引用，因此JVM永远不会收集单例实例。当部署应用程序的新实例时，通常会创建一个新的类加载器，而由于单例，前一个类加载器将继续存在。

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

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

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

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

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

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

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

GC javadoc代码段：

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

图像javadoc片段：

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

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

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

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

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

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