在 Wildfly 8.2.1 上部署的 Java 8 应用程序的元空间内存消耗问题

Posted 2023-02-27

【中文标题】在 Wildfly 8.2.1 上部署的 Java 8 应用程序的元空间内存消耗问题

【英文标题】：Metaspace memory concumption issues of Java 8 applications deployed on Wildfly 8.2.1

【发布时间】：2016-01-17 23:21:33

【问题描述】：

问题描述

我注意到，我们在 Wildfly 8.2.1 上的 Java8 应用程序的每次部署都使用大约 30-40 MB 的 Metaspace 内存池。这很好，但问题是，一旦我重新部署同一个应用程序，元空间内存使用量将增加相同的 30-40 MB，而旧的已分配内存不会被释放。

我什至不会注意到它，但问题是我们有大约 20 个应用程序，有时我需要同时重新部署多达 10 个应用程序。这反过来又导致了一幅可怕的画面。

基本上显示的是约 10 个应用程序的 2 次重新部署。

我不确定为什么 GC 不能释放分配给旧类的内存。该服务器总共有 16GB 物理内存，因此我最多可以重新部署所有应用程序 20-40 次，仅此而已。应用服务器将达到限制并停止响应任何命令。

因此，如果有人可以帮助我了解实际问题可能是什么，我将非常感激：

是 Java8 问题吗？ (jdk 1.8.0_40-b26) 这是 Wildfly 8.2.1 的问题吗？ 或者答案是否尽可能简单，原因是我的代码库？如果是这样，那么请您指导我可能是什么实际原因？

与我的代码库相关的更多细节

1) 我与 Wildfly 一起使用 2 个独立的 HornetQ 服务器，每个应用程序使用约 5 个通道，每个通道至少有 5 个并发消费者。这反过来导致每个应用程序至少有 25 个线程，总共至少 25*20 = 500 个线程。

2) 对于所有低级 JMS 操作，我使用 Spring JMS。

【参考方案1】：

要凭经验确定泄漏的位置和位置（您可能没有泄漏 - 它可能只是在部署期间出于正当原因加载了合法类），您可以在正确的时间尝试taking a heap dump（即之前或之后元空间的增加发生）。然后，进行另一个堆转储。使用MAT 或Yourkit 之类的工具来区分两个堆转储。两者之间的差异将告诉您正在加载哪些类。

元空间中的泄漏非常罕见，因为您只有这么多的类要加载，但它也可能是一些非常奇特的东西。

让我知道你发现了什么，祝你狩猎愉快！这些很有趣。 :-)

【讨论】：

我分析了两个堆转储（在重新部署 ~5 个工件之前和之后），甚至在计算差异之前就注意到了一些可疑的东西：1. 在 snag.gy/JGZdf.jpg 之前 2. 在 snag.gy/VqFiN.jpg 之后 这是不同之处： snag.gy/xfDeV.jpg 我看到 char[] 数组增长了很多。 （似乎是 String 的内容） 这里是 org.jboss...JavaZipFileSystem 类加载器的内容：snag.gy/bbYq7.jpg 所以我的印象是 WildFly 只是将所有工件加载到内存中，即使在重新部署后也不会释放它们。这可能是真的吗？可以吗？

酷！以下是一些建议： 1. 您希望在部署之间进行一些转储，以找到一种单调增加的内存使用模式，过滤掉随机对象。 2.尝试在您怀疑导致泄漏的对象中查找数据（即节点中的值）；这可以引导你的取证。 3. 确保调查您怀疑泄漏所在的元空间，而不是堆。 4. 是的，char[] 类型和其他原语波动很大。在更高的水平上更容易找到泄漏。 5. 是的，WildFly 很容易加载类而不释放它们。对于 JVM，类卸载是可选的。

您找到解决方案了吗？我有同样的问题

【参考方案2】：

WildFly 10.0.0.Final "java.lang.OutOfMemoryError: Metaspace" 发生并将被修复。参考 Wildfly 敏捷开发板

https://issues.jboss.org/browse/WFLY-6173

【讨论】：

欢迎来到 Stack Overflow！始终欢迎提供指向潜在解决方案的链接，但请add context around the link 以便您的其他用户知道它是什么以及为什么存在。始终引用重要链接中最相关的部分，以防目标站点无法访问或永久离线。考虑到仅仅是指向外部站点的链接是Why and how are some answers deleted? 的一个可能原因。

上下文在那里。这是应用程序中的一个错误，将被修复。鉴于此错误很常见，并且此页面是该问题的谷歌热门点击之一，删除此答案对社区造成的损害大于好处。