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

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 {

}

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

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

线程在终止之前不会被收集。它们是垃圾收集的根源。它们是少数几个不能简单地通过忘记它们或清除对它们的引用来回收的对象之一。

考虑：终止工作线程的基本模式是设置线程看到的一些条件变量。线程可以定期检查变量，并将其作为终止的信号。如果变量未声明为volatile，那么线程可能看不到对变量的更改，因此它不知道终止。或者想象一下，如果一些线程想要更新共享对象，但在试图锁定该对象时出现死锁。

如果您只有少数线程，这些错误可能会很明显，因为您的程序将停止正常工作。如果您有一个线程池，可以根据需要创建更多线程，那么过时/卡住的线程可能不会被注意到，并且会无限累积，从而导致内存泄漏。线程可能会在应用程序中使用其他数据，因此也会阻止收集它们直接引用的任何数据。

作为玩具示例：

static void leakMe(final Object object) {
    new Thread() {
        public void run() {
            Object o = object;
            for (;;) {
                try {
                    sleep(Long.MAX_VALUE);
                } catch (InterruptedException e) {}
            }
        }
    }.start();
}

可以任意调用System.gc（），但传递给leakMe的对象永远不会死。

什么是内存泄漏：

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

典型示例：

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

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

正如许多人所建议的那样，资源泄漏很容易造成，就像JDBC示例一样。实际的内存泄漏有点困难——尤其是如果您不依赖JVM中的碎片来为您进行泄漏。。。

创建占地面积非常大的对象，然后无法访问这些对象的想法也不是真正的内存泄漏。如果没有东西可以访问它，那么它将被垃圾收集，如果有东西可以访问，那么它就不是泄漏。。。

然而，一种曾经有效的方法——我不知道它是否仍然有效——是有一条三深的环形链。正如在对象A中有对对象B的引用，对象B有对对象C的引用，而对象C有对对象A的引用。GC足够聪明，知道如果A和B不能被任何其他对象访问，但不能处理三方链，则可以安全地收集两个深链（如在A<-->B中）。。。

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

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

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