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

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 {

}

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

理论上你不能。Java内存模型阻止了这一点。但是，因为必须实现Java，所以可以使用一些警告。这取决于您可以使用什么：

如果可以使用本机，则可以分配以后不会放弃的内存。如果这是不可用的，那么Java有一个不为人知的小秘密。您可以请求一个不由GC管理的直接访问数组，因此可以很容易地用于造成内存泄漏。这由DirectByteBuffer提供(http://download.oracle.com/javase/1.5.0/docs/api/java/nio/ByteBuffer.html#allocateDirect（int））。如果不能使用其中任何一个，仍然可以通过欺骗GC来造成内存泄漏。JVM是使用一代垃圾收集来实现的。这意味着垃圾堆被划分为三个区域：年轻人、成年人和老年人。对象创建时从年轻区域开始。随着它被越来越多地使用，它逐渐发展到成人到老年人。最有可能到达接骨木区域的对象不会被垃圾收集。您无法确定对象是否泄漏，如果您请求停止并清理GC，它可能会清理它，但在很长一段时间内，它会泄漏。更多信息请访问(http://java.sun.com/docs/hotspot/gc1.4.2/faq.html)此外，类对象不需要是GC’ed。也许有办法做到这一点。

我可以从这里复制我的答案：在Java中导致内存泄漏的最简单方法

“在计算机科学中，当计算机程序消耗内存但无法将其释放回操作系统时，就会发生内存泄漏。”（维基百科）

简单的答案是：你不能。Java执行自动内存管理，并将释放您不需要的资源。你无法阻止这种情况的发生。它将始终能够释放资源。在具有手动内存管理的程序中，这是不同的。可以使用malloc（）在C中获得一些内存。要释放内存，您需要malloc返回的指针并对其调用free（）。但是，如果您不再拥有指针（被覆盖或超过生存期），那么很遗憾，您无法释放此内存，因此会出现内存泄漏。

到目前为止，所有其他答案在我的定义中都不是真正的内存泄漏。他们的目标都是快速用毫无意义的东西填满记忆。但在任何时候，您仍然可以取消引用创建的对象，从而释放内存-->无泄漏。尽管我不得不承认，acconrad的答案非常接近，因为他的解决方案实际上是通过强制垃圾收集器进入一个无休止的循环来“崩溃”垃圾收集器）。

长时间的答案是：通过使用JNI为Java编写库，可以获得内存泄漏，JNI可以进行手动内存管理，从而产生内存泄漏。如果调用此库，Java进程将泄漏内存。或者，JVM中可能存在bug，从而导致JVM丢失内存。JVM中可能存在bug，甚至可能存在一些已知的bug，因为垃圾收集并不是那么简单，但它仍然是一个bug。根据设计，这是不可能的。您可能需要一些受此类错误影响的Java代码。很抱歉，我不知道，而且在下一个Java版本中，它可能不再是一个bug。

任何时候，只要您保留对不再需要的对象的引用，就会出现内存泄漏。请参阅处理Java程序中的内存泄漏，以了解内存泄漏如何在Java中表现出来以及您可以如何处理它。