类加载器

1、类加载的顺序

1、类加载机制

     当系统运行时，类加载器将.class文件的二进制数据从外部存储器（如光盘，硬盘）调入内存中，CPU再从内存中读取指令和数据进行运算，并将运算结果存入内存中。

     将class文件字节码内容加载到内存中，并将这些静态数据转换成方法区中的运行时数据结构，在堆中生成一个代表这个类的java.lang.Class对象，用来封装类位于方法区内的数据结构。每个类都对应有一个Class类型的对象，Class类的构造方法是私有的，只有JVM能够创建。因此Class对象是反射的入口。使用该对象就可以获得目标类所关联的.class文件中具体的数据结构。这个过程需要类加载器参与。

     类加载的最终产物就是位于堆中的Class对象，该对象封装了类在方法区中的数据结构，并且向用户提供了访问方法区数据结构的接口，即Java反射的接口。

     

2、连接过程

     将java类的二进制代码合并到JVM的运行状态之中的过程

1. 验证：确保加载的类信息符合JVM规范，没有安全方面的问题
2. 准备：正式为类变量（static变量）分配内存并设置类变量初始值的阶段，这些内存都将在方法区中进行分配
3. 解析：虚拟机常量池的符号引用替换为字节引用过程

3、初始化

     初始化阶段是执行类构造器<clinit>（）方法的过程。类构造器<clinit>（）方法是由编译器自动收藏类中的所有类变量的赋值动作和静态语句块(static块)中的语句合并产生，代码从上往下执行。当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。虚拟机会保证一个类的<clinit>（）方法在多线程环境中被正确加锁和同步

2、类加载器的层次结构

启动（Bootstrap）类加载器

扩展（Extension）类加载器

系统（System）类加载器

启动（Bootstrap）类加载器

      启动类加载器主要加载的是JVM自身需要的类，这个类加载使用C++语言实现的，是虚拟机自身的一部分，它负责将 <JAVA_HOME>/lib路径下的核心类库或-Xbootclasspath参数指定的路径下的jar包加载到内存中，由于虚拟机是按照文件名识别加载jar包的，如rt.jar，如果文件名不被虚拟机识别，即使把jar包丢到lib目录下也是没有作用的(出于安全考虑，Bootstrap启动类加载器只加载包名为java、javax、sun等开头的类)。

扩展（Extension）类加载器

        扩展类加载器是指Sun公司实现的sun.misc.Launcher$ExtClassLoader类，由Java语言实现的,是Launcher的静态内部类，它负责加载<JAVA_HOME>/lib/ext目录下或者由系统变量-Djava.ext.dir指定位路径中的类库，开发者可以直接使用标准扩展类加载器。

系统（System）类加载器、

       也称应用程序加载器是指 Sun公司实现的sun.misc.Launcher$AppClassLoader。它负责加载系统类路径java -classpath或-D java.class.path 指定路径下的类库，也就是我们经常用到的classpath路径，开发者可以直接使用系统类加载器，一般情况下该类加载是程序中默认的类加载器，通过ClassLoader#getSystemClassLoader()方法可以获取到该类加载器。

　 在必要时，我们还可以自定义类加载器，需要注意的是，Java虚拟机对class文件采用的是按需加载的方式，也就是说当需要使用该类时才会将它的class文件加载到内存生成class对象，而且加载某个类的class文件时，Java虚拟机采用的是双亲委派模式即把请求交由父类处理。

3、理解双亲委派模式

       双亲委派模式是在Java 1.2后引入的，其工作原理的是，如果一个类加载器收到了类加载请求，它并不会自己先去加载，而是把这个请求委托给父类的加载器去执行，如果父类加载器还存在其父类加载器，则进一步向上委托，依次递归，请求最终将到达顶层的启动类加载器，如果父类加载器可以完成类加载任务，就成功返回，倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载，这就是双亲委派模式，即每个儿子都很懒，每次有活就丢给父亲去干，直到父亲说这件事我也干不了时，儿子自己想办法去完成

