类加载
当通过java命令运行某个类的main函数启动程序时，首先需要通过类加载器把主类加载到JVM，然后才是main方法的调用，Windows系统中大致流程如下
- java com.mrathena.jvm.Math
- java.exe调用底层的jvm.dll文件创建Java虚拟机(C++实现)
- 创建引导类加载器实例(C++实现)
- C++调用Java代码，使用引导类加载器加载Jvm启动器sun.misc.Launcher，并创建其单例实例，该过程中会同时创建扩展类加载器实例和应用类加载器实例，并设置父子关系
- 获取运行类（Math）自己的类加载器（AppClassLoader），调用loadClass加载要运行的类Math，
Launcher.getLaunche().getClassLoader().loadClass("com.mrathena.jvm.Math")，返回一个Class对象 - 加载完成后，JVM会执行Math类的main方法入口（C++发起调用）
- Math.main()
- JVM销毁
类被加载到方法区中后主要包含 运行时常量池、类型信息、字段信息、方法信息、类加载器的引用、对应class实例的引用等信息。
类加载器的引用：这个类到类加载器实例的引用。Class.class.getClassLoader(), object.getClass.getClassLoader()
对应class实例的引用：类加载器在加载类信息放到方法区中后，会创建一个对应的Class 类型的对象实例放到堆(Heap)中, 作为开发人员访问方法区中类定义的入口和切入点。
注意，主类在运行过程中如果使用到其它类，会逐步加载这些类。jar包或war包里的类不是一次性全部加载的，是使用到时才加载。
ClassLoader.loadClass 流程
加载 >> 验证 >> 准备 >> 解析 >> 初始化 >> 使用 >> 卸载
- 加载：在硬盘上查找并通过IO读入字节码文件。使用到类时才会加载，例如调用类的main()方法，new对象等等，在加载阶段会在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口
- 验证：校验字节码文件的正确性
- 准备：给类的静态变量分配内存，并赋予默认值（0、null等）。这里只是静态变量，加 final 的是静态常量
- 解析：将符号引用替换为直接引用，该阶段会把一些静态方法(符号引用，比如main()方法)替换为指向数据所存内存的指针或句柄等(直接引用)，这是所谓的静态链接过程(类加载期间完成)，动态链接是在程序运行期间完成的将符号引用替换为直接引用（比如实例方法的符号替换为对应代码的地址）
- 初始化：对类的静态变量初始化为指定的值，执行静态代码块
举例
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************");
}
}
运行结果：
*************load TestDynamicLoad************
*************load A************
*************initial A************
*************load test************
类加载器
类加载过程主要是通过类加载器来实现的，Java里有如下几种类加载器
- 引导类加载器：负责加载支撑JVM运行的位于JRE的lib目录下的核心类库，比如rt.jar、charsets.jar等
- 扩展类加载器：负责加载支撑JVM运行的位于JRE的lib\ext扩展目录中的jar包
- 应用程序类加载器：负责加载ClassPath路径下的类包，主要就是加载自己写的那些类
- 自定义加载器：负责加载用户自定义路径下的类包（可通过覆盖ClassLoader的loadClass方法打破双亲委派机制）
注意点
- 引导类加载器是由C++创建和调用的，在java中无法看到对应的实例，所以
String.class.getClassLoader()结果是 null com.sun.crypto.provider.DESKeyFactory.class.getClassLoader()的结果是 ExtClassLoader 的实例com.mrathena.jvm.Math.class.getClassLoader()的结果是 AppClassLoader 的实例ClassLoader.getSystemClassLoader()的结果是 AppClassLoader 的实例appClassLoader.getParent()的结果是 ExtClassLoader 的实例extClassloader.getParent()的结果是 null- 启动类加载起加载
Launcher.getBootstrapClassPath().getURLs()这些文件，如 rt.jar，charsets.jar 等 - 扩展类加载器加载
System.getProperty("java.ext.dirs")目录下的jar包 - 应用类加载器加载
System.getProperty("java.class.path")目录下的jar包，有和其他两个类加载器重复的目录，这些重复的目录中的jar和class等由其他两个类加载器加载，应用类加载器主要负责不重复的目录如target下的class和jar的加载
类加载器初始化过程
JVM启动器是 sun.misc.Launcher。在Launcher的构造方法中，创建了其他两个类加载器，分别是sun.misc.Launcher.ExtClassLoader(扩展类加载器)和sun.misc.Launcher.AppClassLoader(应用类加载器)。并设置应用类加载器实例的parent是扩展类加载器实例，扩展类加载器实例的parent是null（应该是启动类加载器实例，但是因为启动类加载器是由C++创建的，在java中无法拿到该实例，所以理解扩展类加载器的父加载器是启动类加载器就好了）。Launcher类还有一个字段ClassLoader loader，专门用来存储应用类加载器实例的引用，JVM默认使用Launcher的getClassLoader()方法返回的类加载器AppClassLoader的实例加载我们的应用程序。
//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 {
// 构造应用类加载器，在构造的过程中将其父加载器设置为扩展类加载器实例
// 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");
。。。 。。。 //省略一些不需关注代码
}
双亲委派机制
类加载器有父子关系，从上（父）到下（子）分别是 启动类加载器 >> 扩展类加载器 >> 应用类加载器 >> 自定义加载器
加载某个类的时候，除非显式指定类加载器，否则默认由应用类加载器加载。先从应用类加载器自身已加载过的类中查找是否加载过该类，有则返回对应的Class实例，没有则由父加载器即扩展类加载器尝试加载。扩展类加载器加载时，也是先从自身已加载过的类中查找是否加载过该类，有则返回对应的Class实例，没有则由父加载器即启动类加载器尝试加载。启动类加载器加载时，也是从自身已加载过的类中查找是否加载过该类，有则返回对应的Class实例，没有则尝试在启动类加载器负责的路径下查找该类，有则加载并缓存并返回对应的Class实例，没有则返回null。扩展类加载器判断其父加载器的返回结果，如果不是null则继续返回对应的Class实例，如果是null则尝试在扩展类加载器负责的类路径下查找该类，有则加载并缓存并返回对应的Class实例，没有则返回null。应用类加载器判断其父加载器的返回结果，如果不是null则继续返回对应的Class实例，没有是null则尝试在应用类加载器负责的类路径细下查找该类，有则加载并缓存并返回对应的Class实例，没有则返回null，然后报错 ClassNotFoundException
// 扩展类加载器和应用类加载器都继承了ClassLoader
// 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 { // 如果当前加载器父加载器为空（扩展类的父加载器是null）则委托引导类加载器加载该类
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;
}
}
为什么要设计双亲委派机制？
- 沙箱安全机制：自己写的同名核心类不会被加载（同名的已被父加载器加载过了），这样便可以防止核心API库被随意篡改
- 避免类的重复加载：当父亲已经加载了该类时，就没有必要子ClassLoader再加载一次，保证被加载类的唯一性
全盘负责委托机制
“全盘负责”是指当一个ClassLoder装载一个类时，除非显式使用另外一个ClassLoder，该类所依赖及引用的类也由这个ClassLoder载入。
自定义类加载器
自定义类加载器只需要继承 java.lang.ClassLoader 类，该类有两个核心方法，一个是loadClass(String, boolean)，实现了双亲委派机制，它是protected的(子类不覆盖就会默认继承)，还有一个方法是findClass，默认实现是空方法，所以我们自定义类加载器主要是重写findClass方法。在loadClass方法中，如果先从缓存的Class中找不到要加载的类，则会调用findClass去找对应的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);
// 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，其中会把自定义类加载器的父加载器设置为应用程序类加载器AppClassLoader
// 指定该自定义类加载器负责D:/test目录下的class和jar的加载
MyClassLoader classLoader = new MyClassLoader("D:/test");
// D盘创建 test/com/mrathena/jvm 目录，将User.class丢入该目录
Class clazz = classLoader.loadClass("com.mrathena.jvm.User");
Object obj = clazz.newInstance();
Method method = clazz.getDeclaredMethod("sout", null);
method.invoke(obj, null);
System.out.println(clazz.getClassLoader().getClass().getName());
}
}
打破双亲委派机制
打破双薪委派机制指的是使用自定义类加载器，覆盖loadClass方法，不走父类加载器查找，直接在本类加载器做类加载
再来一个沙箱安全机制示例，尝试打破双亲委派机制，用自定义类加载器加载我们自己写的 java.lang.String.class
未打破双亲委派机制时，使用自定义类加载器或应用类加载器加载自己写的 java.lang.String 时，最终会被启动类加载器中找到的jdk中的String类的Class对象覆盖。
打破双亲委派机制时，使用自定义类加载器加载自己写的 java.lang.String 时，会触发java安全机制，直接报 java.lang.SecurityException: Prohibited package name: java.lang
Tomcat 打破双亲委派机制
Tomcat 为什么需要打破双亲委派机制？
- 一个web容器可能需要部署多个应用程序，不同的应用程序可能会依赖同一个第三方类库的不同版本，不能要求同一个类库在同一个服务器只有一份，因此要保证每个应用程序的类库都是独立的，保证相互隔离。
- 部署在同一个web容器中相同的类库相同的版本可以共享。否则，如果服务器有10个应用程序，那么要有10份相同的类库加载进虚拟机。
- web容器也有自己依赖的类库，不能与应用程序的类库混淆。基于安全考虑，应该让容器的类库和程序的类库隔离开来。
- web容器要支持jsp的修改，我们知道，jsp 文件最终也是要编译成class文件才能在虚拟机中运行，但程序运行后修改jsp已经是司空见惯的事情， web容器需要支持 jsp 修改后不用重启。
第一个问题，如果使用默认的类加载器机制，那么是无法加载两个相同类库的不同版本的，默认的类加器是不管你是什么版本的，只在乎你的全限定类名，并且只有一份。
第二个问题，默认的类加载器是能够实现的，因为他的职责就是保证唯一性。
第三个问题和第一个问题一样。
第四个问题，我们想我们要怎么实现jsp文件的热加载，jsp 文件其实也就是class文件，那么如果修改了，但类名还是一样，类加载器会直接取方法区中已经存在的，修改后的jsp是不会重新加载的。那么怎么办呢？我们可以直接卸载掉这jsp文件的类加载器（=null），所以你应该想到了，每个jsp文件对应一个唯一的类加载器，当一个jsp文件修改了，就直接卸载这个jsp类加载器。重新创建类加载器，重新加载jsp文件。
tomcat7之前，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 不是这样实现，tomcat 为了实现隔离性，没有遵守这个约定，每个webappClassLoader加载自己的目录下的class文件，不会传递给父类加载器，打破了双亲委派机制。
模拟tomcat
搞一个不关联父类加载器的自定义类加载器，根据文件夹创建多个负责不同文件夹的自定义类加载器实例，分别负责不同路径下类的加载
注意：同一个JVM内，两个相同包名和类名的类对象可以共存，因为他们的类加载器可以不一样，所以看两个类对象是否是同一个，除了看类的包名和类名是否都相同之外，还需要他们的类加载器也是同一个才能认为他们是同一个。
模拟实现Tomcat的JasperLoader热加载
原理：后台启动线程监听jsp文件变化，如果变化了找到该jsp对应的servlet类的加载器引用(gcroot)，重新生成新的JasperLoader加载器赋值给引用，然后加载新的jsp对应的servlet类，之前的那个加载器因为没有gcroot引用了，下一次gc的时候会被销毁。
扫一扫
171
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
