问题标签 [metaspace]

我在我的项目中遇到了 metaSpace 的问题。

我正在使用 Scala IDE，其中 Spark 2.3.1、Play framework 2.6、Scala 2.11

运行sbt run时，出现元空间错误。

另外，我曾尝试运行sbt clean.

但它给出了同样的错误：

我正在阅读有关 GC 的内容，并了解到当一个对象有资格进行垃圾收集时，GC 必须在其finalize上运行该方法。该finalize方法保证只运行一次，因此 GC 将对象标记为已完成并让它休息直到下一个循环。

在 finalize 方法中，您可以从技术上“复活”一个对象，例如，通过将其分配给静态字段。该对象将再次变得活跃并且不符合垃圾回收条件，因此 GC 不会在下一个周期收集它。

但是，该对象将被标记为已完成，因此当它再次符合条件时，将不会调用 finalize 方法。本质上，您只能在对象的生命周期内将这个“复活”技巧转动一次。

我觉得这很有趣。但是，如果我的变量是非静态的，如何将其更改为finalize方法内的静态？

记住：

如果无法从任何活动线程或任何静态引用访问对象，则该对象符合垃圾收集或 GC 的条件。因此，hack 是将对象添加到finalize方法内的静态资源中，这样只会阻止一次垃圾收集。该finalize方法受到保护，因此可以被子类覆盖，无论它们是否在同一个包中。

这是一种危险的做法，无需使用内部应用程序代码。

根据我的理解，Native Heap 是给一个java进程分配最大Heap size后剩下的内存。
对于 32 位 Java 进程 - 可以分配给该进程的最大虚拟内存为 4GB。在这总的 4GB 中，假设我们为 max Heap 设置了 2GB，并且 OS 使用了 1GB。那么，剩下的 1GB 内存可以称为 Native Heap 吗？

同样，对于 64 位 java 进程，可以分配给进程的最大内存可以大于 4GB。比方说，我的系统中有 16GB RAM，那么可以分配给我系统中每个进程的最大虚拟内存将是 16GB，因为虚拟地址空间范围不允许超过 16GB 的内存。对吗？

那么，64 位 Java 进程的本机堆将 (16-2(-Xmx) -1(OS)) 即 15GB？

我对 Native Heap 计算的理解是否正确？

如果我的理解是正确的，那么为什么我们说从 Native 内存分配的Metaspace的最大可用内存是总可用系统内存。每个进程获得的最大虚拟内存将是系统中可能的最大虚拟可寻址范围，其中一些内存将被堆和操作系统占用。

如果我们将分配给进程的总内存设置为堆内存，那么它会不会抛出outOfMemoryError:Metaspace，因为该进程没有可用的 Native Heap ？

请帮助我纠正我的理解。谢谢。

目前我正在使用 Gradle 5.2.1 配置 Spring boot 2.1 项目。但是我在构建项目时出现内存不足错误，无法理解确切原因。

请查找附件日志

由于 groovy 的东西，我们最近一直在为我们的应用程序遭受元空间 OOM，但是，我设法缓存已编译的脚本以阻止它现在发生。

以前，该进程每天至少崩溃一次。自从我应用修复程序以来，它至少运行了 4 天。为了再次确认修复确实有效，我使用jcmd Metaspace.dump转储了元空间

但是，我在阅读元空间转储时遇到问题，我相信关键信息在下面粘贴的头部。我不知道类空间和非类空间之间的区别以及我的进程已经提交了多少元空间。所以这里需要帮助，在此先感谢！

如果有必要，我可以附上完整的转储文件。但在我看来，它们只是内存块分配地址。

我在 java 8 下运行我的 java 应用程序，我注意到我的 gc 日志文件中有一个奇怪的行为：

首先，由于元数据 GC 阈值，我看到很多 Full GC 触发了一个小的延迟，但是日志没有解释为什么会触发这个 full GC，因为元数据大小仍然很小。另外，在我附加的最后一次完整 GC 中，我看到Metaspace: 799223K->799223K(1769472K)，但是1769472K是从哪里来的？它大于设置的 MaxMetaspaceSize 吗？

我正在使用带有 jdk 8 的 tomcat 8。元空间设置为 1GB，我觉得这已经足够了，我得到了 OutOfMemoryError 异常。我已尝试检查类（SSLEngineImpl.java:1796）以了解导致此问题的原因，但似乎错误行并未引用任何类负载。有人可以帮忙吗？

德拉所有，

我正在使用 openjdk 1.8.0_212-b04、Tomcat 8.0.21 和 Red Hat 6.4。

并且我已经调整了测试web应用程序，确保重新部署后不会出现这样的消息：

这是我在测试中使用的GC参数：

我使用了一个 shell 脚本，不断接触 web.xml 以重新部署 Web 应用程序。测试期间没有其他流量/操作。

这是测试期间VisualVM的元空间图：

如图所示：在第1点，元空间有时会缩小，所以我认为应该没有元空间内存泄漏。

但是在第 2 点，Tomcat 抛出了元空间 OOM：

在第 3 点，我点击了 VisualVM 中的 GC 按钮，元空间实际上是可收缩的。

我尝试添加参数：-XX:MaxMetaspaceFreeRatio=60，但仍然得到了 smae 结果。

这是 GCeasy 的元空间图：

这是 GC 日志： GC 日志

感谢您提供任何解决/故障排除/调试 OOM 错误的建议。

更新 1：感谢@samabcde 的建议，我添加了 se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor 以进行更多测试。它有助于删除一些 ThreadLocal 变量并使 Web 应用程序保持更多时间。

但仍然得到了元空间OOM。

对于 Java 8 之后的 JVM

1. 当元空间的大小 >-XX:metaspaceSize时，会触发一次 gc。
2. 无论你如何配置-XX:metaspaceSize和-XX:maxMetaspaceSize，元空间的初始大小在 64 位服务器上通常是一个固定值（20.8M）。
3. 当接近当前容量时，JVM 会自动调整元空间的大小。
4. 那么，如果-XX:metaspaceSize是20G，当前元空间大小为18M，需要分配大量新对象（约100M），JVM必须为这些新对象resize metaspace，JVM会在resize之前触发full GC吗?

我目前正在调查压缩类空间问题。我知道问题出在哪里，但在调查时，我注意到jstat -gc ...并jcmd ... GC.heap_info给出了不同数量的元空间和压缩类空间容量和使用情况：

堆容量的数字似乎大致匹配（幸存者、伊甸园和老一代的所有容量都同意）。堆使用数字不完全匹配，但我不希望它们匹配；jstat在这里大约一秒钟后被收集jcm。但是元空间数字全部关闭，jstat数字通常略低于jcmd数字。我重新运行了这两个命令以确认调用之间没有发生类加载，实际上，这两个命令都为元空间编号提供了与以前相同的输出。

这里发生了什么？他们测量这些数字的方式是否略有不同？哪个更准确？

运行时信息：