4、双亲委派模式优势

      采用双亲委派模式的是好处是Java类随着它的类加载器一起具备了一种带有优先级的层次关系，通过这种层级关系可以避免类的重复加载，当父亲已经加载了该类时，就没有必要子ClassLoader再加载一次。其次是考虑到安全因素，java核心api中定义类型不会被随意替换，假设通过网络传递一个名为java.lang.Integer的类，通过双亲委托模式传递到启动类加载器，而启动类加载器在核心Java API发现这个名字的类，发现该类已被加载，并不会重新加载网络传递的过来的java.lang.Integer，而直接返回已加载过的Integer.class，这样便可以防止核心API库被随意篡改。可能你会想，如果我们在classpath路径下自定义一个名为java.lang.SingleInterge类(该类是胡编的)呢？该类并不存在java.lang中，经过双亲委托模式，传递到启动类加载器中，由于父类加载器路径下并没有该类，所以不会加载，将反向委托给子类加载器加载，最终会通过系统类加载器加载该类。但是这样做是不允许，因为java.lang是核心API包，需要访问权限，强制加载将会报出如下异常

java.lang.SecurityException: Prohibited package name: java.lang

5、类加载器间的关系

启动类加载器，由C++实现，没有父类。

拓展类加载器(ExtClassLoader)，由Java语言实现，父类加载器为null

系统类加载器(AppClassLoader)，由Java语言实现，父类加载器为ExtClassLoader

自定义类加载器，父类加载器肯定为AppClassLoader

6、类加载器常用方法

loadClass(String)

       该方法加载指定名称（包括包名）的二进制类型，该方法在JDK1.2之后不再建议用户重写但用户可以直接调用该方法，loadClass()方法是ClassLoader类自己实现的，该方法中的逻辑就是双亲委派模式的实现。正如loadClass方法所展示的，当类加载请求到来时，先从缓存中查找该类对象，如果存在直接返回，如果不存在则交给该类加载去的父加载器去加载，倘若没有父加载则交给顶级启动类加载器去加载，最后倘若仍没有找到，则使用findClass()方法去加载。从loadClass实现也可以知道如果不想重新定义加载类的规则，也没有复杂的逻辑，只想在运行时加载自己指定的类，那么我们可以直接使用this.getClass().getClassLoder.loadClass("className")，这样就可以直接调用ClassLoader的loadClass方法获取到class对象。

findClass(String)

       在JDK1.2之前，在自定义类加载时，总会去继承ClassLoader类并重写loadClass方法，从而实现自定义的类加载类，但是在JDK1.2之后已不再建议用户去覆盖loadClass()方法，而是建议把自定义的类加载逻辑写在findClass()方法中，从前面的分析可知，findClass()方法是在loadClass()方法中被调用的，当loadClass()方法中父加载器加载失败后，则会调用自己的findClass()方法来完成类加载，这样就可以保证自定义的类加载器也符合双亲委托模式。需要注意的是ClassLoader类中并没有实现findClass()方法的具体代码逻辑，取而代之的是抛出ClassNotFoundException异常，同时应该知道的是findClass方法通常是和defineClass方法一起使用的

defineClass(byte[] b, int off, int len)

       defineClass()方法是用来将byte字节流解析成JVM能够识别的Class对象(ClassLoader中已实现该方法逻辑)，通过这个方法不仅能够通过class文件实例化class对象，也可以通过其他方式实例化class对象，如通过网络接收一个类的字节码，然后转换为byte字节流创建对应的Class对象，defineClass()方法通常与findClass()方法一起使用，一般情况下，在自定义类加载器时，会直接覆盖ClassLoader的findClass()方法并编写加载规则，取得要加载类的字节码后转换成流，然后调用defineClass()方法生成类的Class对象

resolveClass(Class<T>c)

      使用该方法可以使用类的Class对象创建完成也同时被解析。前面我们说链接阶段主要是对字节码进行验证，为类变量分配内存并设置初始值同时将字节码文件中的符号引用转换为直接引用

