首页 > JVM双亲委派机制+对象分配过程
头像
菜到睡不着
编辑于 2020-12-08 11:14
+ 关注

JVM双亲委派机制+对象分配过程

最近看了一些关于JVM的视频之类的,对于一些知识有了更充分地认识,现在和大家分享下。
以下的顺序没有什么特别的含义,有些知识点也是跳跃性的,中间有很多东西没讲,只是挑一些印象深刻的分享了。
(如果下面有什么讲的不对的地方,大家可以批评指出,我还是个小菜鸡)

  1. 双亲委派机制

    首先先简单说明一下3个最常见的类加载器:

启动类加载器(引导类加载器,Bootstrap ClassLoader)
由C/C++实现;加载Java核心类库;不继承自java.lang.ClassLoader,没有父加载器;
扩展类加载器(Extension ClassLoader)
Java实现,派生于ClassLoader类,父类加载器为启动类加载器;
应用程序类加载器(系统类加载器,Application ClassLoader)
Java实现,派生于ClassLoader类,父类加载器为扩展类加载器,该类是程序中默认的类加载器,一般来说,Java应用的类都是由它来加载完成。

JVM加载类的Class文件时,采用的是双亲委派机制,即把请求交给父类处理,它是一种任务委派模式。
原理:
1)如果一个类加载器收到了类加载请求,它并不会自己先去加载,而是把这个请求委托给父类的加载器去执行;
2)如果父类加载器还存在其父类加载器,则进一步向上委托,依次递归,请求最终将到达顶层的启动类加载器;
3)如果父类加载器可以完成类加载任务,就成功返回,倘若父类加载器无法完成此加载任务,子加载器才会尝试自己去加载,这就是双亲委派模式。
双亲委派机制工作原理图
举个别人讲的例子(这是我听过最好的例子,再也忘不掉):
就像是你有一个苹果,你看你妈在,就先问你妈吃不吃,你妈看你姥姥在,就问你姥姥吃不吃,如果你姥姥吃了,你和你妈就没得吃了。你姥姥不想啃,不吃,就还给你妈,你妈要是吃了你就没得吃了,要是你妈也不吃,才轮到你吃。

优势:

  • 避免类的重复加载
  • 保护程序安全,防止核心API被随意篡改
    举个例子,比如你自己定义了一个String类,且包名设置为java.lang,那就和我们常用的字符串类java.lang.String一样了,但是此时你运行发现String类是不会加载你写的这一个,而是加载系统的String类,就是因为使用双亲委派机制,当系统类加载器收到加载String类的请求时,先传给扩展类加载器,然后扩展类加载器又传给引导类加载器,引导类加载器发现String类属于自己加载的范畴,就加载了系统的String类。

2.对象分配过程
图片说明
图片说明
默认情况下:
年轻代:老年代=1:2
Eden:S0:S1= 8:1:1

1)new的对象先放伊甸园区(Eden)。此区有大小限制;
2)当伊甸园的空间填满时,程序又需要创建对象,JVM的垃圾回收器将对伊甸园区进行垃圾回收(Minor GC),将伊甸园区中的不再被其他对象所引用的对象进行销毁。再加载新的对象放到伊甸园区;
3)然后将伊甸园中的剩余对象移动到幸存者0区(S0)。
4)如果再次触发垃圾回收,此时上次幸存下来的放到幸存者0区的,如果没有回收,就会放到幸存者1区(S1)。
5)如果再次经历垃圾回收,此时会重新放回幸存者0区,接着再去幸存者1区。
6)啥时候能去老年代呢?可以设置次数。默认是15次(从Eden移动到S0区或者S1区算移动一次,从S0区移动到S1区也算一次,从S1区移动到S0区也算一次,所以只要经过过移动都算做一次。当一个对算经历过15次的移动还没被销毁,就放到老年代)。
7)在老年代,很少进行垃圾回收。当老年代内存不足时,触发Major Gc,进行老年代的内存清理。
8)若老年代执行了Major Gc之后发现依然无法进行对象的保存,就会产生ooM异常。

垃圾回收频繁发生在年轻代,很少在老年代,几乎不在永久代(java7及以前)/元空间(java8及以后)收集。

对象分配到老年代不一定要经历15次的移动,有些特殊情况下可以更快或者跳过Eden区直接分配到老年代,上图:
图片说明

先粗略地分享这么多吧,要是工作空闲了,会继续来分享的,也当做自己看了资料过后的总结吧。

全部评论

(3) 回帖
加载中...
话题 回帖

推荐话题

相关热帖

近期精华帖

热门推荐