解决OutOfMemoryError:metaspace元空间溢出问题总结

这个java.lang.OutOfMemoryError：Metaspace表示为Java类元数据分配的本机内存量已被耗尽。让我们来看看如何解决这个问题。

一般来说，可以在命令行上设置MaxMetaSpaceSize：

java -XX:MaxMetaspaceSize=3200m

你可以试着增加它的价值，看看它是否能解决问题。还要记住，减小Java堆的大小将为MetaSpace提供更多的可用空间。Java堆和元空间之间存在一种折衷，因此您必须找到一种平衡。

如果问题仍然存在，那么有必要通过检查JVM中加载的类的数量来分析到底发生了什么。为此，可以使用类似VisualVM的外观。

请注意，JVisualVM从oraclejdk9开始就已经停止了。您需要从这里下载：http://visualvm.github.io/download.html

将visualvm（jvisualvm）连接到JVM之后，单击monitor，然后查看加载的类的数量。在那里您可以监视堆和元空间。如果您可以看到类的数量在请求之间增加，那么您很可能正在动态创建新类。

可以通过堆转储执行进一步的检查：

然后，如果您查看了OQL控制台，就可以执行OQL查询来对您的类执行即席分析。例如，通过执行以下查询，可以从每个类加载器加载一个类列表：

select map(sort(map(heap.objects('java.lang.ClassLoader'), '{loader: it, count: it.classes.elementCount }'), 'lhs.count < rhs.count'), 'toHtml(it) + "
"')

这是一个宝贵的提示，可以用来确定类加载器是否正在加载越来越多的类。

关于metaspace内存溢出排查细节也可以参考之前的文章：https://javakk.com/160.html

我假设您可以在一段时间内使用相同的请求（一组请求）创建问题。定义了MaxMetaspaceSize是一件好事，否则应用程序将使用本机内存直到它耗尽增长。但我将从以下步骤开始：

检查当您多次向服务器发送同一请求时，JVM中加载的类的数量是否继续增长。如果是，您可能正在创建动态类，这会导致加载到元空间中的类增长。那么如何检查加载的类的数量，可以使用visualvm连接到使用JMX的服务器或在本地运行来模拟。我将提到本地的步骤，但是对于远程连接JMX，您应该将以下内容添加到应用程序的JVM参数中，并在端口9999上启动它并使用-XX:+UnlockDiagnosticVMOptions进行远程连接。

-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9999 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -XX:+UnlockDiagnosticVMOptions

将visualvm（jvisualvm）连接到JVM之后，单击monitor，然后查看加载的类的数量。在那里您可以监视堆和元空间。但是我将添加其他工具来密切监视元空间。

另外，一旦连接到jvm，您可能需要获取堆快照并找出使用OQL加载的类。因此，在进行堆转储之前，请停止对服务器的请求，这样就不会捕获任何正在执行的请求/正在执行的代码及其相关对象，但这不是必需的。因此，在visualvm中的“monitor”空间中多次运行同一组请求后，单击右上角的“Heap Dump”。然后打开/加载快照，您将看到OQL控制台的选项。在permgen analysis下的右下面板上会看到一些预定义的OQL查询。运行名为“classloaded class histogram”的查询，我想这将给出每个类加载器加载的类的计数。您可以使用它来找出哪个类加载器正在加载类。

但是上面名为“classloader loaded class”的查询将很慢，这将实际显示每个类加载器加载的类。

select { loader: cl,
             classes: filter(map(cl.classes.elementData, 'it'), 'it != null') }
    from instanceof java.lang.ClassLoader cl

然后试着追踪元空间区域的生长情况。现在我们将使用jconsole和java的一些新功能：jmc（java任务控制）。您可以使用jconsole连接到jvm（本地或远程），一旦连接到jvm，进入memory选项卡，您就可以监视那里的非堆增长，那里应该有元空间、代码缓存和压缩的类空间。现在连接

jmc

要连接到虚拟机，然后在连接之后，单击JMC中位于右上方的“诊断命令”。由于我们启用了UnlockDiagnosticVMOptions，GC.class_stats统计可能会被处决。您可能希望运行它时显示所有列并以csv格式打印。所以命令看起来像：

GC.class_stats -all=true -csv=true

然后，您可以比较不同时期的类统计信息，找出哪些类导致了麻烦（元空间增长），或者哪些类在元空间中有相关的信息（方法/方法数据）。如何分析收集到的csv输出：好吧，我会把csv加载到数据库或其他地方的两个类似的表（代表csv）中进行比较GC.class_stats统计csv输出，我可以运行一些SQL或任何其他分析工具。这将使我们更好地了解元空间中到底在增长什么。GC类统计信息包含以下列：

Index，Super，InstSize，InstCount，InstBytes，Mirror，KlassBytes，K_secondary_superss，VTab，ITab，OopMap，IK_methods，IK_default_methods，IK_default_vtable_索引，IK_local_接口，IK_可传递的_接口，IK_字段，IK_内部_类，IK_signers，class_注解，class_type_注释，字段，方法\注释、方法\参数\注释、方法\类型\注释、方法\默认注释、注释、Cp、CpTags、CpCache、CpOperands、CpRefMap、CpAll、MethodCount、MethodBytes、ConstMethod、MethodData、StackMap、字节码、MethodAll、ROAll、RWAll、Total、ClassName、ClassLoader

希望有帮助。另外，如果1.7中没有导致任何漏洞，那么这个bug可能在Java8中。

此外，如果有人持有对类加载器的任何引用，则不会从元空间卸载类。如果您知道您的类加载器应该是GCed，并且没有人应该持有对您的类加载器的引用，那么您可以返回到visualvm中的heap dump，单击class loader instance并右键单击找到“nearest GC root”，它将告诉您谁持有对类加载器的引用。