我曾经有过一次关于PermGen和XML解析的“内存泄漏”。我们使用的XML解析器（我记不清是哪一个）对标记名执行String.intern（），以加快比较速度。我们的一位客户有一个好主意，不将数据值存储在XML属性或文本中，而是将其存储为标记名，因此我们有了这样一个文档：

<data>
   <1>bla</1>
   <2>foo</>
   ...
</data>

事实上，他们没有使用数字，而是使用更长的文本ID（约20个字符），这些ID是唯一的，每天的使用率为1000万至1000万。这使得每天有200 MB的垃圾，而这些垃圾再也不需要了，也永远不会被GCed（因为它在PermGen中）。我们将permagen设置为512MB，因此内存不足异常（OOME）需要大约两天的时间才能到达。。。

创建一个静态映射并不断添加硬引用。这些永远不会被垃圾收集。

public class Leaker {
    private static final Map<String, Object> CACHE = new HashMap<String, Object>();

    // Keep adding until failure.
    public static void addToCache(String key, Object value) { Leaker.CACHE.put(key, value); }
}

我在Java中看到的大多数内存泄漏都与进程不同步有关。

进程A通过TCP与B对话，并告诉进程B创建一些东西。B向资源发出一个ID，比如432423，A将其存储在一个对象中，并在与B对话时使用。在某些情况下，A中的对象会被垃圾收集回收（可能是由于错误），但A从不告诉B这一点（可能是另一个错误）。

现在A不再拥有它在B的RAM中创建的对象的ID，B也不知道A不再引用该对象。实际上，对象是泄漏的。

如果您不了解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永远不会收集单例实例。当部署应用程序的新实例时，通常会创建一个新的类加载器，而由于单例，前一个类加载器将继续存在。

重叠侦听器是内存泄漏的一个很好的例子：对象被添加为侦听器。当不再需要对象时，对象的所有引用都为空。然而，忘记从侦听器列表中删除对象会使对象保持活动状态，甚至对事件做出响应，从而浪费内存和CPU。看见http://www.drdobbs.com/jvm/java-qa/184404011

要做的一件简单的事情是使用带有不正确（或不存在）hashCode（）或equals（）的HashSet，然后继续添加“重复项”。而不是像应该的那样忽略重复项，集合只会增长，您将无法删除它们。

如果你想让这些坏键/元素到处乱动，你可以使用一个静态字段，比如

class BadKey {
   // no hashCode or equals();
   public final String key;
   public BadKey(String key) { this.key = key; }
}

Map map = System.getProperties();
map.put(new BadKey("key"), "value"); // Memory leak even if your threads die.