我最近遇到了一种更微妙的资源泄漏。我们通过类加载器的getResourceAsStream打开资源，但碰巧输入流句柄没有关闭。

嗯，你可能会说，真是个白痴。

嗯，有趣的是：通过这种方式，您可以泄漏底层进程的堆内存，而不是JVM的堆内存。

您只需要一个jar文件，其中包含一个将从Java代码中引用的文件。jar文件越大，分配内存的速度越快。

您可以使用以下类轻松创建这样的jar：

import java.io.File;
import java.io.FileOutputStream;
import java.io.IOException;
import java.util.zip.ZipEntry;
import java.util.zip.ZipOutputStream;

public class BigJarCreator {
    public static void main(String[] args) throws IOException {
        ZipOutputStream zos = new ZipOutputStream(new FileOutputStream(new File("big.jar")));
        zos.putNextEntry(new ZipEntry("resource.txt"));
        zos.write("not too much in here".getBytes());
        zos.closeEntry();
        zos.putNextEntry(new ZipEntry("largeFile.out"));
        for (int i=0 ; i<10000000 ; i++) {
            zos.write((int) (Math.round(Math.random()*100)+20));
        }
        zos.closeEntry();
        zos.close();
    }
}

只需粘贴到名为BigJarCreator.java的文件中，从命令行编译并运行它：

javac BigJarCreator.java
java -cp . BigJarCreator

等等：您在当前工作目录中找到一个jar存档，其中包含两个文件。

让我们创建第二个类：

public class MemLeak {
    public static void main(String[] args) throws InterruptedException {
        int ITERATIONS=100000;
        for (int i=0 ; i<ITERATIONS ; i++) {
            MemLeak.class.getClassLoader().getResourceAsStream("resource.txt");
        }
        System.out.println("finished creation of streams, now waiting to be killed");

        Thread.sleep(Long.MAX_VALUE);
    }

}

这个类基本上什么都不做，只创建未引用的InputStream对象。这些对象将立即被垃圾收集，因此不会影响堆大小。对于我们的示例来说，从jar文件加载现有资源很重要，这里的大小很重要！

如果您有疑问，请尝试编译并启动上面的类，但确保选择了合适的堆大小（2MB）：

javac MemLeak.java
java -Xmx2m -classpath .:big.jar MemLeak

在这里您不会遇到OOM错误，因为没有保留引用，所以无论您在上面的示例中选择了多大的ITERATIONS，应用程序都将继续运行。除非应用程序执行wait命令，否则进程的内存消耗（在顶部（RES/RSS）或进程资源管理器中可见）会增加。在上面的设置中，它将分配大约150 MB的内存。

如果希望应用程序安全运行，请在创建输入流的位置关闭输入流：

MemLeak.class.getClassLoader().getResourceAsStream("resource.txt").close();

并且您的进程不会超过35MB，与迭代计数无关。

非常简单和令人惊讶。

一些建议：

在servlet容器中使用commons日志记录（可能有点挑衅）在servlet容器中启动线程，不要从其运行方法返回在servlet容器中加载动画GIF图像（这将启动一个动画线程）

通过重新部署应用程序，可以“改善”上述效果；）

我最近偶然发现：

调用“newjava.util.zip。充气器（）；”而不调用“充气器.end（）”

阅读http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5072161并将问题联系起来进行深入讨论。

我觉得有趣的是，没有人使用内部类示例。如果您有内部类；它固有地维护对包含类的引用。当然，从技术上讲，这不是内存泄漏，因为Java最终会清理掉它；但这会导致类停留的时间比预期的长。

public class Example1 {
  public Example2 getNewExample2() {
    return this.new Example2();
  }
  public class Example2 {
    public Example2() {}
  }
}

现在，如果您调用Example1并得到一个Example2丢弃Example1，那么您本质上仍然有一个到Example1对象的链接。

public class Referencer {
  public static Example2 GetAnExample2() {
    Example1 ex = new Example1();
    return ex.getNewExample2();
  }

  public static void main(String[] args) {
    Example2 ex = Referencer.GetAnExample2();
    // As long as ex is reachable; Example1 will always remain in memory.
  }
}

我还听到一个传言，如果你有一个变量存在的时间超过了一个特定的时间；Java假设它将永远存在，并且如果代码中无法访问它，它实际上永远不会尝试清理它。但这完全未经证实。

我在javax.swing.JPopupMenu中遇到了非常真实的内存泄漏。

我有一个GUI应用程序，它显示多个选项卡式文档。关闭文档后，如果在选项卡上的任何组件上使用了右键单击上下文菜单，它就会在内存中停留。这些菜单在选项卡之间共享，结果是，在调用popupMenu.show（component invoker，int x，int y）后，组件会作为菜单的“调用程序”静静地存在，直到下一次更改或被setInvoker（null）清除。间接地，调用者引用持久化了整个文档以及与之相关的所有内容。

值得注意的是，菜单只能以这种方式保存对旧组件的一个引用，因此这种内存泄漏不会在没有绑定的情况下增长。

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

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

import sun.misc.Unsafe;
import java.lang.reflect.Field;

public class Main {
    public static void main(String args[]) {
        try {
            Field f = Unsafe.class.getDeclaredField("theUnsafe");
            f.setAccessible(true);
            ((Unsafe) f.get(null)).allocateMemory(2000000000);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}