JAVA8 JVM memory structure has changed, the generation of permanent metaSpace

In the article " Memory of the structure explain JVM " we describe Java7 previous JVM memory structures, but the JVM in Java8 and later in memory structures slowly changed. As the interviewer if you do not know, the interview process is not some ignorance once again? As the interviewer, if aware of these changes, in turn become the highlight of the interview.

If the search JVM memory configuration on the network, 90% could be found to Java7 and previous memory map, this article will be on the JVM memory structure refinement again, in-depth understanding of internal changes after Java8. Watch now realize the benefits of "New Horizons program," the public number of the bar. Here you can constantly refresh your knowledge and awareness.

[Transfer] https://www.choupangxia.com/2019/10/22/interview-jvm-gc-02/

JVM memory structure refinement

Then look at " the JVM's memory structure Detailed " memory structure diagram.

jvm memory structure

For more detailed explanations, we refer to this chart to further optimize the adjustment. For java7 and previous versions of refinement.

jvm memory structure

See some change? Heap and method area are linked together, but that does not say that heap and method area are together, they are still separated logically. But physically speaking, they are also contiguous block of memory. In other words, the method and the area in front of Eden and we talked about old's continuous.

jvm memory structure

Before proceeding continues, we first understand two concepts: specification and implementation.

Specification and implementation

There are special "Java Virtual Machine Specification" for the implementation of the Java virtual machine Subject to the norms, different vendors have different virtual machine implementations. Like the definition of the interface than the development process, the specific interface it can be implemented according to different business needs.

PS: I have a need to look at "Java Virtual Machine Specification," No public concern "program New Horizons", reply "002" for Java SE Virtual Machine Specification PDF version 7.

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

永久代(PermGen)

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

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

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

jvm memory structure

再重复一遍就是对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)。

jvm memory structure

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

jvm memory structure

针对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错误。

When using the element space, metadata can be loaded much like MaxPermSize no longer controlled by, and controlled by the system of actual space available.

Deeper reason or to merge JRockit and HotSpot code, JRockit never called permanent-generation, operation and maintenance personnel do not need to develop a set of permanent generation size, but runs well. At the same time, do not worry operational performance issues, and in the cover of the test, the program up and running speed by less than 1%, but this performance loss in exchange for greater security.

Guess you like

Origin www.cnblogs.com/hanhaotian/p/11724172.html