1.从JDK源码级别彻底剖析JVM类加载机制
文章目录
1、从JDK源码级别剖析JVM核心类加载器
类加载运行全过程
当用java命令运行某个main函数启动程序时,首先需要通过类加载器把主类加载到JVM。
public class TestMath {
public static final int initData = 666;
public int compute(){
int a = 1;
int b = 2;
int c = (a+b) * 10;
return c;
}
public static void main(String[] args) {
TestMath testMath = new TestMath();
testMath.compute();
}
}
其中的loadClass的类加载过程有如下几步:
加载>>验证>>准备>>解析>>初始化>>使用>>卸载
- 加载:在硬盘上查找并通过IO读入字节码文件,使用到类时才会加载,例如调用类的main()方法,new对象等等,在加载阶段会在内存中生成一个代表这个类的java.lang.Class对象,作为方法区这个类的何种数据的访问入口。
- 验证:校验字节码文件的正确性(格式是否正确)
- 准备:给类的静态变量分配内存,并赋予默认值(用到的所有变量全部赋默认值)
- 解析:将符号引用替换成直接引用,该阶段把一些静态方法(符号引用(方法名和参数变量为符号),例如main()方法)替换为指向数据所存内存的指针或句柄等(直接引用 ),这是所谓的静态链接过程(类加载期间完成),动态链接是在程序运行期间完成的将符号引用替换为直接引用。
- 初始化:对类的讲台变量初始化为指定的值,执行静态代码块
类加载到方法去中后主要包含运行时常量池、类型信息、字段信息、方法信息、类加载器的引用、对应class实例的引用等信息。
类加载器引用:这个类到类加载器实例的引用
对应类class实例的引用:类加载器在加载类信息放到方法区中后,会创建一个对用的Class类型的对象实例放到堆(Heap)中,作为开发人员访问方法去中类定义的入口和切入点。
注意:主类在运行过程中 如果使用到其他类,会逐步加载这些类。jar包或者war包里的类不是一次全部加载的,是使用的时候才加载的。
总结:加载一个引用类时,先加载类的静态块再加载类的构造方法。
类加载器和双亲委派机制
类加载过程主要是通过类加载器来实现的,Java里有如下几种类加载器:
- 引导类加载器:负责加载支撑JVM运行的位于JRE的lib目录下的核心类库,比如rt.jar、charsets.jar等(C++实现)
- 扩展类加载器:负责加载支撑JVM运行的位于JRE的lib目录下的ex扩展目录中的JAR类包
- 应用程序类加载器:负责加载ClassPath路径下的类包,主要就是加载自己写的那些类
- 自定义加载器:负责加载用户自定义路径下的类包
类加载器初始化过程
参照类运行加载过程图可知其中会创建JVM启动器实例sun.misc.Launcher。
sun.misc.Launcher初始化使用了单例模式,保证JVM虚拟机内只有一个sun.misc.Launcher实例。
在Launcher构造方法内部,其创建了量类加载器,分别是sun.misc.Launcher.ExtClassLoader(扩展类加载器)和sun.misc.Launcher.AppClassLoader(应用类加载器)。
JVM默认使用Launcher的getClassLoader()返回的类加载器AppClassLoader的实例加载应用程序。
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);
//....省略一部分代码
}
2、从JDK源码级别剖析类加载双亲委派机制
双亲委派机制
JVM类加载器是有亲自层级结构的,如下图:
这里类加载其实就有一个双亲委派机制,加载某个类时先委托父类加载器寻找目标类,找不到再委托上层父类加载器加载,如果所有的父类加载器在自己的加载路径下都找不到目标类,则自己的类加载路径中寻找并载入目标类。
比如最上面写的TestMath类,最先找到应用程序加载器加载,应用程序加载器会委托扩展类加载器加载,扩展类加载器再委托引导类加载器,顶层引导类加载器在自己的类加载路径里找了半天没有找到TestMath类,则向下退回加载TestMath类的请求,扩展类加载收到回复就自己加载,扩展类加载器在自己的加载路径中也没找到TestMath类,有向下退回TestMath类的加载请求给应用程序类加载器,应用程序类加载器于是在自己的类加载路径中找到TestMath类,结果就自己加载了。
双亲委派机制简单说是,先找父亲加载,不行再由儿子自己加载。
看下应用程序类加载器AppClassLoader 加载类的双亲委派机制源码,AppClassLoader的loadClass方法最终会调用其父类ClassLoader的loadClass方法,该方法大致逻辑如下:
1)首先,检查一下指定名称的类是否已经加载过,若加载过,就不需要加载,直接返回。
2)如果此类没有加载过,再判断下是否有父类加载器,若有则有其父类加载器加载(调用parent.loadClass(name,false);)或者调用bootstrap类加载器来加载。
3)如果父类加载器及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;
}
}
为什么要设计双亲委派机制?
1)沙箱安全机制:自己写的java.lang.String.class类不会被加载,这样便可以防止核心API库随意篡改
2)避免类的重复加载:当父亲Classloader已经加载了该类,子类Classloader就没必要再加载一次,保证被加载类的唯一性。
package java.lang;
public String{
public static void main(String[] args){
System.out.println("******String Class************");
}
}
运行结果:
错误:在类 java.lang.String 中找不到main方法,请将main方法定义为public static void main(String[] args)
否则 Java FX应用程序类必须扩展javafx.application.Application
全盘负责委托机制
全盘负责是指当一个Classloader装载一个类时,除非显示的使用另一个Classloader,该类所依赖及引用的类也有这个Classloader载入。
自定义类加载器示例
自定义类加载器只需要继承java.lang.ClassLoader类,该类有两个核心方法,一个是loadClass(String,boolean),实现了双亲委派机制,还有一个方法是findClass,默认实现是空方法,所以我们自定义类加载器主要重写findClass方法。
import java.io.FileInputStream;
import java.lang.reflect.Method;
public class MyClassLoaderTest {
static class MyClassLoader extends ClassLoader{
private String classPath;
public MyClassLoader(String classPath){
this.classPath = classPath;
}
private byte[] loadByte(String name) throws Exception{
name = name.replaceAll("\\.","/");
FileInputStream fis = new FileInputStream(classPath+"/"+name+".class");
int len = fis.available();
byte[] data = new byte[len];
fis.read(data);
fis.close();
return data;
}
protected Class<?> findClass(String name) throws ClassNotFoundException {
try {
byte[] data = loadByte(name);
//defineClass 方法 加载校验等逻辑
return defineClass(name,data,0,data.length);
}catch (Exception e){
e.printStackTrace();
throw new ClassNotFoundException();
}
}
}
public static void main(String[] args) throws Exception{
//初始化自定义类加载器,会闲初始化父类Classloader,其中会把自定义类加载器的父类
// 加载器设置为应用程序加载器AppClassloader,加载类的路径
MyClassLoader classLoader = new MyClassLoader("D:/soft");
//类的全包名,包名就是文件夹路径,class 真实地址是D:/soft/jvm/TestMath.class
//TestMath类就是本项目的一个类
Class calss = classLoader.loadClass("jvm.TestMath");
Object obj = calss.newInstance();
Method method = calss.getDeclaredMethod("compute",null);
method.invoke(obj,null);
System.out.println(calss.getClassLoader().getClass().getName());
}
}
打印的结果如下
sun.misc.Launcher$AppClassLoader
如果把本地项目中的TestMath.class删除后运行的结果如下
jvm.MyClassLoaderTest$MyClassLoader
这就是双亲委派机制,如果父级加载器找到此类并加载,当前加载器就不加载了,若父加载器找不到,就用自定义加载器加载。
3、手写自定义类加载器打破双亲委派机制
打破双亲委派机制
再来一个沙箱安全机制示例,尝试打破双亲委派机制,用自定义类加载自己实现的jvm.TestMath.calss
1)重写 loadClass 方法
2)删除双亲委派的代码
运行下面的代码:
import java.io.FileInputStream;
import java.lang.reflect.Method;
public class MyClassLoaderTest {
static class MyClassLoader extends ClassLoader{
private String classPath;
public MyClassLoader(String classPath){
this.classPath = classPath;
}
private byte[] loadByte(String name) throws Exception{
name = name.replaceAll("\\.","/");
FileInputStream fis = new FileInputStream(classPath+"/"+name+".class");
int len = fis.available();
byte[] data = new byte[len];
fis.read(data);
fis.close();
return data;
}
protected Class<?> findClass(String name) throws ClassNotFoundException {
try {
byte[] data = loadByte(name);
//defineClass 方法 加载校验等逻辑
return defineClass(name,data,0,data.length);
}catch (Exception e){
e.printStackTrace();
throw new ClassNotFoundException();
}
}
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();
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;
}
}
}
public static void main(String[] args) throws Exception{
//初始化自定义类加载器,会闲初始化父类Classloader,其中会把自定义类加载器的父类
// 加载器设置为应用程序加载器AppClassloader,加载类的路径
MyClassLoader classLoader = new MyClassLoader("D:/soft");
//类的全包名,包名就是文件夹路径,class 真实地址是D:/soft/jvm/TestMath.class
Class calss = classLoader.loadClass("jvm.TestMath");
Object obj = calss.newInstance();
Method method = calss.getDeclaredMethod("compute",null);
method.invoke(obj,null);
System.out.println(calss.getClassLoader().getClass().getName());
}
}
结果如下
java.io.FileNotFoundException: D:\soft\java\lang\Object.class (系统找不到指定的路径。)
at java.io.FileInputStream.open0(Native Method)
为什么呢?因为打破双亲委派机制,只会加载我们指定的目录,因为类TestMath继承了Object。
解决方案:把Object.class放到D:\soft\java\lang路径下?可行吗?
不可行,因为违反了沙箱安全机制,不能修改核心API
修改loadClass方法如下:当时jvm开头的类走本地加载,不是jvm开头的走父级加载器。
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();
//修改的地方
if(!name.startsWith("jvm")){
c = this.getParent().loadClass(name);
}else {
c = findClass(name);
}
// thi s 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;
}
}
4、Tomcat类加载机制深度剖析
Tomcat打破双亲委派机制
以Tomcat类加载为例,Tomcat如果使用默认的双亲委派类加载机制行不行? 答案:不行
思考一下:Tomcat 是个web容器,那么它要解决什么问题:
1)一个web容器可能需要部署两个应用程序,不同的应用程序可能会依赖同一个第三方类库的不同版本,不能要求同一个类库在同一个服务器上只有一份,因此要保证每个应用程序的类库都是独立的,保证相互隔离。
2)不是在同一个web容器中相同的类库相同的版本可以共享。否则,如果服务器中有10个应用程序,那么要有10分相同的类库加载进虚拟机。
3)web容器也有自己依赖的类库,不能与应用程序的类库混淆。基于安全考虑,应该让容器的类库和程序的类库隔离开来。
4)web容器要支持jsp的修改,jsp文件最终也是编程成class文件才能在虚拟机中运行,但程序运行后修改了jsp已经是常事,web容器需要支持jsp修改后不用重启。
上面的四个问题答案如下:
默认的类加载器是能够实现的,因为它的职责是保证唯一性
第三个问题和第一个一样。
第四个问题:想想怎么实现jsp文件的热加载,jsp文件其实也就是class文件,那么如果修改了,但类名还是一样的,类加载器会直接取方法区中已经存在的,修改后的jsp是不会重新加载的。那么怎么办呢?可以直接卸载掉这jsp文件的类加载器,所以你应该想到了,每个jsp文件对应一个唯一的类加载器,当一个jsp文件修改了,就直接卸载这个jsp类加载器。重新创建类加载器,重新加载jsp文件。
Tomcat加载器层级图如下
Tomcat的几个主要类加载器:
- commonLoader:Tomcat最基本的类加载器,加载路径中的class可以被Tomcat容器本身以及各个Webapp访问;
- catalinaLoader:Tomcat容器私有化的类加载器,加载路径中的class对于Webapp不可见;
- WebappClassLoder:各个Webapp私有的类加载器,加载路径中的class只对当前Webapp可见,比如加载war包中相关的类,每个war包应用都有自己的WebappClassLoader,实现相互隔离,比如不同war包应用因为不同的spring版本,这样实现就能加载各自的spring版本。
从上图委派关系中可以看出:
CommonClassLoader能加载的类都可以被CatalinaClassLoader和SharedClassLoader使用,从而实现了共有类库的共用,而CatalinaClassLoader和SharedClassLoader自己加载的类与对方相互隔离。
WebappClassLoder可以使用SharedClassLoader加载的类,但是各个WebappClassLoader实例之间相互隔离。
JasperLoader的加载范围仅仅是JSP文件编译出来的那个class文件,它出现的目的就是为了被丢弃;当Web容器检测到JSP文件被修改时,会替换掉目前的JasperLoader实例,在创建一个新的JSP类加载器实现JSP文件的热加载功能。
tomcat 这种类加载机制违背 了java推荐的双亲委派机制吗?是的违背了。
Tomcat为了实现隔离性,没有遵循这个约定,每个WebappClassLoder加载自己的目录下的class文件,不会传递给父类加载,打破了双亲委派机制。