01-JVM 学习记录-类加载器
一、类加载器子系统
1. 作用-运输工具(快递员)
负责从文件系统或者网络中加载Class文件(DNA元数据模板),Class文件开头有特定标识,魔术,咖啡杯壁(class文件存于本地硬盘,JVM根据class实例化)DNA元数据模板
Classloader只负责class文件的加载,至于是否可运行,则由执行引擎决定
加载的类信息存放于称为方法区的内存空间,除了类信息,方法区还会存放运行时常量池信息,还可能包括字符串字面量和数字常量(常量池运行时加载到内存中,即运行时常量池)
2. 类的加载过程
加载——链接(验证、准备、解析)——初始化
解析阶段不一定,在某些情况下可以在初始化阶段之后再开始,为了支持Java语言的运行时绑定特性(也称为动态绑定或晚期绑定)。
2.1 加载
加载是类加载过程的一个阶段,注意区分
1. 通过一个类的全限定名获取定义此类的二进制字节流
加载class文件的方法:
本地系统直接加载
网络获取,Web Applet
zip压缩包获取,jar,war
运行时计算生成,动态代理
有其他文件生成,jsp
专有数据库提取.class文件,比较少见
加密文件中获取,防止Class文件被反编译的保护措施
2. 将这个字节流所代表的的静态存储结果转化为方法区的运行时数据结构
3. 在内存中生成一个代表这个类的java.lang.Class对象,作为方法区这个类的各种数据访问入口
2.2 链接
2.2.1 验证:确保Class文件的字节流中包含信息符合当前虚拟机要求,保证被加载类的正确性,不会危害虚拟机自身安全
四种验证:
- 文件格式验证
CA FE BA BE(魔数,Java虚拟机识别)
主次版本号
常量池的常量中是否有不被支持的常量类型
指向常量的各种索引值中是否有指向不存在的常量或不符合类型的常量
- 元数据验证
对字节码描述的信息进行语义分析,保证描述符合Java规范
类是否有父类,除了Object之外,所有的类都应该有父类
类的父类是否继承了不允许被继承的类(被final修饰的类)
如果这个类不是 抽象类,是否实现了其父类或接口中要求实现的所有方法。
类的字段,方法是否与父类的产生矛盾。例如方法参数都一样,返回值不同
- 字节码验证
通过数据流分析和控制流分析,确定程序语义是合法的,符合逻辑的。
对类的方法体,进行校验分析,保证在运行时不会做出危害虚拟机的行为
保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作,不会出现类似于在操作数栈放了一个int类型的数据,使用时却按照long类型加载到本地变量表中的情况。
保障任何跳转指令都不会跳转到方法体之外的字节码指令上。
- 符号引用验证
通过字符串描述的全限定名是否能找到对应的类
符号引用中的类、字段、方法的可访问性是否可被当前类访问
2.2.2 准备:为类变量分配内存,并且设置该类变量的初始值,即零值
不包含用final修饰的static(常量),在编译的时候就会分配了,准备阶段会显示初始化
不会为实例变量分配初始化(还没创建对象),类变量会分配在方法区中,实例变量会随着对象一起分配到Java堆中
2.2.3 解析
解析操作往往会伴随着JVM在执行完初始化之后再执行
将常量池内的符号引用转换为直接引用的过程。符号引用就是一组符号来描述引用的目标。符号引用的字面量形式明确定义在Java虚拟机规范的Class文件格式中。直接引用就是直接指向目标的指针,相对偏移量或一个间接定位到目标的句柄
解析动作主要针对类,或接口,字段,类方法,接口方法,方法类型等。对应常量池中的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info
符号引用是用符号(如类名,方法名,字段名等)来描述所引用的对象,而直接引用是用具体的内存地址或指针来指向所引用的对象。符号引用在编译阶段就存在,但是需要在运行时通过类加载器解析成直接引用。直接引用在运行时才存在,它可以直接定位到内存中的目标。直接引用的效率要比符号引用高。
2.3 初始化
初始化阶段是执行类构造器方法<clinit>()的过程,此方法不需要定义,是javac编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并而来。如果没有类变量和静态代码块,也不会有clinit。构造器方法中指令按照语句在源文中出现的顺序执行。
-
<clinit>()不同于类的构造器(关联:构造器是虚拟机视角下的<init>())
-
非法的前向引用:可以在static中对number先赋值,再声明,但不能先调用。
-
若该类具有父类,JVM会保证子类的<clinit>()执行前,父类的<clinit>()已经执行完毕
-
虚拟机必须保证一个类的<clinit>()方法在多线程下被同步加锁,只被执行一次
-
Java虚拟机规范严格规定了,有且只有六种情况,必须立即对类进行初始化,其他使用类的方式被看做是对类的被动使用,都不会导致类的初始化
1、遇到new,getstatic,putstatic或invokestatic这四条字节码指令时。
使用new关键字实例化对象
读取或设置一个类型的静态字段(final修饰已在编译期将结果放入常量池的静态字段除外)
调用一个类型的静态方法的时候
2、对类型进行反射调用,如果类型没有经过初始化,则需要触发初始化
3、初始化类的时候,发现父类没有初始化,则先触发父类初始化
4、虚拟机启动时,用户需要指定一个要执行的主类(包含main方法的那个类),虚拟机会初始化这个主类
5、只用JDK7中新加入的动态语言支持,如果一个java.lang.invoke.MethodHandler实例最后的解析结果为REF_getStatic,REF_putStatic,REF_invokeStatic,REF_newInvokeSpecial四种类型的方法句柄,并且这个方法对应的类没有进行初始化,则先触发其初始化
6、当一个接口中定了JDK8新加入的默认方法时,如果这个接口的实现类发生了初始化,要先将接口进行初始化
3. 类加载器分类
分为引导(启动)类加载器和自定义加载器(所有派生于抽象类ClassLoader的类加载器都划分为自定义加载器,扩展类加载器和系统类加载器属于自定义加载器)。
-
引导类加载器返回null,获取不到(因为是c/c++写的),系统的核心类库都是用引导类加载器。
-
自定义类加载器默认使用系统类加载器
3.1 引导类加载器
-
C/C++语言实现,嵌套JVM内部,用来加载Java核心类库,rt.jar、resources.jar、sun.boot.class.path路径下的内容。
-
并不继承java.lang.ClassLoader,没有父加载器,是扩展类和应用程序类加载器的父加载器。
-
出于安全考虑,Bootstrap启动类加载器只加载包名为java\javax\sun等开头的类
3.2 扩展类加载器
-
Java语言编写,由sun.misc.Launcher$ExtClassLoader实现
-
派生于ClassLoader类
-
父类加载器为启动类加载器
-
从java.ext.dirs系统属性所指定的目录中加载类库,或从jre/lib/ext子目录下加载类库。如果用户创建的jar放在此目录下,自动由扩展类加载器加载。
3.3 系统类加载器(应用程序类加载器)
-
Java语言编写,由sun.misc.Launcher$AppClassLoader实现
-
派生于ClassLoader类
-
父类加载器为扩展类加载器
-
负责加载环境变量classpath或系统属性java.class.path指定路径下的类库
-
该类加载器是程序中默认的类加载器,一般来说,Java应用的类都是由它来完成加载
-
通过ClassLoader#getSystemClassLoader()方法可以后去到类加载器
3.4 用户自定义类加载器
3.4.1 为什么要用自定义类加载器?
隔离加载类:例如使中间件的Jar包与应用程序Jar包不冲突
修改类加载的方式:启动类加载器必须使用,其他可以根据需要自定义加载
扩展加载源
防止源码泄露:对字节码进行加密,自定义类加载器实现解密
3.4.2 实现步骤
继承抽象类java.lang.ClassLoader类的方式,实现自己的类加载器
jdk1.2之前,继承并重写loadClass方法;jdk1.2之后,建议把自定义的类加载逻辑写在findClass()方法中
如果没有太过复杂的需求,可以直接继承URLClassLoader类,可以避免自己编写findClass()方法,及其获取字节码流的方式,使自定义类加载器编写更加简洁
3.5 ClassLoader
抽象类,除了启动类加载器,其他类加载器都继承于此。
findClass方法中调用defineClass方法,搭配使用。
获取ClassLoader的途径:
4. 双亲委派机制
1. 一种任务委派模式:
JVM对Class文件采用的是按需加载(需要使用该类时才将它的class文件加载到内存生成class对象),而且加载class文件时,Java虚拟机使用的是双亲委派模式,即把请求交由父类处理。
如果一个类加载器收到了类加载请求,它并不会自己先去加载。而是把这个请求委托给父类的加载器去执行
如果父类加载器还存在其父类加载器,则进一步向上委托,依次递归,请求最终将达到顶层的启动类加载器
如果父类的加载器可以完成类加载任务,就成功返回,倘若父类加载器无法完成此加载任务,子加载器才会尝试自己去加载,这就是双亲委派模式
例:如果我自定义了一个包java.lang,写了一个String类,默认是系统类加载器,我在其他类的静态代码块使用String,加载时不会加载我写的String类,依然是引导类加载器,因为引导类加载器是系统类加载器的父加载器(扩展类加载器)的父加载器,且可以完成这个加载任务。
2. 优势
-
避免类的重复加载
-
保护程序安全,防止核心API被篡改
3. 沙箱安全机制
-
保证对Java核心源代码的保护
例:360沙箱,将一些东西(U盘、病毒)限制在沙箱区域里运行,不会影响电脑的其他程序。
5. 类的主动使用和被动使用
在JVM中表示两个class对象,是否为同一个类存在两个必要条件:
类的完整类名必须一致,包括包名
加载这个类的ClassLoader必须相同
即使两个类对象来源于同一个class文件,被同一个JVM加载,只要加载它们的ClassLoader实例对象不同,这两个类对象也不相等。
JVM必须知道一个类型是由启动类加载器加载的,还是由用户类加载器加载的。如果是用户类加载器加载的,JVM会将这个类加载器的一个引用作为类型信息的一部分,保存到方法区中。
参考:b站尚硅谷-宋少康
下一篇: JVM 内存溢出故障排除 - 场景
推荐阅读
-
[PyTorch 与深度学习] 4、PyTorch 的数据集和数据加载器详细使用教程
-
[姿势估计] 实践记录:使用 Dlib 和 mediapipe 进行人脸姿势估计 - 本文重点介绍方法 2):方法 1:基于深度学习的方法:。 基于深度学习的方法:基于深度学习的方法利用深度学习模型,如卷积神经网络(CNN)或递归神经网络(RNN),直接从人脸图像中学习姿势估计。这些方法能够学习更复杂的特征表征,并在大规模数据集上取得优异的性能。方法二:基于二维校准信息估计三维姿态信息(计算机视觉 PnP 问题)。 特征点定位:人脸姿态估计的第一步是通过特征点定位来检测和定位人脸的关键点,如眼睛、鼻子和嘴巴。这些关键点提供了人脸的局部结构信息,可用于后续的姿势估计。 旋转表示:常见的旋转表示方法包括欧拉角和旋转矩阵。欧拉角通过三个旋转角度(通常是俯仰、偏航和滚动)描述头部的旋转姿态。旋转矩阵是一个 3x3 矩阵,表示头部从一个坐标系到另一个坐标系的变换。 三维模型重建:根据特征点的定位结果,三维人脸模型可用于姿势估计。通过将人脸的二维图像映射到三维模型上,可以估算出人脸的旋转和平移信息。这就需要建立人脸的三维模型,然后通过优化方法将模型与特征点对齐,从而获得姿势估计结果。 特征点定位 特征点定位是用于检测人脸关键部位的五官基础部分,还有其他更多的特征点表示方法,大家可以参考我上一篇文章中介绍的特征点检测方案实践:人脸校正二次定位操作来解决人脸校正的问题,客户在检测关键点的代码上略有修改,坐标转换部分客户见上图 def get_face_info(image). img_copy = image.copy image.flags.writeable = False image = cv2.cvtColor(image, cv2.COLOR_BGR2RGB) results = face_detection.process(image) # 在图像上绘制人脸检测注释。 image.flags.writeable = True image = cv2.cvtColor(image, cv2.COLOR_RGB2BGR) box_info, facial = None, None if results.detections: for detection in results. for detection in results.detections: mp_drawing.Drawing.detection = 无 mp_drawing.draw_detection(image, detection) 面部 = detection.location_data.relative_keypoints 返回面部 在上述代码中,返回的数据是五官(6 个关键点的坐标),这是用 mediapipe 库实现的,下面我们可以尝试用另一个库:dlib 来实现。 使用 dlib 使用 Dlib 库在 Python 中实现人脸关键点检测的步骤如下: 确保已安装 Dlib 库,可使用以下命令: pip install dlib 导入必要的库: 加载 Dlib 的人脸检测器和关键点检测器模型: 读取图像并将其灰度化: 使用人脸检测器检测图像中的人脸: 对检测到的人脸进行遍历,并使用关键点检测器检测人脸关键点: 显示绘制了关键点的图像: 以下代码将参数 landmarks_part 添加到要返回的关键点坐标中。
-
01-JVM 学习记录-类加载器
-
团结类银河恶魔城学习记录 11-14 P116 雷霆一击物品特效源代码
-
Unity 类银河恶魔城学习记录 11-8 p110 敌人修改器源代码
-
RFID 寄存器初始化 | 学习笔记 - A 类卡的基本流程
-
Android 开发中 nodpi、xhdpi、hdpi、mdpi、ldpi 的概念 - 术语和概念 屏幕尺寸 屏幕的物理尺寸,基于屏幕的对角线长度(如 2.8 英寸、3.5 英寸)。 简而言之,安卓系统将所有屏幕尺寸简化为三大类:大、普通和小。 程序可以为这三种屏幕尺寸提供三种不同的布局选项,然后系统会以合适的方式将布局选项呈现到相应的屏幕上,这个过程不需要程序员用代码进行干预。 屏幕纵横比 屏幕的物理长度与物理宽度之比。程序只需使用系统提供的资源分类器 long(长)和 notlong(不长),就能为具有特定长宽比的屏幕提供配制材料。 分辨率 屏幕的像素总数。请注意,分辨率并不意味着长宽比,尽管在大多数情况下,分辨率表示为 "宽度 x 长度"。在安卓系统中,程序一般不直接处理分辨率。 密度 根据屏幕分辨率,沿屏幕宽度和长度排列的像素数量。 密度较低的屏幕在长度和宽度方向上的像素都相对较少,而密度较高的屏幕通常会在同一区域内排列很多甚至非常非常多的像素。屏幕的密度非常重要;例如,一个界面元素(如按钮)的长度和宽度以像素为单位,在低密度屏幕上会显得很大,但在高密度屏幕上就会显得很小。 独立于密度的像素(DIP)是指程序用来定义界面元素的抽象意义上的像素。它作为一个与实际密度无关的单位,帮助程序员构建布局方案(界面元素的宽度、高度和位置)。 与密度无关的像素在逻辑上与像素密度为 160 DPI 的屏幕上的像素大小相同,而 160 DPI 是安卓平台默认的显示设备。在运行时,平台会以目标屏幕的密度为基准,"透明 "地处理所有所需的 DIP 缩放操作。要将与密度无关的像素转换为屏幕像素,可以使用一个简单的公式:像素 = DIP * (密度 / 160)。例如,在 240 DPI 的屏幕上,1 个 DIP 等于 1.5 个物理像素。强烈建议使用 DIP 来定义程序界面的布局,因为这样可以确保用户界面在所有分辨率的屏幕上都能正常显示。 为了简化程序员在面对各种分辨率时的麻烦,也为了让各种分辨率的平台都能直接运行这些程序,Android 平台将所有屏幕以密度和分辨率作为分类方式,分别分为三类:- 三大尺寸:大、普通、小;- 三种不同密度:高(hdpi)、中(mdpi)和低(ldpi)。DPI 表示 "每英寸点数",即每英寸的像素数。如果需要,程序可以为不同的屏幕尺寸提供不同的资源(主要是布局),为不同的屏幕密度提供不同的资源(主要是位图)。除此之外,程序无需对屏幕尺寸或密度进行任何额外处理。执行时,平台会根据屏幕本身的尺寸和密度特性自动加载相应的资源,并将其从逻辑像素(DIP,用于定义界面布局)转换为屏幕上的物理像素。
-
jvm 的 java 类加载机制和类加载器(ClassLoader)的详细信息
-
Java 类加载]自定义类加载器
-
JVM 注意事项 (I) Java 类加载过程?类加载器?