JVM内存模型

1.JVM组成部分
  • 类加载器子系统
  • 运行时数据区(内存结构,JVM内存模型)
  • 执行引擎
2.图示
image.png
3.线程隔离数据区域
image.png
image.png

堆:new出来的对象及数组等存放的区域
方法区:存放类的信息,常量及静态变量
java栈 :每个线程在执行的时候都会创建一个栈,每执行到一个方法创建相应的栈帧,栈帧包括:局部变量表,操作数栈,动态链接,方法出口。
其生命周期与线程一致,不存在垃圾回收。
本地方法栈:执行native方法时,加载到本地方法栈中
程序计数器:保存了下一个执行的指令的地址

4. 堆
image.png

1.GC主要收集区域:堆。-Xmx -Xms指定
2.jdk1.8后取消永久代,改为MetaData(元数据区域),之前永久代在JVM堆中,元数据区存放在单独物理内存中。
3.新生代包含Eden区跟survivor区,默认占比8 :1,新生代跟老年代默认占比是1:2。
4.minor GC :发生在年轻代的GC。Major GC:发生在老年代的GC。FullGC:清理整个堆空间(视具体垃圾收集器不同而不同,可能只发生在老年代)
5.JVM调优的目的:
减少FullGC次数,降低单次FullGc时间
6.垃圾收集过程:
对象创建后装载到Eden区,当Eden满了之后就会触发Minor GC,将没有GC root引用的对象清理掉,将存活的对象放到From区,随着Eden区不断发生MinorGC,不断往MinorGC存放,From区域满了之后发生MinorGC,将存活的对象放到To区,此时From与To区角色发生转换,Eden区域的对象经过GC后放入From区(之前的To区),From与To区交替15次(JVM默认值,发生在Survivor区15次GC)之后存活下来的对象,放到Tenured区(老年代),当老年代经过MajorGC后,还是满了的话。就会触发FullGC。
STW(stop the world):发生Full GC时,运行GC线程时,会推掉所有的工作线程,将工作线程挂起,此时会导致应用程序发生停顿。

5.永久代 元数据空间

元数据区:元数据区取代了永久代(jdk1.8以前),本质和永久代类似,都是对JVM规范中方法区的实现,区别在于元数据区并不在虚拟机中,而是使用本地物理内存,永久代在虚拟机中,永久代逻辑结构上属于堆,但是物理上不属于堆,堆大小=新生代+老年代。元数据区也有可能发生OutOfMemory异常。


Jdk1.6及之前: 有永久代, 常量池在方法区
Jdk1.7: 有永久代,但已经逐步“去永久代”,常量池在堆
Jdk1.8及之后: 无永久代,常量池在元空间


元数据区的动态扩展,默认–XX:MetaspaceSize值为21MB的高水位线。一旦触及则Full GC将被触发并卸载没有用的类(类对应的类加载器不再存活),然后高水位线将会重置。新的高水位线的值取决于GC后释放的元空间。如果释放的空间少,这个高水位线则上升。如果释放空间过多,则高水位线下降。
为什么jdk1.8用元数据区取代了永久代?
官方解释:移除永久代是为融合HotSpot JVM与 JRockit VM而做出的努力,因为JRockit没有永久代,不需要配置永久代

6.执行引擎
执行引擎

JIT(及时编译 just in time)

JIT编译器:字节码文件会经过一系列的过程全部解释成目标代码(计算机可识别的01010文件),放到虚拟机中执行。缺点是:第一次执行较慢,因为要全部解释成目标代码再执行。优点是:之后的执行会变快,因为目标代码会存储在内存中,下一次需要执行时,之间执行目标代码即可。
字节码解释器:会将字节码文件一行行边解释边执行。
实际上JVM采用第三种方式 即 mixed mode,第一次执行时,采用字节解释器,每次执行时计数器加一,发现该字节码文件多次执行时,则采用JIT编译器,一次解释成目标代码,再执行。

image.png

你可能感兴趣的:(JVM内存模型)