下面将有一个不明显的Java泄漏案例，除了被遗忘的侦听器、静态引用、哈希图中的伪/可修改键，或者只是线程被卡住而没有机会结束其生命周期的标准案例之外。

File.deleteOnExit（）-总是泄漏字符串，如果字符串是子字符串，则泄漏更严重（底层的char[]也泄漏）-在Java 7中，子字符串也会复制char[]，因此后者不适用@丹尼尔，不过不需要投票。

我将集中讨论线程，以展示非托管线程的危险性，甚至不希望触及摆动。

Runtime.addShutdownHook，不删除。。。然后，即使使用removeShutdownHook，由于ThreadGroup类中关于未启动线程的错误，它也可能无法被收集，从而有效地泄漏了ThreadGroup。JGroup在GossipRouter中有漏洞。创建一个线程，但不是启动它，它属于与上面相同的类别。创建线程继承ContextClassLoader和AccessControlContext，加上ThreadGroup和任何InheritedThreadLocal，所有这些引用都是潜在的泄漏，以及类加载器加载的所有类和所有静态引用，以及ja-ja。这种效果在整个j.u.c.Executor框架中尤其明显，该框架具有超简单的ThreadFactory接口，但大多数开发人员对潜在的危险一无所知。此外，许多库确实会根据请求启动线程（太多行业流行的库）。ThreadLocal缓存；这些在很多情况下都是邪恶的。我相信每个人都看到过很多基于ThreadLocal的简单缓存，但坏消息是：如果线程在上下文ClassLoader的生命周期中继续运行超过预期，这是一个非常好的小泄漏。除非确实需要，否则不要使用ThreadLocal缓存。当ThreadGroup本身没有线程，但仍保留子ThreadGroups时，调用ThreadGroup.destroy（）。一个严重的泄漏，将阻止ThreadGroup从其父级中删除，但所有子级都无法枚举。使用WeakHashMap和值（in）直接引用键。如果没有堆转储，这很难找到。这适用于可能将硬引用保留回受保护对象的所有扩展弱/软引用。将java.net.URL与HTTP（S）协议一起使用，并从（！）加载资源。这一个是特殊的，KeepAliveCache在系统ThreadGroup中创建了一个新线程，该线程泄漏了当前线程的上下文类加载器。当不存在活动线程时，线程会在第一个请求时创建，因此您可能会幸运，或者只是泄漏。泄漏在Java7中已经修复，创建线程的代码正确地删除了上下文类加载器。创建类似线程的情况很少（如ImageFetcher，也已修复）。使用充气器InputStream在构造函数（例如PNGImageDecoder）中传递新的java.util.zip充气器（），而不调用充气器的end（）。好吧，如果你只传递一个新的构造函数，就没有机会。。。是的，如果将其作为构造函数参数手动传递，则对流调用close（）不会关闭充气机。这不是真正的泄漏，因为它将由终结器释放。。。当它认为有必要时。直到那一刻，它会严重消耗本地内存，导致Linux oom_killer肆无忌惮地终止进程。主要的问题是，在Java中完成是非常不可靠的，G1使其更糟，直到7.0.2。故事的寓意：尽快释放本土资源；终结器太差了。与java.util.zip.Deflater的情况相同。这一情况更糟，因为Deflater在java中需要内存，即总是使用15位（最大值）和8个内存级别（最大值为9）来分配数百KB的本地内存。幸运的是，Deflater没有被广泛使用，据我所知，JDK没有任何误用。如果手动创建放气器或充气器，请始终调用end（）。最后两种方法中最棒的一点是：您无法通过常规的分析工具找到它们。

（我可以根据要求再添加一些我遇到的时间浪费者。）

祝你好运，保持安全；泄漏是邪恶的！

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

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

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

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

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

这里有一个在纯Java中创建真正的内存泄漏（运行代码无法访问但仍存储在内存中的对象）的好方法：

应用程序创建一个长时间运行的线程（或者使用线程池更快地泄漏）。线程通过（可选的自定义）ClassLoader加载类。该类分配一大块内存（例如新字节[10000000]），在静态字段中存储对它的强引用，然后在ThreadLocal中存储对自身的引用。分配额外的内存是可选的（泄漏类实例就足够了），但这会使泄漏工作得更快。应用程序清除对自定义类或从中加载该类的ClassLoader的所有引用。重复

由于ThreadLocal在Oracle的JDK中的实现方式，这会造成内存泄漏：

每个线程都有一个私有字段threadLocals，它实际上存储线程本地值。此映射中的每个键都是对ThreadLocal对象的弱引用，因此在ThreadLocal对象被垃圾收集后，其条目将从映射中删除。但每个值都是一个强引用，因此当一个值（直接或间接）指向作为其键的ThreadLocal对象时，只要线程存在，该对象既不会被垃圾收集，也不会从映射中删除。

在本例中，强引用链如下所示：

线程对象→ threadLocals映射→ 示例类的实例→ 示例类→ 静态ThreadLocal字段→ ThreadLocal对象。

（ClassLoader在创建泄漏时并没有真正发挥作用，它只是因为这个额外的引用链而使泄漏变得更糟：example类→ 类加载器→ 它加载的所有类。在许多JVM实现中，尤其是在Java7之前，情况更糟，因为类和ClassLoader被直接分配到permagen中，根本不会被垃圾收集。）

这种模式的一个变体是，如果您经常重新部署碰巧使用ThreadLocal的应用程序，而这些应用程序在某种程度上指向自己，那么应用程序容器（如Tomcat）会像筛子一样泄漏内存。这种情况可能有许多微妙的原因，并且通常很难调试和/或修复。

更新：由于很多人一直在要求它，这里有一些示例代码显示了这种行为。

面试官可能在寻找一个循环引用，比如下面的代码（顺便说一下，这只会在使用引用计数的非常旧的JVM中泄漏内存，而现在情况已经不是这样了）。但这是一个非常模糊的问题，因此这是展示您对JVM内存管理理解的绝佳机会。

class A {
    B bRef;
}

class B {
    A aRef;
}

public class Main {
    public static void main(String args[]) {
        A myA = new A();
        B myB = new B();
        myA.bRef = myB;
        myB.aRef = myA;
        myA=null;
        myB=null;
        /* at this point, there is no access to the myA and myB objects, */
        /* even though both objects still have active references. */
    } /* main */
}

然后您可以解释，使用引用计数，上面的代码会泄漏内存。但大多数现代JVM不再使用引用计数。大多数都使用一个清理垃圾收集器，它实际上会收集这些内存。

接下来，您可能会解释创建一个具有底层本机资源的Object，如下所示：

public class Main {
    public static void main(String args[]) {
        Socket s = new Socket(InetAddress.getByName("google.com"),80);
        s=null;
        /* at this point, because you didn't close the socket properly, */
        /* you have a leak of a native descriptor, which uses memory. */
    }
}

然后您可以解释这在技术上是内存泄漏，但实际上泄漏是由JVM中的本机代码分配底层本机资源造成的，而Java代码没有释放这些资源。

最后，对于现代JVM，您需要编写一些Java代码来分配JVM感知范围之外的本地资源。

如果您不了解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，这几乎是不可能的。

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