1.内存结构概述
● Class文件 ● 类加载子系统 ● 运行时数据区 ?? ○ 方法区 ?? ○ 堆 ?? ○ 程序计数器 ?? ○ 虚拟机栈 ?? ○ 本地方法栈 ● 执行引擎 ● 本地方法接口 ● 本地方法库
详细图
2.类加载器与类的加载过程
2.1 类加载器子系统作用
● 类加载器子系统负责从文件系统或者网络中加载Class文件,class文件在文件开头有特定的文件标识。 ● ClassLoader只负责class文件的加载,至于它是否可以运行,则由Execution Engine(执行引擎)决定。 ● 加载的类信息存放于一块称为方法区的内存空间。除了类的信息外,方法区中还会存放运行时常量池信息,可能还包括字符串字面量和数字常量(这部分常量信息是Class文件中常量池部分的内存映射)
2.2 类加载器ClasLoader角色
● class file存在于本地硬盘上,可以理解为设计师画在纸上的模板,而最终这个模板在执行的时候是要加载到JVM当中来根据这个文件实例化出n个一模一样的实例。 ● class file加载到JVM中,被称为DNA元数据模板,放在方法区。 ● 在.class文件->JVM->最终成为元数据模板,此过程就要一个运输工具(类装载器Class Loader),扮演一个快递员的角色。
2.3 类加载过程
public class HelloLoader {
public static void main(String[] args) {
System.out.println("Hello World!");
}
}
用流程图表示上述示例代码:
执行 main( ) 方法(静态方法)就需要先加载承载类 HelloLoader 加载成功,则进行链接、初始化等操作,完成后调用 HelloLoader 类中的静态方法 main 加载失败则抛出异常
完整的流程图如下所示: 加载 --> 链接(验证 --> 准备 --> 解析) --> 初始化
2.3.1 加载(Loading)阶段
加载
1.通过一个类的全限定名(就是类名全称,带包路径的用点隔开,例如: java.lang.String。)获取定义此类的二进制字节流 2.将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构 3.在内存中生成一个代表这个类的java.lang.Class对象,作为方法区这个类的各种数据的访问入口
补充:加载class文件的方式 ● 从本地系统中直接加载 ● 通过网络获取,典型场景:Web Applet ● 从zip压缩包中读取,成为日后jar、war格式的基础 ● 运行时计算生成,使用最多的是:动态代理技术 ● 由其他文件生成,典型场景:JSP应用 ● 从专有数据库中提取.class文件,比较少见 ● 从加密文件中获取,典型的防Class文件被反编译的保护措施
2.3.2 链接(Linking)阶段
链接分为三个子阶段:
验证 --> 准备 --> 解析
验证(Verify):
1.目的在于确保Class文件的字节流中包含信息符合当前虚拟机要求,保证被加载类的正确性,不会危害虚拟机自身安全。 2.主要包括四种验证,文件格式验证,元数据验证,字节码验证,符号引用验证。 3.格式检查:是否以魔术CAFEBABE开头,主版本和副版本是否在当前Java虚拟机的支持范围内,数据中每一项是否都拥有正确的长度等
准备(Prepare): ?? ○ 为类变量(静态变量)分配内存并且设置该类变量的默认初始值,即零值。 ?? ○ 这里不包含用final修饰的static,因为final在编译的时候就会分配了,准备阶段会显式初始化; ?? ○ 这里不会为实例变量分配初始化,类变量会分配在方法区中,而实例变量是会随着对象一起分配到Java堆中。
举例
变量a在准备阶段会赋初始值,但不是1,而是0,在初始化阶段会被赋值为 1
public class HelloApp {
private static int a = 1;
public static void main(String[] args) {
System.out.println(a);
}
}
解析(Resolve):
○ 将常量池内的符号引用转换为直接引用的过程(简言之,将类、接口、字段和方法的符号引用转为直接引用)。 ○ 事实上,解析操作往往会伴随着JVM在执行完初始化之后再执行。 ○ 符号引用就是一组符号来描述所引用的目标。符号引用的字面量形式明确定义在《java虚拟机规范》的Class文件格式中。直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。 ○ 解析动作主要针对类或接口、字段、类方法、接口方法、方法类型等。对应常量池中的CONSTANT_Class_info,CONSTANT_Fieldref_info、CONSTANT_Methodref_info等。
解释什么是符号引号和直接引用? 教室里有个空的位子没坐人,座位上边牌子写着小明的座位(符号引用),后来小明进来坐下去掉牌子(符号引用换成直接引用)
2.3.3 初始化(Initialization)阶段
为类变量赋予正确的初始化值
● 初始化阶段就是执行类构造器方法<clinit>()的过程。 ● 此方法不需定义,是javac编译器自动收集类中的所有类变量(静态变量)的赋值动作和静态代码块中的语句合并而来。 ● 构造器方法中指令按语句在源文件中出现的顺序执行。 ● <clinit>()不同于类的构造器。(关联:构造器是虚拟机视角下的<init>()) ● 若该类具有父类,JVM会保证子类的<clinit>()执行前,父类的<clinit>()已经执行完毕。 ● 虚拟机必须保证一个类的<clinit>()方法在多线程下被同步加锁。
IDEA安装 JClassLib 插件
当我们代码中包含static变量或静态代码块的时候,就会有clinit方法
public class ClassInitTest {
private static int num = 1;
static {
num = 2;
}
public static void main(String[] args) {
System.out.println(ClassInitTest.num);
}
}
<clinit>()方法中的指令按语句在源文件中出现的顺序执行
public class ClassInitTest {
private static int num = 1;
static {
num = 2;
number = 20;
System.out.println(num);
}
private static int number = 10;
public static void main(String[] args) {
System.out.println(ClassInitTest.num);
System.out.println(ClassInitTest.number);
}
}
静态变量 number 的值变化过程如下 准备阶段时:默认初始化 0 执行静态代码块:20 执行静态变量初始化:10
构造器是虚拟机视角下的<init>()
package com.jvm.lecture;
public class ClinitTest {
private int a = 10;
private static int c = 3;
public ClinitTest() {
a = 20;
int d = 10;
}
public static void main(String[] args) {
int b = 2;
}
}
在构造器中: 先将类变量 a 赋值为 10 再将局部变量赋值为 20
当一个类初始化时,要求其父类全部都已经初始化完毕
public class ClinitTest2 {
public static void main(String[] args) {
System.out.println(MyChlid.str);
System.out.println(MyChlid.str2);
}
}
class MyParent {
public static String str = "hello word";
static {
System.out.println("MyParent static block");
}
}
class MyChlid extends MyParent{
public static String str2 = "welcome";
static {
System.out.println("MyChlid static block");
}
}
虚拟机必须保证一个类的<clinit>()方法在多线程下被同步加锁
public class DeadThreadTest {
public static void main(String[] args) {
Runnable r = () -> {
System.out.println(Thread.currentThread().getName() + "开始");
DeadThread dead = new DeadThread();
System.out.println(Thread.currentThread().getName() + "结束");
};
Thread t1 = new Thread(r, "线程1");
Thread t2 = new Thread(r, "线程2");
t1.start();
t2.start();
}
}
class DeadThread {
static {
if (true) {
System.out.println(Thread.currentThread().getName() + "初始化当前类");
while (true) {
}
}
}
}
程序卡死,分析原因: 两个线程同时去加载 DeadThread 类,而 DeadThread 类中静态代码块中有一处死循环 先加载 DeadThread 类的线程抢到了同步锁,然后在类的静态代码块中执行死循环,而另一个线程在等待同步锁的释放。
Java编译器并不会为所有的类都产生<clinit>()初始化方法 1.一个类中并没有声明任何的类变量,也没有静态代码块时 2.一个类中声明类变量,但是没有明确使用类变量的初始化语句以及静态代码块来执行初始化操作时 3.一个类中包含static final修饰的基本数据类型的字段,这些类字段初始化语句采用编译时常量表达式
public class InitializationTest1 {
public int num = 1;
public static int num1;
public static final int num2 = 1;
}
static与final的搭配问题 (使用static + final修饰,且显示赋值中不涉及到方法或构造器调用的基本数据类型或String类型的显式赋值,是在链接阶段的准备环节进行)
public class InitializationTest2 {
public static int a = 1;
public static final int INT_CONSTANT = 10;
public static final Integer INTEGER_CONSTANT1 = Integer.valueOf(100);
public static Integer INTEGER_CONSTANT2 = Integer.valueOf(1000);
public static final String s0 = "helloworld0";
public static final String s1 = new String("helloworld1");
public static String s2 = "helloworld2";
public static final int NUM1 = new Random().nextInt(10);
}
3.类加载器分类
JVM支持两种类型的类加载器 。分别为引导类加载器(Bootstrap ClassLoader)和自定义类加载器(User-Defined ClassLoader)。
从概念上来讲,自定义类加载器一般指的是程序中由开发人员自定义的一类类加载器,但是Java虚拟机规范却没有这么定义,而是将所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器。
无论类加载器的类型如何划分,在程序中我们最常见的类加载器始终只有3个,如下所示:
为什么 ExtClassLoader 和 AppClassLoader 都属于自定义加载器
规范定义:所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器
ExtClassLoader 继承树
AppClassLoader 继承树
public class ClassLoaderTest {
public static void main(String[] args) {
ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader();
System.out.println(systemClassLoader);
ClassLoader extClassLoader = systemClassLoader.getParent();
System.out.println(extClassLoader);
ClassLoader bootstrapClassLoader = extClassLoader.getParent();
System.out.println(bootstrapClassLoader);
ClassLoader classLoader = ClassLoaderTest.class.getClassLoader();
System.out.println(classLoader);
ClassLoader classLoader1 = String.class.getClassLoader();
System.out.println(classLoader1);
}
}
我们尝试获取引导类加载器,获取到的值为 null ,这并不代表引导类加载器不存在,因为引导类加载器是由 C/C++ 语言构成的,所以我们是获取不到。
两次获取系统类加载器的值都相同:sun.misc.Launcher$AppClassLoader@18b4aac2 ,这说明系统类加载器是全局唯一的。
3.1 虚拟机自带的加载器
3.1.1 启动类加载器(引导类加载器,Bootstrap ClassLoader )
● 这个类加载使用C/C++语言实现的,嵌套在JVM内部。 ● 它用来加载Java的核心库(JAVA_HOME/jre/lib/rt.jar、resources.jar或sun.boot.class.path路径下的内容),用于提供JVM自身需要的类 ● 并不继承自ava.lang.ClassLoader,没有父加载器。 ● 加载扩展类和应用程序类加载器,并指定为他们的父类加载器。 ● 出于安全考虑,Bootstrap启动类加载器只加载包名为java、javax、sun等开头的类
3.1.2 扩展类加载器(Extension ClassLoader)
● Java语言编写,由sun.misc.Launcher$ExtClassLoader实现。 ● 派生于ClassLoader类 ● 父类加载器为启动类加载器 ● 从java.ext.dirs系统属性所指定的目录中加载类库,或从JDK的安装目录的jre/1ib/ext子目录(扩展目录)下加载类库。如果用户创建的JAR放在此目录下,也会自动由扩展类加载器加载。
3.1.3 应用程序类加载器(系统类加载器,AppClassLoader)
● java语言编写,由sun.misc.LaunchersAppClassLoader实现 ● 派生于ClassLoader类 ● 父类加载器为扩展类加载器 ● 它负责加载环境变量classpath或系统属性java.class.path指定路径下的类库 ● 该类加载是程序中默认的类加载器,一般来说,Java应用的类都是由它来完成加载 ● 通过ClassLoader.getSystemclassLoader() 方法可以获取到该类加载器
public class ClassLoaderTest1 {
public static void main(String[] args) {
System.out.println("**********启动类加载器**************");
URL[] urLs = sun.misc.Launcher.getBootstrapClassPath().getURLs();
for (URL element : urLs) {
System.out.println(element.toExternalForm());
}
ClassLoader classLoader = Provider.class.getClassLoader();
System.out.println(classLoader);
System.out.println("***********扩展类加载器*************");
String extDirs = System.getProperty("java.ext.dirs");
for (String path : extDirs.split(";")) {
System.out.println(path);
}
ClassLoader classLoader1 = CurveDB.class.getClassLoader();
System.out.println(classLoader1);
}
}
/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/bin/java -javaagent:/Applications/IntelliJ IDEA.app/Contents/lib/idea_rt.jar=49287:/Applications/IntelliJ IDEA.app/Contents/bin -Dfile.encoding=UTF-8 -classpath /Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre/lib/charsets.jar:/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre/lib/ext/cldrdata.jar:/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre/lib/ext/dnsns.jar:/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre/lib/ext/jaccess.jar:/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre/lib/ext/legacy8ujsse.jar:/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre/lib/ext/localedata.jar:/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre/lib/ext/nashorn.jar:/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre/lib/ext/openjsse.jar:/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre/lib/ext/sunec.jar:/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre/lib/ext/sunjce_provider.jar:/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre/lib/ext/sunpkcs11.jar:/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre/lib/ext/zipfs.jar:/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre/lib/jce.jar:/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre/lib/jfr.jar:/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre/lib/jsse.jar:/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre/lib/management-agent.jar:/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre/lib/resources.jar:/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre/lib/rt.jar:/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/lib/dt.jar:/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/lib/jconsole.jar:/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/lib/tools.jar:/Users/zhangshouan/WorkSpace/spring-kernel/out/production/jvm com.jvm.lecture.ClassLoaderTest1
**********启动类加载器**************
file:/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre/lib/resources.jar
file:/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre/lib/rt.jar
file:/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre/lib/sunrsasign.jar
file:/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre/lib/jsse.jar
file:/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre/lib/jce.jar
file:/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre/lib/charsets.jar
file:/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre/lib/jfr.jar
file:/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre/classes
null
***********扩展类加载器*************
/Users/zhangshouan/Library/Java/Extensions:/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre/lib/ext:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java
sun.misc.Launcher$ExtClassLoader@1540e19d
Process finished with exit code 0
加载器执行流程
3.2 用户自定义类加载器
在Java的日常应用程序开发中,类的加载几乎是由上述3种类加载器相互配合执行的,在必要时,我们还可以自定义类加载器,来定制类的加载方式。
为什么要自定义类加载器? ● 隔离加载类 ● 修改类加载的方式 ● 扩展加载源 ● 防止源码泄漏
用户自定义类加载器实现步骤:
- 开发人员可以通过继承抽象类ava.lang.ClassLoader类的方式,实现自己的类加载器,以满足一些特殊的需求
- 在JDK1.2之前,在自定义类加载器时,总会去继承ClassLoader类并重写loadClass() 方法,从而实现自定义的类加载类,但是在JDK1.2之后已不再建议用户去覆盖loadclass() 方法,而是建议把自定义的类加载逻辑写在findClass()方法中
- 在编写自定义类加载器时,如果没有太过于复杂的需求,可以直接继承URLClassLoader类,这样就可以避免自己去编写findClass() 方法及其获取字节码流的方式,使自定义类加载器编写更加简洁。
3.3 ClassLoader的使用说明
ClassLoader类是一个抽象类,其后所有的类加载器都继承自ClassLoader(不包括启动类加载器)
sun.misc.Launcher 它是一个java虚拟机的入口应用
3.3.1获取 ClassLoader 的途径
public class ClassLoaderTest2 {
public static void main(String[] args) {
try {
ClassLoader classLoader = Class.forName("java.lang.String").getClassLoader();
System.out.println(classLoader);
ClassLoader classLoader1 = Thread.currentThread().getContextClassLoader();
System.out.println(classLoader1);
ClassLoader classLoader2 = ClassLoader.getSystemClassLoader().getParent();
System.out.println(classLoader2);
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
}
}
4.双亲委派机制
4.1 双亲委派机制原理
Java虚拟机对class文件采用的是按需加载的方式,也就是说当需要使用该类时才会将它的class文件加载到内存生成class对象。而且加载某个类的class文件时,Java虚拟机采用的是双亲委派模式,即把请求交由父类处理,它是一种任务委派模式。
工作原理
● 1)如果一个类加载器收到了类加载请求,它并不会自己先去加载,而是把这个请求委托给父类的加载器去执行; ● 2)如果父类加载器还存在其父类加载器,则进一步向上委托,依次递归,请求最终将到达顶层的启动类加载器; ● 3)如果父类加载器可以完成类加载任务,就成功返回,倘若父类加载器无法完成此加载任务,子加载器才会尝试自己去加载,这就是双亲委派模式。
4.2 双亲委派机制代码示例
举例一 我们自己定义一个java.lang包,在其下面定义一个String类,里面声明了静态代码块
public class String {
static {
System.out.println("我是自定义的String类的静态代码块");
}
}
public class StringTest {
public static void main(String[] args) {
java.lang.String str = new java.lang.String();
System.out.println("你好,世界");
}
}
运行结果
你好,世界
Process finished with exit code 0
结果:程序并没有输出我们静态代码块中的内容,可见仍然加载的是 JDK 自带的 String 类
举例二
在我们自己定义的 String 类中加个 main( ) 方法
public class String {
static {
System.out.println("我是自定义的String类的静态代码块");
}
public static void main(String[] args) {
System.out.println("hello word");
}
}
原因:由于双亲委派机制,我们的String类是由引导类加载器加载的,而引导类加载器并没有main方法,所以会报错。
举例三
当我们加载jdbc.jar 用于实现数据库连接的时候,首先我们需要知道的是 jdbc.jar是基于SPI接口进行实现的,所以在加载的时候,会进行双亲委派,最终从根加载器中加载 SPI核心类,然后在加载SPI接口类,接着在进行反向委派,通过线程上下文类加载器进行实现类jdbc.jar的加载。
举例四
package java.lang;
public class TestStart {
public static void main(String[] args) {
System.out.println("hell word");
}
}
出于保护机制,java.lang 包下不允许我们自定义类
4.3 双亲委派机制的优势
● 避免类的重复加载 ● 保护程序安全,防止核心API被随意篡改 ? ?○ 自定义类:java.lang.String没有调用。 ? ?○ 自定义类:java.lang.TestStart(报错:阻止创建 java.lang开头的类)
5.沙箱安全机制
自定义String类,但是在加载自定义String类的时候会率先使用引导类加载器加载,而引导类加载器在加载的过程中会先加载jdk自带的文件(rt.jar包中java\lang\String.class),报错信息说没有main方法,就是因为加载的是rt.jar包中的string类。这样可以保证对java核心源代码的保护,这就是沙箱安全机制。
6.类的主动使用与被动使用
如何判断两个class对象是否相同
在JVM中表示两个class对象是否为同一个类存在两个必要条件: ● 类的完整类名必须一致,包括包名。 ● 加载这个类的ClassLoader(指ClassLoader实例对象)必须相同。
换句话说,在JVM中,即使这两个类对象(class对象)来源同一个Class文件,被同一个虚拟机所加载,但只要加载它们的 ClassLoader 实例对象不同,那么这两个类对象也是不相等的。
对类加载器的引用
JVM必须知道一个类型是由启动加载器加载的还是由用户类加载器加载的。 如果一个类型是由用户类加载器加载的,那么JVM会将这个类加载器的一个引用作为类型信息的一部分保存在方法区中。 当解析一个类型到另一个类型的引用的时候,JVM需要保证这两个类型的类加载器是相同的。
类的主动使用和被动使用
Java程序对类的使用方式分为:主动使用和被动使用。
主动使用,又分为七种情况:
● 创建类的实例 ● 访问某个类或接口的静态变量,或者对该静态变量赋值 ● 调用类的静态方法 ● 反射(比如:Class.forName(“com.jvm.Test”)) ● 初始化一个类的子类 ● Java虚拟机启动时被标明为启动类的类 ● JDK 7 开始提供的动态语言支持: java.lang.invoke.MethodHandle实例的解析结果 REF_getStatic、REF_putStatic、REF_invokeStatic句柄对应的类没有初始化,则初始化
除了以上七种情况,其他使用Java类的方式都被看作是对类的被动使用,都不会导致类的初始化,即不会执行初始化阶段(不会调用 clinit( ) 方法和 init( ) 方法)。
|