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

我认为，一个有效的例子可能是在线程集中的环境中使用ThreadLocal变量。

例如，使用Servlet中的ThreadLocal变量与其他web组件通信，让容器创建线程，并在池中维护空闲线程。ThreadLocal变量如果没有正确清理，将一直存在，直到同一个web组件覆盖它们的值。

当然，一旦确定，问题很容易解决。

以在任何servlet容器（Tomcat、Jetty、GlassFish等）中运行的任何web应用程序为例。连续重新部署应用程序10或20次（只需在服务器的autodeploy目录中触摸WAR即可）。

除非有人真的测试过，否则在重新部署几次之后，很可能会出现OutOfMemoryError，因为应用程序没有注意自己的清理。通过此测试，您甚至可以在服务器中发现错误。

问题是，容器的生存期比应用程序的生存期长。您必须确保容器对应用程序的对象或类的所有引用都可以被垃圾收集。

如果只有一个引用在web应用程序的取消部署后仍然存在，则相应的类加载器以及web应用程序中的所有类都不能被垃圾收集。

应用程序启动的线程、ThreadLocal变量、日志附加器是导致类加载器泄漏的常见原因。

我觉得有趣的是，没有人使用内部类示例。如果您有内部类；它固有地维护对包含类的引用。当然，从技术上讲，这不是内存泄漏，因为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假设它将永远存在，并且如果代码中无法访问它，它实际上永远不会尝试清理它。但这完全未经证实。

我最近遇到了由log4j引起的内存泄漏情况。

Log4j有一种称为嵌套诊断上下文（NDC）的机制，它是一种区分不同来源的交织日志输出的工具。NDC工作的粒度是线程，因此它区分不同线程的日志输出。

为了存储线程特定的标记，log4j的NDC类使用一个Hashtable，该Hashtable由thread对象本身（而不是线程id）键控，因此直到NDC标记保留在内存中，挂在线程对象上的所有对象也保留在内存。在我们的web应用程序中，我们使用NDC标记带有请求id的登录，以将日志与单个请求区分开来。将NDC标记与线程关联的容器在返回请求响应时也会将其删除。在处理请求的过程中，产生了一个子线程，类似于以下代码：

pubclic class RequestProcessor {
    private static final Logger logger = Logger.getLogger(RequestProcessor.class);
    public void doSomething()  {
        ....
        final List<String> hugeList = new ArrayList<String>(10000);
        new Thread() {
           public void run() {
               logger.info("Child thread spawned")
               for(String s:hugeList) {
                   ....
               }
           }
        }.start();
    }
}    

因此，NDC上下文与派生的内联线程相关联。这个NDC上下文的关键线程对象是一个内联线程，它挂着hugeList对象。因此，即使线程完成了它正在做的事情，对hugeList的引用也会被NDC上下文Hastable保持活动状态，从而导致内存泄漏。

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

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

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