部署取消部署时Weblogic内存泄漏答案

【问题标题】：Weblogic memory leak on deploy undeploy部署取消部署时Weblogic内存泄漏
【发布时间】：2012-07-27 06:35:39
【问题描述】：

使用-Xmx1024m -Xms1024m 运行 32 位 JRockit R 28.2.4-14 的 Weblogic 10.3.5 在我们的 Java EE EAR 文件 5-8 次取消部署-重新部署周期后总是会耗尽本机内存。

根据错误信息和 VisualVM 中显示的内容，不是 Java Heap 太满，而是可用的系统内存不足。

java.lang.OutOfMemoryError: class allocation, 865324184 loaded, 464M footprint,
in check_alloc (src/jvm/model/classload/classalloc.c:215).

Attempting to allocate 1G bytes

There is insufficient native memory for the Java
Runtime Environment to continue.

Possible reasons:
  The system is out of physical RAM or swap space
  In 32 bit mode, the process size limit was hit
Possible solutions:
  Reduce memory load on the system
  Increase physical memory or swap space
  Check if swap backing store is full
  Use 64 bit Java on a 64 bit OS
  Decrease Java heap size (-Xmx/-Xms)
  Decrease number of Java threads
  Decrease Java thread stack sizes (-Xss)
  Disable compressed references (-XXcompressedRefs=false)

        at sun.misc.Unsafe.defineClass(Native Method)
        at sun.reflect.ClassDefiner.defineClass(ClassDefiner.java:45)
        at sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:381)
        at sun.reflect.MethodAccessorGenerator.generate(MethodAccessorGenerator.java:377)
        at sun.reflect.MethodAccessorGenerator.generateSerializationConstructor(MethodAccessorGenerator.java:95)
        at sun.reflect.ReflectionFactory.newConstructorForSerialization(ReflectionFactory.java:313)
        at java.io.ObjectStreamClass.getSerializableConstructor(ObjectStreamClass.java:1322)

我了解建议的可能解决方案，但如果应用程序只部署一次，一切都很好，因此在取消部署时似乎没有正确释放类。取消部署后的堆转储显示我们的许多类留在内存中。那他们不应该被垃圾收集吗？

GC Root 的路径显示一个线程<JNI Local> java.lang.Thread @ 0x129ac778 JDWP Transport Listener: dt_socket Native Stack, Thread。服务器上没有流量，我不知道为什么它仍然处于活动状态。

【问题讨论】：

标签： java jakarta-ee memory-leaks weblogic

【解决方案1】：

这种内存泄漏很可能是在 perm-gen 空间中引起的（这就是在 Hotspot JVM 上的调用方式）。 JRockit 没有专门的 Perm-Gen 空间，但为此使用“常规”堆空间。看看以下网站，我发现它们对了解这里发生的事情非常有帮助：

What is a PermGen leak

Busting PermGen Myths

【讨论】：

没错，这就是我在使用 Hotspot JVM 时遇到的错误。即使将 MaxPermGen 增加到 256M（1024 个！），我仍然会收到错误消息。我会检查您提供的链接...
根据您提供的链接，任何长时间运行的线程或数据库连接可能仍有引用。我暂停了一个通过 t3 访问服务器的批处理客户端，但这不是问题。取消部署后，我的一些对象仍然存在，查看引用我发现<JNI Local> java.lang.Thread @ 0x129ac778 JDWP Transport Listener: dt_socket Native Stack, Thread 显示为罪魁祸首。那个线程是什么，为什么它仍然活跃？
这看起来像一个调试连接。不附加调试器时是否也会发生内存泄漏？
是的，它们也会在没有附加调试器的情况下发生。

【解决方案2】：

我发现Eclipse MAT 对调试 PermGen 泄漏非常有帮助：

我的方法通常是这样的：

取消部署后进行堆转储
找到您的应用程序类之一（其实并不重要，都应该泄漏）。或者显示重复的类。
显示 GC 根目录的路径

为什么修复看起来取决于原因。

【讨论】：

我就是这么做的。请参阅问题的最后一段。在这种情况下，这个线程仍然是什么以及它为什么引用我的类并不能真正帮助我。
您找到解决方案了吗？ :)

【解决方案3】：

很可能某些类持有类加载器，这导致整个应用程序在重新部署时泄漏。你可以阅读this article about classloaders。

【讨论】：