1年前 (2020-09-17)  爪哇岛 |   抢沙发  279 
文章评分 0 次,平均分 0.0

众所周知java8的新特性之一是完全删除了永久生成(PermGen)空间,自jdk7发布以来,Oracle就已经宣布了这一点。例如,自jdk7以来,内部字符串已经从PermGen空间中删除。jdk8版本完成了它的退役。本文将与大家分享到目前为止我们在PermGen继任者:Metaspace上发现的信息。我们还将比较hotspots1.7和hotspots1.8(b75)在执行Java程序“泄漏”类元数据对象时的运行时行为。一旦java8正式发布,围绕Metaspace的最终规范、调优标志和文档应该可以使用。

元空间metaspace

一个新的记忆空间诞生了

jdk8热点JVM现在使用本机内存来表示类元数据,称为Metaspace;类似于oraclejrockit和ibmjvmjava.lang.OutOfMemoryError:PermGen空间问题,无需再调整和监视此内存空间…不要太快。虽然这个更改在默认情况下是不可见的,但是接下来我们将向您展示您仍然需要担心类元数据内存占用。请记住,这个新特性并不能神奇地消除类和类加载器内存泄漏。您将需要使用不同的方法并通过学习新的命名约定来跟踪这些问题。

总而言之:

PermGen空间情况

此内存空间已完全删除。

PermSize和MaxPermSize JVM参数将被忽略,如果在启动时出现,则会发出警告。

元空间内存分配模型

类元数据的大多数分配现在都是从本机内存中分配的。

用于描述类元数据的klasse已被删除。

元空间容量

默认情况下,类元数据分配受可用本机内存量的限制(容量当然取决于是否使用32位JVM而不是64位以及操作系统虚拟内存可用性)。

有一个新的标志可用(MaxMetaspaceSize),允许您限制用于类元数据的本机内存量。如果不指定此标志,元空间将根据运行时的应用程序需求动态调整大小。

元空间垃圾回收

一旦类元数据使用量达到“MaxMetaspaceSize”,就会触发对死类和类加载器的垃圾回收。

显然需要对元空间进行适当的监视和调优,以限制此类垃圾收集的频率或延迟。过多的元空间垃圾收集可能是类、类加载器内存泄漏或应用程序大小不足的症状。

Java堆空间影响

一些杂项数据已移动到Java堆空间。这意味着您可能会在未来的jdk8升级后观察到Java堆空间的增加。

元空间监测

Metaspace用法可从HotSpot 1.8详细GC日志输出中获得。

根据我们对b75的测试,Jstat和JVisualVM还没有更新,旧的PermGen空间引用仍然存在。

理论足够了,让我们看看这个新的内存空间是如何通过我们泄漏的Java程序运行的…

更多细节可以参考这一篇介绍:https://javakk.com/417.html

PermGen与Metaspace运行时比较

为了更好地理解新元空间内存空间的运行时行为,我们创建了一个类元数据泄漏Java程序。你可以在这里下载源代码。

将测试以下场景:

  • 使用jdk1.7运行Java程序,以监视并耗尽设置为128mb的PermGen内存空间。
  • 使用jdk1.8(b75)运行Java程序,以监视新Metaspace内存空间的动态增加和垃圾收集。
  • 使用jdk1.8(b75)运行Java程序,通过将MaxMetaspaceSize值设置为128mb来模拟元空间的消耗

JDK 1.7@64位-永久代消耗

  • 具有50K配置迭代的Java程序
  • 1024 MB的Java堆空间
  • Java PermGen空间为128 MB(-XX:MaxPermSize=128m)

Java8:从永久代PermGen到元空间Metaspace

正如您在JVisualVM中看到的,PermGen耗尽是在加载了大约30K+个类之后达到的。我们也可以从程序和GC输出中看到这种消耗。

Class metadata leak simulator
 
Author: Pierre-Hugues Charbonneau
 
http://javaeesupportpatterns.blogspot.com
 
ERROR: java.lang.OutOfMemoryError: PermGen space

Java8:从永久代PermGen到元空间Metaspace

现在让我们使用hotspotsjdk1.8jre执行该程序。

JDK 1.8@64位–元空间动态调整大小

  1. 具有50K配置迭代的Java程序
  2. 1024 MB的Java堆空间
  3. Java元空间:无边界(默认)

Java8:从永久代PermGen到元空间Metaspace

从详细的GC输出中可以看到,JVM元空间确实从20mb动态扩展到328mb的保留本机内存,以满足Java程序增加的类元数据内存占用。我们还可以观察到JVM试图销毁任何死类或类加载器对象时的垃圾收集事件。由于我们的Java程序正在泄漏,JVM别无选择,只能动态扩展元空间内存空间。该程序能够在没有OOM事件的情况下运行其50K次迭代,并加载了50K+个类。让我们转到最后一个测试场景。

JDK 1.8@64位-元空间耗尽

  • 具有50K配置迭代的Java程序
  • 1024 MB的Java堆空间
  • Java元空间:128 MB(-XX:MaxMetaspaceSize=128m)

Java8:从永久代PermGen到元空间Metaspace

正如您在JVisualVM中看到的,元空间耗尽是在加载了大约30K+个类之后达到的;这与jdk1.7的运行非常相似。我们也可以从程序和GC输出中看到这一点。另一个有趣的观察是,保留的本机内存占用是指定的最大大小的两倍。这可能表明有机会微调Metaspace resize策略(如果可能),以避免本机内存浪费。

现在在下面找到我们从Java程序输出中得到的异常。

Class metadata leak simulator
 
Author: Pierre-Hugues Charbonneau
 
http://javaeesupportpatterns.blogspot.com
 
ERROR: java.lang.OutOfMemoryError: Metadata space

正如预期的那样,将元空间限制在128MB,就像我们在JDK1.7的基线运行中所做的那样,不允许我们完成程序的50K迭代。JVM抛出了一个新的OOM错误。上面的OOM事件是JVM在内存分配失败后从元空间抛出的

Java8:从永久代PermGen到元空间Metaspace

当前的观察结果明确表明,为了避免诸如上一个测试场景触发的过多的元空间GC或OOM条件等问题,需要进行适当的监控和调优。以后的文章可能会包括性能比较,以确定与此新特性相关的潜在性能改进。

 

除特别注明外,本站所有文章均为老K的Java博客原创,转载请注明出处来自https://javakk.com/421.html

关于

发表评论

表情 格式

暂无评论

登录

忘记密码 ?

切换登录

注册