什么是内存泄漏：

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

典型示例：

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

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对象引用了其他对象，则这些对象也引用了其他的对象。在某种程度上，您也可以认为这是某种内存泄漏（由糟糕的设计导致）。

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

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); }
}

内存泄漏的情况有很多种。我遇到了一个，它暴露了一个不应该在其他地方暴露和使用的地图。

public class ServiceFactory {

    private Map<String, Service> services;

    private static ServiceFactory singleton;

    private ServiceFactory() {
        services = new HashMap<String, Service>();
    }

    public static synchronized ServiceFactory getDefault() {

        if (singleton == null) {
            singleton = new ServiceFactory();
        }
        return singleton;
    }

    public void addService(String name, Service serv) {
        services.put(name, serv);
    }

    public void removeService(String name) {
        services.remove(name);
    }

    public Service getService(String name, Service serv) {
        return services.get(name);
    }

    // The problematic API, which exposes the map.
    // and user can do quite a lot of thing from this API.
    // for example, create service reference and forget to dispose or set it null
    // in all this is a dangerous API, and should not expose
    public Map<String, Service> getAllServices() {
        return services;
    }

}

// Resource class is a heavy class
class Service {

}

JDK 1.7之前内存泄漏的实时示例：

假设您读取了一个包含1000行文本的文件，并将其保存在String对象中：

String fileText = 1000 characters from file
fileText = fileText.subString(900, fileText.length());

在上面的代码中，我最初读取了1000个字符，然后执行了子字符串，只获得最后100个字符。现在，fileText应该只引用100个字符，所有其他字符都应该被垃圾收集，因为我丢失了引用，但是在JDK1.7之前，substring函数间接引用了最后100个字符的原始字符串，并阻止了整个字符串的垃圾收集，而整个1000个字符将一直保存在内存中，直到您丢失了对子字符串的引用。

您可以创建一个类似于上述的内存泄漏示例。

这里的大多数例子都“过于复杂”。它们是边缘案例。在这些例子中，程序员犯了一个错误（比如不要重新定义equals/hashcode），或者被JVM/JAVA的一个极端情况（用静态加载类…）所咬。我认为这不是面试官想要的例子，甚至不是最常见的例子。

但内存泄漏的情况确实更简单。垃圾收集器只释放不再引用的内容。我们作为Java开发人员并不关心内存。我们在需要时分配它，并让它自动释放。好的

但任何长寿命的应用程序都倾向于共享状态。它可以是任何东西，静态的，单态的。。。通常，非平凡的应用程序倾向于生成复杂的对象图。只是忘记将引用设置为null，或者更经常地忘记从集合中删除一个对象，就足以造成内存泄漏。

当然，如果处理不当，所有类型的侦听器（如UI侦听器）、缓存或任何长期共享状态都会产生内存泄漏。应该理解的是，这不是Java角落的情况，也不是垃圾收集器的问题。这是一个设计问题。我们设计为向长寿命对象添加侦听器，但在不再需要时不删除侦听器。我们缓存对象，但我们没有从缓存中删除它们的策略。

我们可能有一个复杂的图来存储计算所需的先前状态。但前一状态本身与前一状态相关联，依此类推。

就像我们必须关闭SQL连接或文件一样。我们需要设置对null的正确引用，并从集合中删除元素。我们应该有适当的缓存策略（最大内存大小、元素数量或计时器）。所有允许通知侦听器的对象必须同时提供addListener和removeListener方法。当这些通知器不再使用时，它们必须清除侦听器列表。

内存泄漏确实是可能的，而且完全可以预测。无需特殊的语言功能或角盒。内存泄漏要么是某些东西可能丢失的指示，甚至是设计问题。

您可以通过在类的finalize方法中创建类的新实例来创建移动内存泄漏。如果终结器创建多个实例，则会获得加分。下面是一个简单的程序，它可以在几秒钟到几分钟内泄漏整个堆，具体取决于堆的大小：

class Leakee {
    public void check() {
        if (depth > 2) {
            Leaker.done();
        }
    }
    private int depth;
    public Leakee(int d) {
        depth = d;
    }
    protected void finalize() {
        new Leakee(depth + 1).check();
        new Leakee(depth + 1).check();
    }
}

public class Leaker {
    private static boolean makeMore = true;
    public static void done() {
        makeMore = false;
    }
    public static void main(String[] args) throws InterruptedException {
        // make a bunch of them until the garbage collector gets active
        while (makeMore) {
            new Leakee(0).check();
        }
        // sit back and watch the finalizers chew through memory
        while (true) {
            Thread.sleep(1000);
            System.out.println("memory=" +
                    Runtime.getRuntime().freeMemory() + " / " +
                    Runtime.getRuntime().totalMemory());
        }
    }
}