面试官Java8-JVM内存结构变了永久代到元空间

4次阅读

共计 2653 个字符,预计需要花费 7 分钟才能阅读完成。

在文章《JVM 之内存结构详解》中我们描述了 Java7 以前的 JVM 内存结构,但在 Java8 和以后版本中 JVM 的内存结构慢慢发生了变化。作为面试官如果你还不知道,那么面试过程中是不是有些露怯?作为面试者,如果知晓这些变化,又将成为面试中的亮点。

如果在网络上搜索 JVM 内存结构,90% 的可能会搜到 Java7 及以前的内存图,本篇文章将会对 JVM 内存结构再次细化,深入理解 Java8 之后的内部变化。现在意识到关注公众号“程序新视界”的好处了吧。在这里可以不断的刷新你的知识和认知。

JVM 内存结构的细化

再来看一下《JVM 之内存结构详解》中的内存结构图。

为了更细化的讲解,我们将该图进行进一步的优化调整。针对 java7 及以前版本的细化。

看出变化了吗?堆和方法区连在了一起,但这并不能说堆和方法区是一起的,它们在逻辑上依旧是分开的。但在物理上来说,它们又是连续的一块内存。也就是说,方法区和前面讲到的 Eden 和老年代是连续的。

在继续进行下去之前,我们先来理解两个概念:规范和实现。

规范和实现

针对 Java 虚拟机的实现有专门的《Java 虚拟机规范》,在遵守规范的前提下,不同的厂商会对虚拟机进行不同的实现。就好比开发的过程中定义了接口,具体的接口实现大家可以根据不同的业务需求进行实现。

PS:大家都有必要了解一下《Java 虚拟机规范》,关注公众号“程序新视界”,回复“002”获得 Java SE 7 的虚拟机规范 PDF 版。

我们通常使用的 Java SE 都是由 Sun JDK 和 OpenJDK 所提供,这也是应用最广泛的版本。而该版本使用的 VM 就是 HotSpot VM。通常情况下,我们所讲的 java 虚拟机指的就是 HotSpot 的版本。

永久代(PermGen)

上面理解了规范和实现之后,来看认识一个概念“永久代(Permanet Generation,也称 PermGen)”。对于习惯了在 HotSpot 虚拟机上开发、部署的程序员来说,很多都愿意将方法区称作永久代。

本质上来讲两者并不等价,仅因为 Hotspot 将 GC 分代扩展至方法区,或者说使用永久代来实现方法区。在其他虚拟机上是没有永久代的概念的。也就是说方法区是规范,永久代是 Hotspot 针对该规范进行的实现。

理解上面的概念之后,我们对 Java7 及以前版本的堆和方法区的构造再进行一下变动。

再重复一遍就是对 Java7 及以前版本的 Hotspot 中方法区位于永久代中。同时,永久代和堆是相互隔离的,但它们使用的物理内存是连续的。

永久代的垃圾收集是和老年代捆绑在一起的,因此无论谁满了,都会触发永久代和老年代的垃圾收集。

但在 Java7 中永久代中存储的部分数据已经开始转移到 Java Heap 或 Native Memory 中了。比如,符号引用 (Symbols) 转移到了 Native Memory;字符串常量池 (interned strings) 转移到了 Java Heap;类的静态变量 (class statics) 转移到了 Java Heap。

然后,在 Java8 中,时代变了,Hotspot 取消了永久代。永久代真的成了永久的记忆。永久代的参数 -XX:PermSize 和 -XX:MaxPermSize 也随之失效。

元空间(Metaspace)

对于 Java8,HotSpots 取消了永久代,那么是不是就没有方法区了呢?当然不是,方法区只是一个规范,只不过它的实现变了。

在 Java8 中,元空间 (Metaspace) 登上舞台,方法区存在于元空间(Metaspace)。同时,元空间不再与堆连续,而且是存在于本地内存(Native memory)。

本地内存(Native memory),也称为 C -Heap,是供 JVM 自身进程使用的。当 Java Heap 空间不足时会触发 GC,但 Native memory 空间不够却不会触发 GC。

针对 Java8 的调整,我们再次对内存结构图进行调整。

元空间存在于本地内存,意味着只要本地内存足够,它不会出现像永久代中“java.lang.OutOfMemoryError: PermGen space”这种错误。看上图中的方法区,是不是“膨胀”了。

默认情况下元空间是可以无限使用本地内存的,但为了不让它如此膨胀,JVM 同样提供了参数来限制它使用的使用。

  • -XX:MetaspaceSize,class metadata 的初始空间配额,以 bytes 为单位,达到该值就会触发垃圾收集进行类型卸载,同时 GC 会对该值进行调整:如果释放了大量的空间,就适当的降低该值;如果释放了很少的空间,那么在不超过 MaxMetaspaceSize(如果设置了的话),适当的提高该值。
  • -XX:MaxMetaspaceSize,可以为 class metadata 分配的最大空间。默认是没有限制的。
  • -XX:MinMetaspaceFreeRatio, 在 GC 之后,最小的 Metaspace 剩余空间容量的百分比,减少为 class metadata 分配空间导致的垃圾收集。
  • -XX:MaxMetaspaceFreeRatio, 在 GC 之后,最大的 Metaspace 剩余空间容量的百分比,减少为 class metadata 释放空间导致的垃圾收集。

永久代为什么被替换了

思考一下,为什么使用元空间替换永久代?

表面上看是为了避免 OOM 异常。因为通常使用 PermSize 和 MaxPermSize 设置永久代的大小就决定了永久代的上限,但是不是总能知道应该设置为多大合适, 如果使用默认值很容易遇到 OOM 错误。

当使用元空间时,可以加载多少类的元数据就不再由 MaxPermSize 控制, 而由系统的实际可用空间来控制。

更深层的原因还是要合并 HotSpot 和 JRockit 的代码,JRockit 从来没有所谓的永久代,也不需要开发运维人员设置永久代的大小,但是运行良好。同时也不用担心运行性能问题了, 在覆盖到的测试中, 程序启动和运行速度降低不超过 1%,但是这点性能损失换来了更大的安全保障。

小结

经过上面的讲解和演变,是不是对 JVM 的内存结构有了更深的理解了?可以和面试官多聊一会儿了,毕竟面试官的时间也不多了。另外,走过路过不要错过,该系列持续更新中。最后别忘了关注公众号“程序新视界”获得第一手资料。

原文链接:《面试官,Java8 JVM 内存结构变了,永久代到元空间》

《面试官》系列文章:

  • 《JVM 之内存结构详解》
  • 《面试官,不要再问我“Java GC 垃圾回收机制”了》
  • 《面试官,Java8 JVM 内存结构变了,永久代到元空间》

<center>程序新视界:精彩和成长都不容错过 </center>

正文完
 0