Compare JDK1.7 and JDK1.8 memory model of

As the online article states was mixed, I do not know what is right, do a lot of access to information as well as I scanned the article they think is a summary, if you please point out the error, thank you

JDK1.7 memory model

For these five areas I probably do a general introduction, the details may consult other information or articles

Program Counter : thread private, can be seen as the commander of the current line number of program execution.

Java Virtual Machine stack : thread private, life cycle and the same thread, Java memory model is a virtual machine implemented method described stack, each method when executed will form a stack frame for storing a local variable table, the operand stack, dynamic link, for export and other information, a method to perform after completion of the call is to a stack frame from the stack into the stack to the process, the next chart is a structural model of a virtual machine stack, and a detailed explanation source: HTTPS: // the WWW .cnblogs.com / aflyun / p / 10575740.html

 Native method stacks : thread private, acting on the Java Virtual Machine stack similar, but the Java Virtual Machine to execute Java stack method, while the native method stacks running local Native method.

Heap : The biggest area of memory management in the Java virtual machine, Java heap is shared by the threads, used to store an object instance. That birth and subject to collection in this area are carried out. Substituting into the primary reactor (Young Gen) and the old year (Tenured Gen), the default ratio is 1: 2, and is divided into primary substituting From and To Eden and three regions, the default ratio is 8: 1: 1 , as FIG.

Methods District : threads share, class information is used to store the virtual machine has been loaded, constants, static variables, the time compiler to compile the code and other data, here to say what methods and permanent generations in the end zone What is the relationship, the permanent generation of HotSpot virtual machine for the implementation of the district, implementation area is not virtual machine specification constraints, HotSpot VM team here just is accomplished.

运行时常量池:在JDK1.7中,是运行时常量池是方法区的一部分,用于存放编译期生成的各种字符变量和符号引用。其实除了运行时常量池,还有字符串常量池,class常量池,具体的介绍和区别请看这篇文章:Java中的常量池(字符串常量池、class常量池和运行时常量池)

以上就是JDK1.7的虚拟机内存模型。

JDK1.8内存模型

JDK1.8与1.7最大的区别是1.8将永久代取消,取而代之的是元空间,既然方法区是由永久代实现的,取消了永久代,那么方法区由谁来实现呢,在1.8中方法区是由元空间来实现,所以原来属于方法区的运行时常量池就属于元空间了。元空间属于本地内存,所以元空间的大小仅受本地内存限制,但是可以通过-XX:MaxMetaspaceSize进行增长上限的最大值设置,默认值为4G,元空间的初始空间大小可以通过-XX:MetaspaceSize进行设置,默认值为20.8M,还有一些其他参数可以进行设置,元空间大小会自动进行调整,详细请看这篇文章:jdk8 Metaspace 调优

这里要说明一下,要区分字符串常量池和运行时常量池,这里引用这篇文章JDK1.8关于运行时常量池, 字符串常量池的要点所提到的:

  •  在JDK1.7之前运行时常量池逻辑包含字符串常量池存放在方法区, 此时hotspot虚拟机对方法区的实现为永久代
  • 在JDK1.7 字符串常量池被从方法区拿到了堆中, 这里没有提到运行时常量池,也就是说字符串常量池被单独拿到堆,运行时常量池剩下的东西还在方法区, 也就是hotspot中的永久代
  • 在JDK1.8 hotspot移除了永久代用元空间(Metaspace)取而代之, 这时候字符串常量池还在堆, 运行时常量池还在方法区, 只不过方法区的实现从永久代变成了元空间(Metaspace) 

 

 

 

参考文献:

https://blog.csdn.net/bruce128/article/details/79357870

https://www.cnblogs.com/aflyun/p/10575740.html

https://blog.csdn.net/q5706503/article/details/84640762

https://blog.csdn.net/zm13007310400/article/details/77534349

《深入理解Java虚拟机

Guess you like

Origin blog.csdn.net/Hollake/article/details/92762180