Java内存泄漏的一个例子是当忘记调用ResultSets close方法时导致的MySQL内存泄漏错误。例如：

while(true) {
    ResultSet rs = database.select(query);
    ...
    // going to next step of loop and leaving resultset without calling rs.close();
}

什么是内存泄漏：

这是由错误或不良设计引起的。这是在浪费记忆。随着时间的推移，情况会变得更糟。垃圾收集器无法清理它。

典型示例：

对象缓存是一个很好的起点，可以让事情变得一团糟。

private static final Map<String, Info> myCache = new HashMap<>();

public void getInfo(String key)
{
    // uses cache
    Info info = myCache.get(key);
    if (info != null) return info;

    // if it's not in cache, then fetch it from the database
    info = Database.fetch(key);
    if (info == null) return null;

    // and store it in the cache
    myCache.put(key, info);
    return info;
}

您的缓存不断增长。很快整个数据库就被吸进了内存。更好的设计使用LRUMap（仅将最近使用的对象保存在缓存中）。

当然，你可以让事情变得更加复杂：

使用ThreadLocal构造。添加更复杂的参考树。或由第三方库引起的泄漏。

经常发生的情况：

如果此Info对象引用了其他对象，则这些对象也引用了其他的对象。在某种程度上，您也可以认为这是某种内存泄漏（由糟糕的设计导致）。

我曾经有过一次关于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）需要大约两天的时间才能到达。。。

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

面试官可能在寻找一个循环引用，比如下面的代码（顺便说一下，这只会在使用引用计数的非常旧的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永远不会收集单例实例。当部署应用程序的新实例时，通常会创建一个新的类加载器，而由于单例，前一个类加载器将继续存在。