我正在调试一个多年来在 Tomcat 应用程序中遇到的问题 - 由于 Webapp 类加载器无法进行 GC，因此在重新启动应用程序时导致内存泄漏。我已经用 JProfiler 拍摄了堆的快照，似乎至少我的一些静态变量没有被释放。
某些类有一个静态最终成员，该成员在首次加载该类时被初始化，因为它是最终的，所以我无法在应用关闭时将其设置为 null。
静态最终变量是 Tomcat 中的反模式，还是我遗漏了什么？我刚刚开始使用 JProfiler 8，所以我可能会误解传入的引用告诉我的内容。
干杯！
卢克
【问题讨论】：
标签： java tomcat memory-leaks jprofiler
这是几年前的事了，但我在 JavaOne 上给出的 presentation 正好涵盖了这个主题。找到泄漏的关键步骤在幻灯片 11 中，但也有许多可能有用的背景信息。
简短的版本是：
正如我在演示文稿中指出的那样，找到漏洞是一回事，找到触发它们的原因可能要困难得多。
我建议在最新的稳定 Tomcat 版本上运行，因为我们一直在改进内存泄漏检测和预防代码，并且生成的警告和错误也可能提供一些指示。
【讨论】：
当类本身被垃圾回收时，静态变量应该被垃圾回收，而当它的类加载器被垃圾回收时也是如此。
您可以通过引用您的任何类（或您的类的实例）的应用程序类加载器未加载的任何内容轻松创建内存泄漏。查找您没有正确删除的回调侦听器等内容（内部/匿名类很容易被忽略）。
对您的某个类的单一引用会阻止其类加载器，进而阻止该类加载器加载的任何类被垃圾回收。
编辑，泄漏阻止所有类 GC 的对象的示例：
MemoryMXBean mx = ManagementFactory.getMemoryMXBean();
NotificationListener nl = new NotificationListener() { ... };
((NotificationEmitter) mx).addNotificationListener(nl, ..., ...);
如果您使用存在于应用程序范围之外的对象（此处为 MemoryMXBean）注册侦听器（此处为 NotificationListener），则您的侦听器将保持“活动”状态，直到显式删除。由于您的侦听器实例持有对其 ClassLoader（您的应用程序类加载器）的引用，您现在已经创建了一个强大的引用链，阻止了类加载器的 GC，进而阻止了它加载的所有类，以及这些类持有的任何静态变量。
Edit2：基本上你需要避免这种情况：
[Root ClassLoader]
|
v
[Application ClassLoader]
|
v
(Type loaded by Root).addSomething()
运行应用程序服务器的 JVM 已经通过根类加载器（可能还有应用程序服务器）加载了 JRE。这意味着这些类永远不会有资格进行 GC，因为其中一些类总是会被实时引用。应用程序服务器将在一个单独的类加载器中加载您的应用程序，当您的应用程序被重新部署（或至少应该）时，它将不再持有对它的引用。但是您的应用程序将与应用程序服务器（至少是 JRE，但通常还有应用程序服务器）共享来自至少 JRE 的所有类。
在假设情况下，当应用程序服务器要创建一个单独的类加载器（没有父类，实际上是第二个根类加载器）并尝试第二次加载 JRE（作为您的应用程序的私有）时，它会导致很多问题。打算成为单例的类将存在两次，并且两个类层次结构将无法保存另一个的任何引用（由不同的类加载器加载的同一类对 JVM 的不同类型造成）。他们甚至不能使用 java.lang.Object 作为相应“其他”类加载器对象的引用类型。
【讨论】：
这个Blog 可以让您了解应用程序中的内存泄漏。
【讨论】：