做房产的一般用哪个网站好,店铺推广软件,专门做任务的网站吗,域名企业备案对网站的好处文章目录 类加载运行全过程类加载器和双亲委派机制类加载器初始化过程双亲委派机制为什么要设计双亲委派机制#xff1f;全盘负责委托机制自定义类加载器 打破双亲委派机制Tomcat打破双亲委派机制Tomcat自定义加载器详解模拟实现Tomcat的JasperLoader热加载 补充#xff1a;H… 文章目录 类加载运行全过程类加载器和双亲委派机制类加载器初始化过程双亲委派机制为什么要设计双亲委派机制全盘负责委托机制自定义类加载器 打破双亲委派机制Tomcat打破双亲委派机制Tomcat自定义加载器详解模拟实现Tomcat的JasperLoader热加载 补充Hotspot源码JVM启动执行main方法流程 类加载运行全过程
当我们用java命令运行某个类的main函数启动程序时首先需要通过类加载器把主类加载到JVM。
package com.tuling.jvm;public class Math {public static final int initData 666;public static User user new User();public int compute() { //一个方法对应一块栈帧内存区域int a 1;int b 2;int c (a b) * 10;return c;}public static void main(String[] args) {Math math new Math();math.compute();}}通过Java命令执行代码的大体流程如下
其中loadClass的类加载过程有如下几步 加载 验证 准备 解析 初始化 使用 卸载
加载在硬盘上查找并通过IO读入字节码文件使用到类时才会加载例如调用类的main()方法new对象等等在加载阶段会在内存中生成一个代表这个类的java.lang.Class对象作为方法区这个类的各种数据的访问入口验证校验字节码文件的正确性准备给类的静态变量分配内存并赋予默认值解析将符号引用替换为直接引用该阶段会把一些静态方法(符号引用比如main()方法)替换为指向数据所存内存的指针或句柄等(直接引用)这是所谓的静态链接过程(类加载期间完成)动态链接是在程序运行期间完成的将符号引用替换为直接引用下期会讲到动态链接初始化对类的静态变量初始化为指定的值执行静态代码块
类被加载到方法区中后主要包含 运行时常量池、类型信息、字段信息、方法信息、类加载器的引用、对应class实例的引用等信息。 类加载器的引用这个类到类加载器实例的引用 对应class实例的引用类加载器在加载类信息放到方法区中后会创建一个对应的Class 类型的对象实例放到堆(Heap)中, 作为开发人员访问方法区中类定义的入口和切入点。
注意主类在运行过程中如果使用到其它类会逐步加载这些类。 jar包或war包里的类不是一次性全部加载的是使用到时才加载。
public class TestDynamicLoad {static {System.out.println(*************load TestDynamicLoad************);}public static void main(String[] args) {new A();System.out.println(*************load test************);B b null; //B不会加载除非这里执行 new B()}
}class A {static {System.out.println(*************load A************);}public A() {System.out.println(*************initial A************);}
}class B {static {System.out.println(*************load B************);}public B() {System.out.println(*************initial B************);}
}运行结果
类加载器和双亲委派机制
上面的类加载过程主要是通过类加载器来实现的Java里有如下几种类加载器
引导类加载器负责加载支撑JVM运行的位于JRE的lib目录下的核心类库比如rt.jar、charsets.jar等扩展类加载器负责加载支撑JVM运行的位于JRE的lib目录下的ext扩展目录中的JAR类包应用程序类加载器负责加载ClassPath路径下的类包主要就是加载你自己写的那些类自定义加载器负责加载用户自定义路径下的类包
看一个类加载器示例
public class TestJDKClassLoader {public static void main(String[] args) {System.out.println(String.class.getClassLoader());System.out.println(com.sun.crypto.provider.DESKeyFactory.class.getClassLoader().getClass().getName());System.out.println(TestJDKClassLoader.class.getClassLoader().getClass().getName());System.out.println();ClassLoader appClassLoader ClassLoader.getSystemClassLoader();ClassLoader extClassloader appClassLoader.getParent();ClassLoader bootstrapLoader extClassloader.getParent();System.out.println(the bootstrapLoader : bootstrapLoader);System.out.println(the extClassloader : extClassloader);System.out.println(the appClassLoader : appClassLoader);System.out.println();System.out.println(bootstrapLoader加载以下文件);URL[] urls Launcher.getBootstrapClassPath().getURLs();for (int i 0; i urls.length; i) {System.out.println(urls[i]);}System.out.println();System.out.println(extClassloader加载以下文件);System.out.println(System.getProperty(java.ext.dirs));System.out.println();System.out.println(appClassLoader加载以下文件);System.out.println(System.getProperty(java.class.path));}
}运行结果
null
sun.misc.Launcher$ExtClassLoader
sun.misc.Launcher$AppClassLoaderthe bootstrapLoader : null
the extClassloader : sun.misc.Launcher$ExtClassLoader38af3868
the appClassLoader : sun.misc.Launcher$AppClassLoader18b4aac2bootstrapLoader加载以下文件
file:/D:/Program%20Files/Java/jdk1.8.0_291/jre/lib/resources.jar
file:/D:/Program%20Files/Java/jdk1.8.0_291/jre/lib/rt.jar
file:/D:/Program%20Files/Java/jdk1.8.0_291/jre/lib/sunrsasign.jar
file:/D:/Program%20Files/Java/jdk1.8.0_291/jre/lib/jsse.jar
file:/D:/Program%20Files/Java/jdk1.8.0_291/jre/lib/jce.jar
file:/D:/Program%20Files/Java/jdk1.8.0_291/jre/lib/charsets.jar
file:/D:/Program%20Files/Java/jdk1.8.0_291/jre/lib/jfr.jar
file:/D:/Program%20Files/Java/jdk1.8.0_291/jre/classesextClassloader加载以下文件
D:\Program Files\Java\jdk1.8.0_291\jre\lib\ext;C:\WINDOWS\Sun\Java\lib\extappClassLoader加载以下文件
D:\Program Files\Java\jdk1.8.0_291\jre\lib\charsets.jar;D:\Program Files\Java\jdk1.8.0_291\jre\lib\deploy.jar;D:\Program Files\Java\jdk1.8.0_291\jre\lib\ext\access-bridge-64.jar;D:\Program Files\Java\jdk1.8.0_291\jre\lib\ext\cldrdata.jar;D:\Program Files\Java\jdk1.8.0_291\jre\lib\ext\dnsns.jar;D:\Program Files\Java\jdk1.8.0_291\jre\lib\ext\jaccess.jar;D:\Program Files\Java\jdk1.8.0_291\jre\lib\ext\jfxrt.jar;D:\Program Files\Java\jdk1.8.0_291\jre\lib\ext\localedata.jar;D:\Program Files\Java\jdk1.8.0_291\jre\lib\ext\nashorn.jar;D:\Program Files\Java\jdk1.8.0_291\jre\lib\ext\sunec.jar;D:\Program Files\Java\jdk1.8.0_291\jre\lib\ext\sunjce_provider.jar;D:\Program Files\Java\jdk1.8.0_291\jre\lib\ext\sunmscapi.jar;D:\Program Files\Java\jdk1.8.0_291\jre\lib\ext\sunpkcs11.jar;D:\Program Files\Java\jdk1.8.0_291\jre\lib\ext\zipfs.jar;D:\Program Files\Java\jdk1.8.0_291\jre\lib\javaws.jar;D:\Program Files\Java\jdk1.8.0_291\jre\lib\jce.jar;D:\Program Files\Java\jdk1.8.0_291\jre\lib\jfr.jar;D:\Program Files\Java\jdk1.8.0_291\jre\lib\jfxswt.jar;D:\Program Files\Java\jdk1.8.0_291\jre\lib\jsse.jar;D:\Program Files\Java\jdk1.8.0_291\jre\lib\management-agent.jar;D:\Program Files\Java\jdk1.8.0_291\jre\lib\plugin.jar;D:\Program Files\Java\jdk1.8.0_291\jre\lib\resources.jar;D:\Program Files\Java\jdk1.8.0_291\jre\lib\rt.jar;F:\tulingxueyuan\jvm\out\production\jvm;D:\Program Files\JetBrains\IntelliJ IDEA 2021.1\lib\idea_rt.jar
类加载器初始化过程
参见类运行加载全过程图可知其中会创建JVM启动器实例sun.misc.Launcher。 在Launcher构造方法内部其创建了两个类加载器分别是sun.misc.Launcher.ExtClassLoader(扩展类加载器)和sun.misc.Launcher.AppClassLoader(应用类加载器)。 JVM默认使用Launcher的getClassLoader()方法返回的类加载器AppClassLoader的实例加载我们的应用程序。 sun.misc.Launcher类中Launcher的构造方法部分代码如下
//Launcher的构造方法
public Launcher() {Launcher.ExtClassLoader var1;try {//构造扩展类加载器在构造的过程中将其父加载器设置为nullvar1 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);//。。。 。。。省略一些不需关注代码}双亲委派机制
JVM类加载器是有亲子层级结构的如下图
这里类加载其实就有一个双亲委派机制加载某个类时会先委托父加载器寻找目标类找不到再委托上层父加载器加载如果所有父加载器在自己的加载类路径下都找不到目标类则在自己的类加载路径中查找并载入目标类。 比如我们的Math类最先会找应用程序类加载器加载应用程序类加载器会先委托扩展类加载器加载扩展类加载器再委托引导类加载器顶层引导类加载器在自己的类加载路径里找了半天没找到Math类则向下退回加载Math类的请求扩展类加载器收到回复就自己加载在自己的类加载路径里找了半天也没找到Math类又向下退回Math类的加载请求给应用程序类加载器应用程序类加载器于是在自己的类加载路径里找Math类结果找到了就自己加载了。。 双亲委派机制说简单点就是先找父亲加载不行再由儿子自己加载
我们来看下应用程序类加载器AppClassLoader加载类的双亲委派机制源码AppClassLoader的loadClass方法最终会调用其父类ClassLoader的loadClass方法该方法的大体逻辑如下
首先检查一下指定名称的类是否已经加载过如果加载过了就不需要再加载直接返回。如果此类没有加载过那么再判断一下是否有父加载器如果有父加载器则由父加载器加载即调用parent.loadClass(name, false);.或者是调用bootstrap类加载器来加载。如果父加载器及bootstrap类加载器都没有找到指定的类那么调用当前类加载器的findClass方法来完成类加载。
查看java.lang.ClassLoader类的loadClass方法
//ClassLoader的loadClass方法里面实现了双亲委派机制
protected Class? loadClass(String name, boolean resolve)throws ClassNotFoundException
{synchronized (getClassLoadingLock(name)) {// 检查当前类加载器是否已经加载了该类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 statssun.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再加载一次保证被加载类的唯一性
看一个类加载示例
package java.lang;public class String {public static void main(String[] args) {System.out.println(**************My String Class**************);}
}运行结果
全盘负责委托机制
“全盘负责”是指当一个ClassLoder装载一个类时除非显示的使用另外一个ClassLoder该类所依赖及引用的类也由这个ClassLoder载入。
自定义类加载器
自定义类加载器只需要继承 java.lang.ClassLoader 类该类有两个核心方法一个是loadClass(String, boolean)实现了双亲委派机制还有一个方法是findClass默认实现是空方法所以我们自定义类加载器主要是重写findClass方法。
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将一个字节数组转为Class对象这个字节数组是class文件读取后最终的字节数组。return defineClass(name, data, 0, data.length);} catch (Exception e) {e.printStackTrace();throw new ClassNotFoundException();}}}public static void main(String args[]) throws Exception {//初始化自定义类加载器会先初始化父类ClassLoader其中会把自定义类加载器的父加载器设置为应用程序类加载器AppClassLoaderMyClassLoader classLoader new MyClassLoader(F:/test);//F盘创建 test/com/tuling/jvm 几级目录将User类的复制类User1.class丢入该目录Class clazz classLoader.loadClass(com.tuling.jvm.User1);Object obj clazz.newInstance();Method method clazz.getDeclaredMethod(sout, null);method.invoke(obj, null);System.out.println(clazz.getClassLoader().getClass().getName());}
}运行结果
打破双亲委派机制
再来一个沙箱安全机制示例尝试打破双亲委派机制用自定义类加载器加载我们自己实现的 java.lang.String.class
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);return defineClass(name, data, 0, data.length);} catch (Exception e) {e.printStackTrace();throw new ClassNotFoundException();}}/*** 重写类加载方法实现自己的加载逻辑不委派给双亲加载* param name* param resolve* return* throws ClassNotFoundException*/protected Class? loadClass(String name, boolean resolve)throws ClassNotFoundException {synchronized (getClassLoadingLock(name)) {// First, check if the class has already been loadedClass? c findLoadedClass(name);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 statssun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);sun.misc.PerfCounter.getFindClasses().increment();}if (resolve) {resolveClass(c);}return c;}}}public static void main(String args[]) throws Exception {MyClassLoader classLoader new MyClassLoader(F:/test);//尝试用自己改写类加载机制去加载自己写的java.lang.String.classClass clazz classLoader.loadClass(java.lang.String);Object obj clazz.newInstance();Method method clazz.getDeclaredMethod(sout, null);method.invoke(obj, null);System.out.println(clazz.getClassLoader().getClass().getName());}
}运行结果 java.lang.SecurityException: Prohibited package name: java.lang at java.lang.ClassLoader.preDefineClass(ClassLoader.java:659) at java.lang.ClassLoader.defineClass(ClassLoader.java:758) 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的几个主要类加载器
commonLoaderTomcat最基本的类加载器加载路径中的class可以被Tomcat容器本身以及各个Webapp访问catalinaLoaderTomcat容器私有的类加载器加载路径中的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 不是这样实现tomcat 为了实现隔离性没有遵守这个约定每个webappClassLoader加载自己的目录下的class文件不会传递给父类加载器打破了双亲委派机制。
模拟实现Tomcat的webappClassLoader加载自己war包应用内不同版本类实现相互共存与隔离
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);return defineClass(name, data, 0, data.length);} catch (Exception e) {e.printStackTrace();throw new ClassNotFoundException();}}/*** 重写类加载方法实现自己的加载逻辑不委派给双亲加载* param name* param resolve* return* throws ClassNotFoundException*/protected Class? loadClass(String name, boolean resolve)throws ClassNotFoundException {synchronized (getClassLoadingLock(name)) {// First, check if the class has already been loadedClass? c findLoadedClass(name);if (c null) {// If still not found, then invoke findClass in order// to find the class.long t1 System.nanoTime();//非自定义的类还是走双亲委派加载if (!name.startsWith(com.tuling.jvm)){c this.getParent().loadClass(name);}else{c findClass(name);}// this is the defining class loader; record the statssun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);sun.misc.PerfCounter.getFindClasses().increment();}if (resolve) {resolveClass(c);}return c;}}}public static void main(String args[]) throws Exception {MyClassLoader classLoader new MyClassLoader(D:/test);Class clazz classLoader.loadClass(com.tuling.jvm.User1);Object obj clazz.newInstance();Method method clazz.getDeclaredMethod(sout, null);method.invoke(obj, null);System.out.println(clazz.getClassLoader());System.out.println();MyClassLoader classLoader1 new MyClassLoader(D:/test1);Class clazz1 classLoader1.loadClass(com.tuling.jvm.User1);Object obj1 clazz1.newInstance();Method method1 clazz1.getDeclaredMethod(sout, null);method1.invoke(obj1, null);System.out.println(clazz1.getClassLoader());}
}运行结果
自己的加载器加载类调用方法
com.tuling.jvm.MyClassLoaderTest$MyClassLoader266474c2另外一个User1版本自己的加载器加载类调用方法
com.tuling.jvm.MyClassLoaderTest$MyClassLoader66d3c617注意 \color {Red}注意 注意同一个JVM内两个相同包名和类名的类对象可以共存因为他们的类加载器可以不一样所以看两个类对象是否是同一个除了看类的包名和类名是否都相同之外还需要他们的类加载器也是同一个才能认为他们是同一个。
模拟实现Tomcat的JasperLoader热加载
原理后台启动线程监听jsp文件变化如果变化了找到该jsp对应的servlet类的加载器引用(gcroot)重新生成新的JasperLoader加载器赋值给引用然后加载新的jsp对应的servlet类之前的那个加载器因为没有gcroot引用了下一次gc的时候会被销毁。
附下User类的代码
package com.tuling.jvm;public class User {private int id;private String name;public User() {}public User(int id, String name) {super();this.id id;this.name name;}public int getId() {return id;}public void setId(int id) {this.id id;}public String getName() {return name;}public void setName(String name) {this.name name;}public void sout() {System.out.println(自己的加载器加载类调用方法);}
}补充Hotspot源码JVM启动执行main方法流程