7、热部署的原理是什么

       首先通过java编译器，将java文件编译成class字节码，类加载器读取class字节码，再将类转化为实例，也就是将class字节码转换到类的实例。在java应用中，所有的实例都是由类加载器加载而来。一般在系统中，类的加载都是由系统自带的类加载器完成，而且对于同一个全限定名的java类，只能被加载一次，而且无法被卸载。这个时候问题就来了，如果我们希望将java类卸载，并且替换更新版本的java类。既然在类加载器中，java类只能被加载一次，并且无法卸载。那是不是可以直接把类加载器给换了？答案是可以的，我们可以自定义类加载器，并重写ClassLoader的findClass方法。想要实现热部署可以分以下三个步骤：

1. 销毁该自定义ClassLoader
2. 更新class类文件
3. 创建新的ClassLoader去加载更新后的class类文件

8、热部署与热加载

Java热部署与热加载的联系：

1. 不重启服务器编译/部署项目
2. 基于Java的类加载器实现

Java热部署与热加载的区别：

1. 部署方式：热部署在服务器运行时重新部署项目，热加载在运行时重新加载class
2. 实现原理：热部署直接重新加载整个应用，热加载在运行时重新加载class
3. 使用场景：热部署更多的是在生产环境使用，热加载则更多的实在开发环境使用

字节码技术（了解）

9、字节码技术应用场景

      AOP技术、Lombok去除重复代码插件（耗内存性能差）、动态修改class文件等

10、字节技术优势

      Java字节码增强指的是在Java字节码生成之后，对其进行修改，增强其功能，这种方式相当于对应用程序的二进制文件进行修改。Java字节码增强主要是为了减少冗余代码，提高性能等。

实现字节码增强的主要步骤为： 

修改字节码：在内存中获取到原来的字节码，然后通过一些工具（如 ASM，Javaasist）来修改它的byte[]数组，得到一个新的byte数组。

使修改后的字节码生效：

1. 自定义ClassLoader来加载修改后的字节码
2. 替换掉原来的字节码：在JVM加载用户的Class时，拦截并返回修改后的字节码；或者在运行时，使用Instrumentation.redefineClasses方法来替换掉原来的字节码

11、常见的字节码操作类库

BCEL

Byte Code Engineering Library(BCEL)，这是Apache Software Foundation的Jakarta项目的一部分。BCEL是Java classworking 广泛使用的一种框架，它可以让您深入jvm汇编语言进行类库操作的细节。BCEL与javassist有不同的处理字节码方法，BCEL在实际的jvm指令层次上进行操作(BCEL拥有丰富的jvm指令集支持) 而javassist所强调的是源代码级别的工作。

ASM

是一个轻量级Java字节码操作框架，直接涉及到JVM底层的操作和指令高性能，高质量

CGLIB

生成类库，基于ASM实现

Javassist

是一个开源的分析，编辑和创建Java字节码的类库。性能较ASM差，跟cglib差不多，但是使用简单。很多开源框架都在使用它。

12、Javassist优势

javassist性能高于反射，低于ASM

运行时操作字节码可以让我们实现如下功能：

1. 动态生成新的类
2. 动态改变某个类的结构 ( 添加 / 删除 / 修改    新的属性 / 方法 )

javassist的最外层的API和JAVA的反射包中的API颇为类似。 主要由CtClass，CtMethod以及CtField几个类组成。用以执行和JDK反射API中java.lang.Class， java.lang.reflect.Method，java.lang.reflect.Method .Field相同的操作。

13、javassist的局限性

JDK5.0 新语法不支持 ( 包括泛型、枚举 ) ，不支持注解修改，但可以通过底层的 javassist 类来解决
不支持数组的初始化，如 String[]{"1","2"} ，除非只有数组的容量为1
不支持内部类和匿名类
不支持 continue 和 break表达式。
对于继承关系，有些不支持。例如
class A {}  
class B extends A {} 
class C extends B {}