JVM学习
我们用java命令运行某个类的main函数启动程序时,需要先通过类加载器把主类加载到jvm。
通过java命令执行代码的大体流程如下:
比如有一个类为Pig,则先运行Pig.class字节码文件,在Windows系统里面会通过java.exe调用底层 的jvm.dll文件创建java虚拟机(底层为c++实现),然后创建一个引导类加载器实例(C++实现的类加载器),C++调用java代码创建jvm的启动器实例sun.misc.Launcher(sum.misc.Launcher.getLauncher()),该类由引导类加载器负责加载创建其他类加载器,然后获取运行类的加载器ClassLoader,是AppClassLoader的实例(launcher.getClassLoader()),然后调用loadClass加载要运行的类Math(classLoader.loadClass(“Pig”)), 加载完成时候jvm会执行Pig类的main方法入口(Pig.main())java程序运行结束后jvm销毁。下列是流程图:
loadClass的类加载过程如下几步:
加载>>验证>>准备>>解析>>初始化>>使用>>卸载
- 加载:在硬盘上查找并通过IO读入字节码文件,使用到类时才会加载,例如调用类的main()方法,new对象等等,在加载阶段会在内存中生成一个代表这个类的java.lang.Class对象,作为方法区这个类的各种数据的访问入口
- 验证:校验字节码文件的正确性比如可能.class文件中被别人乱修改
- 准备:给类的静态变量分配内存,并赋予默认值
- 解析:将符号引用替换为直接引用,该阶段会把一些静态方法(符号引用,比如main()方法)替换为指向数据所存内存的指针或句柄等(直接引用),这是所谓的静态链接过程(类加载期间完成),动态链接是在程序运行期间完成的将符号引用替换为直接引用。
- 初始化:对类的静态变量初始化为指定的值,执行静态代码块
类被加载到方法区中后主要包含 运行时常量池、类型信息、字段信息、方法信息、类加载引用、对应class实例的引入等信息
类加载器的引用:这个类到类加载器实例的引用
对应class实例的引用:类加载器在加载类信息放到方法区中后,会创建一个对应的class类型的对象实例放到堆(Heap)中,作为开发人员访问方法的入口和切入点
**注意:**主类在运行过程中如果使用到其他类,会逐步加载这些类。jar包或者war包里的类不是一次性全部加载的,是使用到时才加载
类加载器和双亲委派机制
类加载的过程主要是通过类加载器来实现的,java里有如下几种类加载器
- 引导类加载器:负责加载支撑jvm运行的位于JRE的lib目录下的核心类库,比如:rt.jar、charsets.jar等
- 扩展类加载器:负责加载支撑jvm运行的位于JRE的lib目录下的ext扩展目录中的jar类包
- 应用程序类加载器:负责加载ClassPath路径下的类包,主要就是加载你自己写的那些类
- 自定义加载器:负责加载用户自定义路径下的类包
类加载器初始化过程:
类运行加载全过程中回去创建jvm启动器实例sum.misc.Launcher。sum.misc.Launcher初始化使用了单例模式设计,保证一个jvm虚拟机内只有一个sum.misc.Launcher实例。
在Launcher构造方法内部,创建了两个类加载器,分别是sum.misc.Launcher.ExtClassLoader(扩展类加载器)和sum.misc.Launcher.AppClassLoader(应用类加载器)。jvm默认使用Launcher的getClassLoader()方法返回的类加载器AppClassLoader的实例加载我们的应用程序。
//单例设计模式
public static Launcher getLauncher() {
return launcher;
}
// Launcher的构造函数
public Launcher() {
Launcher.ExtClassLoader var1;
try {
// 构造扩展类加载器,在构造的过程中将其父加载器设置为null
var1 = Launcher.ExtClassLoader.getExtClassLoader();
} catch (IOException var10) {
throw new InternalError("Could not create extension class loader", var10);
}
try {
//构造应用类加载器,在构造的过程中将其父加载器设置为ExtClassLoader
//Launcher的loader属性值是AppCLassLoader,我们一般都是用这个类加载器来加载自己写的应用程序
this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);
} catch (IOException var9) {
throw new InternalError("Could not create application class loader", var9);
}
Thread.currentThread().setContextClassLoader(this.loader);
String var2 = System.getProperty("java.security.manager");
if (var2 != null) {
SecurityManager var3 = null;
if (!"".equals(var2) && !"default".equals(var2)) {
try {
var3 = (SecurityManager)this.loader.loadClass(var2).newInstance();
} catch (IllegalAccessException var5) {
} catch (InstantiationException var6) {
} catch (ClassNotFoundException var7) {
} catch (ClassCastException var8) {
}
} else {
var3 = new SecurityManager();
}
if (var3 == null) {
throw new InternalError("Could not create SecurityManager: " + var2);
}
System.setSecurityManager(var3);
}
}
双亲委派机制
jvm类加载器是有亲子层级结构的
这里类加载中有一个双亲委派机制,加载某个类时会先委托父加载器寻找目标类,找不到再委托上层父加载器加载,如果所有父加载器在自己的加载类路径下都找不到目标,则在自己的类加载路径中查找并载入目标类。
比如我们的Pig类,最先会找到应用程序类加载器加载,应用程序类加载器会先委托扩展类加载器,扩展类加载器在委托引导类加载器,顶层引导类加载器在自己的类加载路径中没有找到Pig类,则向下退回加载Pig类的请求,扩展类加载器收到回复就自己加载,在自己的类加载路径里也没有找到Pig类,又向下退回Pig类的加载请求给应用程序类加载器,应用程序类加载器在自己的类加载路径中找到了Pig类,最后就自己加载。
双亲委派机制就是:先找父亲加载,不行再由儿子自己加载
应用程序类加载器源码学习
AppClassLoader的loaderClass方法最终会调用其父亲ClassLoader的loadClass方法,改方法大体逻辑如下:
- 首先,检查一下指定名称的类是否已经加载过了,如果已经加载过则不需要再次加载,直接返回。
- 如果这个类没有加载过,则再判断一下是否有父加载器,如果有父加载器则由父加载器加载(即调用parent.loadClass(name,false);)或者是调用bootstrap类加载器来加载。
- 如果父加载器及bootstrap类加载器都没有找到指定的类,那么调用当前类加载器的findClass方法来完成加载
// ClassLoader的loadClass方法,实现了双亲委派机制
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
// First, check if the class has already been loaded
// 检查当前类加载器是否已经加载了该类
Class<?> c = findLoadedClass(name);
if (c == null) {
long t0 = System.nanoTime();
try {
if (parent != null) {
//如果当前加载器父加载器不为空则委托父加载器加载该类
c = parent.loadClass(name, false);
} else {
//如果当前加载器父加载器为空则委托引导类加载器加载该类
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// ClassNotFoundException thrown if class not found
// from the non-null parent class loader
}
if (c == null) {
// If still not found, then invoke findClass in order
// to find the class.
long t1 = System.nanoTime();
//都会调用URLClassLoader的findClass方法在加载器的类路径中查找并加载该类
c = findClass(name);
// this is the defining class loader; record the stats
sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
sun.misc.PerfCounter.getFindClasses().increment();
}
}
if (resolve) {
//不会执行
resolveClass(c);
}
return c;
}
}
为什么要设计双亲委派机制
- 沙箱安全机制:自己写的java.lang.String.class类不会被加载,这样可以防止核心API库被随意篡改
- 避免类的重复加载:如果父亲已经加载了此类,就没有必要子ClassLoader再加载一次,保证被加载类的唯一性
全盘负责委托机制
“全盘负责”是指一个ClassLoader装载一个类时,除非显示的使用是另外一个ClassLoader,该类所依赖及引用的类也是由这个ClassLoader载入。
自定义类加载器示例:
自定义类加载器只需要继承java.lang.ClassLoader类,该类有两个核心的方法,一个是loadClass(String,boolean),实现了双亲委派机制,还有一个方法是findClass,默认实现是空方法,所以我们自定义类加载器主要是重写findClass方法
Tomcat打破双亲委派机制
以Tomcat类加载器为例,Tomcat如果使用默认的双亲委派类加载器机制行不行?
思考一下:Tomcat是一个web容器,那么他需要解决什么问题:
- 一个web容器可能需要部署两个应用程序,不通的应用程序可能会依赖同一个第三方类库的不通版本,不能要求同一个类库在同一个服务器只有一份,因此要保证每个应用程序的类库都是独立的,保证相互隔离
- 部署在同一个web容器中相同的类库相同的版本可以共享,否则,如果服务器有10个应用程序,那么要有10份相同的类库加载进虚拟机
- web容器也有自己的依赖的类库,不能与应用程序类混淆。基于安全考虑,应该让容器的类库和程序的类库隔离开来
- web容器要支持jsp的修改,我们知道,jsp文件最终也要编译成class文件才能在虚拟机中运行,但程序运行后修改jsp已经很常见了,web容器需要支持jsp修改后不用重启
Tomcat不能使用双亲委派机制
- 如果使用默认的类加载器机制,那么是无法加载两个相同类库的不通版本,默认的类加载器是不管你是什么版本,只在乎你的全限定类名,并且只有一份
- 默认的类加载器是能够实现的,因为他的职责就是保证唯一性
- 怎么实现jsp文件的热加载,jsp文件其实也是class文件,如果修改了,但是类名一样,类加载器会直接取方法区中已经存在的,修改后的jsp是不会重新加载的,那怎么可以解决呢,可以直接卸载掉这jsp文件的类加载器,所以每一个jsp文件都有一个唯一的类加载器,当一个jsp文件修改后,就直接卸载这个jsp的类加载器,重新创建类加载器,重新加载jsp文件。
Tomcat自定义加载器详解
Tomcat的几个主要的类加载器:
- commonLoader:Tomcat最基本的类加载器,加载路径中的class可以被Tomcat容器本身以及各个Webapp访问
- catalinaLoader:Tomcat容器私有的类加载器,加载路径中的class对于Webapp不可见
- sharedLoader:各个Webapp共享的类加载器,加载路径中的class对于所有的Webapp可见,但是对于Tomcat容器不可见
- WebappClassLoader:各个Webapp私有的类加载器,加载路径中的class只对当前Webapp可见,比如加载war包里相关的类,每个war包应用都有自己的WebAppClassLoader,实现相互隔离,比如不同的war包应用引入了不同的spring版本,这样就可以实现加载各自的spring版本;
从图中的委派关系中可以看出:
CommonClassLoader能加载的类都可以被CatalinaClassLoader和SharedClassLoader使用,从而实现了公有类库的共用,而CatalinaClassLoader和SharedClassLoader自己能加载的类则与对方相互隔离。
WebAppClassLoader可以使用SharedClassLoader加载到的类,各个WebAppClassLoader实例之间相互隔离。
而JasperLoader的加载范围仅仅是这个jsp文件所编译出来的那一个.class文件,它出现的目的就是为了被丢弃:当web容器检测到jsp文件被修改时,会替换掉目前的JasperLoader的实例,并通过再建立一个新的jsp类加载器来实现jsp文件的热加载功能。
tomcat的这种设计模式违背了java推荐的双亲委派模型,tomcat为了实现隔离性,没有遵循这个约定,每个WebAppClassLoader加载自己的目录下的class文件,不会传递给父类加载器,打破了双亲委派机制。
注意:同一个jvm内,两个相同包名和类名的类对象可以共存,因为他们的类加载器可以不一样,所以看两个类对象是否是同一个,除了看类的包名和类名是否相同之外,还需要他们的类加载器是同一个才能认为他们是同一个