JVM系列(一) : JAVA类加载机制
1、什么是类加载
类加载其实是在硬盘上查找通过io读入字节码文件（class文件）并加载到jvm方法区，在加载过程中会在堆内存中生成一个代表这个类的java.lang.Class对象,Class对象封装了类在方法区内的数据结构，并且提供了访问方法区内部数据结构的接口。
加载.calss文件的方式：
- 从本地系统直接加载
- 通过网络下载.class
- 从zip、jar等归档文件中加载.class
2、类生命周期
其中类加载过程包括加载、验证、准备、解析、初始化五个阶段，在这五个阶段中加载、验证、准备、初始化这四个阶段顺序是确定的，而解析阶段不一定，它在某些情况下可以在初始化之后，这是为了支持java语言运行时的动态绑定（例如接口只在调用的时候才知道具体实现的是哪个子类）。注意这几个阶段是按顺序开始，而不是按顺序进行或者完成，因为这些阶段通常都是互相交叉地混合进行，通常在一个阶段执行的过程中调用或者激活另外一个阶段。
2.1、加载：查找并加载类的二进制数据（class）
加载阶段是“类加载机制”中的一个阶段、虚拟机需要完成以下事情：
1、通过一个类的全限定名来获取其定义的二进制字节流
2、将这个字节流所代表的的静态存储结构转换为方法区的运行时数据结构
3、在java堆中生成一个代表这个类的java.lang.Class对象，作为对方法区中这些数据访问的入口
2.2、验证：确保加载的class的正确性
验证是链接阶段的第一步，这一步主要的目的是确保class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身安全。
验证阶段大致完成4个阶段的检验过程：
文件格式验证：验证字节流是否符号class文件格式规范，例如： class文件是否已魔术0xCAFEBABE开头 ，主、次版本号是否在当前虚拟机处理范围之内等
元数据验证：这个阶段是对字节码描述的信息进行语义分析，以保证其描述的信息符合Java语言规范的要求；例如：这个类是否有父类，除了java.lang.Object之外。
字节码验证：通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。例如可以把一个子类对象赋值给父类数据类型，这是安全的，但不能把一个父类对象赋值给子类数据类型
符号引用验证：符号引用中通过字符串描述的全限定名是否能找到对应的类、符号引用类中的类，字段和方法的访问性(private、protected、public、default)是否可被当前类访问（确保解析动作能正确执行）
验证阶段是非常重要的，但不是必须的，它对程序运行期没有影响，如果所引用的类经过反复验证，那么可以考虑采用
-Xverifynone参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间
2.3、准备: 给类的静态变量分配内存，并赋予默认值
准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些内存都将在方法区中分配。需要注意以下2个点：
1、这时候进行内存分配的仅包括类变量（static），而不包括实例变量，实例变量会在对象实例化时随着对象一块分配在Java堆中。
2、这里所设置的初始值通常情况下是数据类型默认的零值（如0、0L、null、false等），而不是被在Java代码中被显式地赋予的值。
假设一个类变量的定义为：public static int value = 3；那么变量value在准备阶段过后的初始值为0，而不是3，因为这时候尚未开始执行任何Java方法，而把value赋值为3的putstatic指令是在程序编译后，存放于类构造器<clinit>（）方法之中的，所以把value赋值为3的动作将在初始化阶段才会执行。
3、如果类字段的字段属性表中存在ConstantValue属性，即同时被final和static修饰，那么在准备阶段变量value就会被初始化为ConstValue属性所指定的值。
假设上面的类变量value被定义为： public static final int value = 3；编译时Javac将会为value生成ConstantValue属性，在准备阶段虚拟机就会根据ConstantValue的设置将value赋值为3。
2.4、解析：将符号引用替换为直接引用
解析阶段是虚拟机将符号引用替换为直接引用的过程，该阶段会把一些静态方法(符号引用，比如main()方法)替换为指向数据所存内存的指针或句柄等(直接引用)，这是所谓的静态链接过程(类加载期间完成)，动态链接是在程序运行期间完成的将符号引用替换为直接引用。
解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行。
符号引用就是一组符号来描述目标，可以是任何字面量。
直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。
2.5、初始化：
对类的静态变量初始化为指定的值，执行静态代码块。在java中对类变量进行初始值设定有两种方式：
1、声明类变量是指定初始值
2、使用静态代码块为类变量指定初始值
JVM初始化步骤
- 假如这个类还没有被加载和连接，则程序先加载并连接该类
- 假如该类的直接父类还没有被初始化，则先初始化其直接父类
- 假如类中有初始化语句，则系统依次执行这些初始化语句
何时触发初始化：
1、创建类实例。也就是new的方式
2、调用某个类的类方法
3、访问某个类或接口的类变量，或为该类变量赋值
4、使用反射方式强制创建某个类或接口对应的java.lang.Class对象
5、初始化某个类的子类，则其父类也会被初始化
6、虚拟机启动时，定义了main()方法的那个类先初始化
以上情况称为称对一个类进行“主动引用”，除此种情况之外，均不会触发类的初始化，称为“被动引用” 接口的加载过程与类的加载过程稍有不同。接口中不能使用static{}块。当一个接口在初始化时，并不要求其父接口全部都完成了初始化，只有真正在使用到父接口时（例如引用接口中定义的常量）才会初始化。
被动引用例子
1、子类调用父类的静态变量，子类不会被初始化。只有父类被初始化。。对于静态字段，只有直接定义这个字段的类才会被初始化
2、通过数组定义来引用类，不会触发类的初始化，MyClass[] cs = new MyClass[10];
class SuperClass { static { System.out.println("superclass init"); } public static int value = 123; } class SubClass extends SuperClass { static { System.out.println("subclass init"); } } public class Test { public static void main(String[] args) { System.out.println(SubClass.value);// 被动应用1 SubClass[] sca = new SubClass[10];// 被动引用2 } }
程序运行输出 superclass init 123 从上面的输入结果证明了 被动引用1 与 被动引用2
class ConstClass { static { System.out.println("ConstClass init"); } public static final String HELLOWORLD = "hello world"; } public class Test { public static void main(String[] args) { System.out.println(ConstClass.HELLOWORLD);// 调用类常量 } }
程序输出结果 hello world 从上面的输出结果证明了被动引用3
class SingleTon { private static SingleTon singleTon = new SingleTon(); public static int count1; public static int count2 = 0; private SingleTon() { count1++; count2++; } public static SingleTon getInstance() { return singleTon; } } public class Test { public static void main(String[] args) { SingleTon singleTon = SingleTon.getInstance(); System.out.println("count1=" + singleTon.count1); System.out.println("count2=" + singleTon.count2);
结果：count1=1 count2=0
分析:
1:SingleTon singleTon = SingleTon.getInstance();调用了类的SingleTon调用了类的静态方法，触发类的初始化
2:类加载的时候在准备过程中为类的静态变量分配内存并初始化默认值 singleton=null count1=0,count2=0
3:类初始化化，为类的静态变量赋值和执行静态代码快。singleton赋值为new SingleTon()调用类的构造方法
4:调用类的构造方法后count=1;count2=1
5:继续为count1与count2赋值,此时count1没有赋值操作,所有count1为1,但是count2执行赋值操作就变为0
2.6、结束生命周期
在如下几种情况下，Java虚拟机将结束生命周期
- 执行了
System.exit()方法 - 程序正常执行结束
- 程序在执行过程中遇到了异常或错误而异常终止
- 由于操作系统出现错误而导致Java虚拟机进程终止
3、类加载器
Java里有如下几种类加载器：
- 引导类加载器：Bootstrap ClassLoader 负责加载支撑JVM运行的位于JRE的lib目录下的核心类库，比如rt.jar、charsets.jar等
- 扩展类加载器： ExtClassLoader 负责加载支撑JVM运行的位于JRE的lib目录下的ext扩展目录中的JAR类包
- 应用程序类加载器：AppClassLoader 负责加载ClassPath路径下的类包，主要就是加载自己写的那些类
- 自定义加载器：负责加载用户自定义路径下的类包
public class TestClassLoad { public static void main(String[] args) { 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); } }the bootstrapLoader(引导类加载器) : null the extClassloader(扩展类加载器) : sun.misc.Launcher$ExtClassLoader@4a574795 the appClassLoader(应用程序类加载器): sun.misc.Launcher$AppClassLoader@18b4aac2从上面的结果可以看出，并没有获取到
ExtClassLoader的父Loader，原因是Bootstrap Loader（引导类加载器）是用C语言实现的，找不到一个确定的返回父Loader的方式，于是就返回null
类加载器加载指定目录下的类：
public class TestClassLoad { public static void main(String[] args) { 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("extClassloader加载以下文件："); System.out.println(System.getProperty("java.ext.dirs")); System.out.println("appClassLoader加载以下文件："); System.out.println(System.getProperty("java.class.path")); } }
类加载器的亲子关系：
注意：这里父类加载器并不是通过继承关系来实现的，而是采用组合实现的。
引导类加载器：它使用C++实现，是虚拟机自身的一部分；所有其它的类加载器：比如ExtClassLoader，AppClassLoader这些类加载器都由Java语言实现，独立于虚拟机之外，并且全部继承自抽象类java.lang.ClassLoader，这些类加载器需要由启动类加载器加载到内存中之后才能去加载其他的类。
类加载器初始化：
在类加载的过程中会创建jvm启动器实例sun.misc.Launchher。sun.misc.Launcher初始化使用了单例模式设计，保证一个JVM虚拟机内只有一个sun.misc.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); } }
4、双亲委派模型：
双亲委派模型的工作流程： 当一个类加载器收到加载类的请求，首先它会委托给它的父加载器类加载，，如果所有的父加载器类在自己加载类路径都找不到目标类，则在自己的类加载路径中查找并载入目标类
- 当
AppClassLoader加载一个class时，它首先不会自己去尝试加载这个类，而是把类加载请求委派给父类加载器ExtClassLoader去完成。 - 当
ExtClassLoader加载一个class时，它首先也不会自己去尝试加载这个类，而是把类加载请求委派给BootStrapClassLoader```去完成。 - 如果
BootStrapClassLoader加载失败（例如在$JAVA_HOME/jre/lib里未查找到该class），会使用ExtClassLoader来尝试加载； - 若ExtClassLoader也加载失败，则会使用
AppClassLoader来加载，如果AppClassLoader也加载失败，则会报出异常ClassNotFoundException。
public Class<?> loadClass(String var1, boolean var2) throws ClassNotFoundException { int var3 = var1.lastIndexOf(46); if (var3 != -1) { SecurityManager var4 = System.getSecurityManager(); if (var4 != null) { var4.checkPackageAccess(var1.substring(0, var3)); } } if (this.ucp.knownToNotExist(var1)) { Class var5 = this.findLoadedClass(var1); if (var5 != null) { if (var2) { this.resolveClass(var5); } return var5; } else { throw new ClassNotFoundException(var1); } } else { // 调用 ClassLoader 中的 loadClass 方法 return super.loadClass(var1, var2); } }
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再加载一
次，保证被加载类的唯一性
5、类加载
- 全盘负责委托机制（全盘负责），是指当一个ClassLoder装载一个类时，该类所依赖及引用的类也由这个ClassLoder载入，除非显示的使用另外一个ClassLoder。
- 父类委托，先让父类加载器试图加载该类，只有在父类加载器无法加载该类时才尝试从自己的类路径中加载该类
- 缓存机制，缓存机制将会保证所有加载过的Class都会被缓存，当程序中需要使用某个Class时，类加载器先从缓存区寻找该Class，只有缓存区不存在，系统才会读取该类对应的二进制数据，并将其转换成Class对象，存入缓存区。这就是为什么修改了Class后，必须重启JVM，程序的修改才会生效
类加载有三种方式：
- 1、命令行启动应用时候由JVM初始化加载
- 2、通过Class.forName()方法动态加载
- 3、通过ClassLoader.loadClass()方法动态加载
Class.forName()：将类的.class文件加载到jvm中之外，还会对类进行解释，执行类中的static块；ClassLoader.loadClass()：只干一件事情，就是将.class文件加载到jvm中，不会执行static中的内容,只有在newInstance才会去执行static块。Class.forName(name, initialize, loader)带参函数也可控制是否加载static块。并且只有调用了newInstance()方法采用调用构造函数，创建类的对象 。
6、自定义类加载器
通常情况下，我们都是直接使用系统类加载器。但是，有的时候，我们也需要自定义类加载器。比如应用是通过网络来传输 Java类的字节码，为保证安全性，这些字节码经过了加密处理，这时系统类加载器就无法对其进行加载，这样则需要自定义类加载器来实现。自定义类加载器一般都是继承自ClassLoader类，从上面对loadClass方法来分析来看，我们只需要重写 findClass 方法即可,如下所示：
public class MyClassLoader extends ClassLoader { private String classPath; public MyClassLoader(String classPath) { this.classPath = classPath; } @Override protected Class<?> findClass(String name) { byte[] data = loadData(name); return super.defineClass(name, data, 0, data.length); } public byte[] loadData(String name) { name = name.replaceAll("\\.", "/"); String name1 = classPath + "/" + name + ".class"; try (FileInputStream fis = new FileInputStream(name1);) { int size = fis.available(); byte[] buffer = new byte[size]; fis.read(buffer); return buffer; } catch (Exception e) { e.printStackTrace(); } return null; } public static void main(String[] args) { MyClassLoader myClassLoader=new MyClassLoader("D:\\class"); Class userClass= myClassLoader.loadClass("com.huy.User"); System.out.println(userClass.getClassLoader().getClass().getName()); } }
6.1、打破双亲委派机制模型
public class MyClassLoader extends ClassLoader { private String classPath; public MyClassLoader(String classPath) { this.classPath = classPath; } @Override public Class<?> findClass(String name) { byte[] data = loadData(name); return super.defineClass(name, data, 0, data.length); } // 重写 loadClass @Override public 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(); if (c == null) { // If still not found, then invoke findClass in order // to find the class. long t1 = System.nanoTime(); if (!StringUtils.startsWith(name,"com.huy.User")) {// 如果要加载的类不是外部自定义类，通过双亲委派机制加载 c=this.getParent().loadClass(name); }else{// 如果要加载的类是外部自定义类，使用自定义类加载器加载 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 byte[] loadData(String name) { name = name.replaceAll("\\.", "/"); String name1 = classPath + "/" + name + ".class"; try (FileInputStream fis = new FileInputStream(name1);) { int size = fis.available(); byte[] buffer = new byte[size]; fis.read(buffer); return buffer; } catch (Exception e) { e.printStackTrace(); } return null; } public static void main(String[] args) throws ClassNotFoundException { MyClassLoader myClassLoader=new MyClassLoader("D:\\class"); Class userClass= myClassLoader.loadClass("com.huy.User"); System.out.println(userClass.getClassLoader().getClass().getName()); } }
注意：同一个JVM内，两个相同包名和类名的类对象可以共存，因为他们的类加载器可以不一样，所以看两个类对象是否是同一个，除了看类的包名和类名是否都相同之外，还需要他们的类加载器也是同一个才能认为他们是同一个
7、Tomcat类加载器机制
Tomcat是个web容器， 那么它要解决以下问题：
1. 一个web容器可能需要部署多个应用程序，不同的应用程序可能会依赖同一个第三方类库的不同版本，不能要求同一个类库在同一个服务器只有一份，因此要保证每个应用程序的类库都是独立的，保证相互隔离。
2. 部署在同一个web容器中相同的类库相同的版本可以共享。
3. web容器也有自己依赖的类库，不能与应用程序的类库混淆。
4. web容器要支持jsp的修改，jsp 文件最终也是要编译成class文件才能在虚拟机中。运行，但程序运行后修改jsp已经是司空见惯的事情， web容器需要支持 jsp 修改后不用重启
- commonLoader：Tomcat最基本的类加载器，加载路径中的class可以被Tomcat容器本身以及各个Webapp访问。
- catalinaLoader：Tomcat容器私有的类加载器，加载路径中的class对于Webapp不可见
- sharedLoader：各个Webapp共享的类加载器，加载路径中的class对于所有Webapp可见，但是对于Tomcat容器不可见
- WebappClassLoader：各个Webapp私有的类加载器，加载路径中的class只对当前Webapp可见，比如加载war包里相关的类，每个war包应用都有自己的
从图中的委派关系中可以看出：
- CommonClassLoader能加载的类都可以被CatalinaClassLoader和SharedClassLoader使用，
从而实现了公有类库的共用，而CatalinaClassLoader和SharedClassLoader自己能加载的类则
与对方相互隔离。
- WebAppClassLoader可以使用SharedClassLoader加载到的类，但各个WebAppClassLoader
实例之间相互隔离
- JasperLoader的加载范围仅仅是这个JSP文件所编译出来的那一个.Class文件，它出现的目的
就是为了被丢弃，当Web容器检测到JSP文件被修改时，会替换掉目前的JasperLoader的实例，
并通过再建立一个新的Jsp类加载器来实现JSP文件的热加载功能
