深入分析ClassLoader工作机制

结合资料，自己的一些理解，分析JVM的类加载器工作机制。

1.java类的加载机制

1.1 .什么是类的加载

类的加载指的是将类的.class文件中的二进制数据读入到内存中，将其放在运行时数据区的方法区内，然后在堆区创建一个java.lang.Class对象，用来封装类在方法区内的数据结构。类的加载的最终产品是位于堆区中的Class对象，Class对象封装了类在方法区内的数据结构，并且向Java程序员提供了访问方法区内的数据结构的接口。

wps5F9E.tmp

类加载器并不需要等到某个类被“首次主动使用”时再加载它，JVM规范允许类加载器在预料某个类将要被使用时就预先加载它，如果在预先加载的过程中遇到了.class文件缺失或存在错误，类加载器必须在程序首次主动使用该类时才报告错误（LinkageError错误）如果这个类一直没有被程序主动使用，那么类加载器就不会报告错误。

加载.class文件的方式有：

从本地系统中直接加载
通过网络下载.class文件
从zip，jar等归档文件中加载.class文件
从专有数据库中提取.class文件
将Java源文件动态编译为.class文件

1.2.类的生命周期

wps257C.tmp

其中类加载的过程包括了加载、验证、准备、解析、初始化五个阶段。在这五个阶段中，加载、验证、准备和初始化这四个阶段发生的顺序是确定的，而解析阶段则不一定，它在某些情况下可以在初始化阶段之后开始，这是为了支持Java语言的运行时绑定（也成为动态绑定或晚期绑定）。另外注意这里的几个阶段是按顺序开始，而不是按顺序进行或完成，因为这些阶段通常都是互相交叉地混合进行的，通常在一个阶段执行的过程中调用或激活另一个阶段。

Java中的绑定：绑定指的是把一个方法的调用与方法所在的类(方法主体)关联起来，对java来说，绑定分为静态绑定和动态绑定：

静态绑定：即前期绑定。在程序执行前方法已经被绑定，此时由编译器或其它连接程序实现。针对java，简单的可以理解为程序编译期的绑定。java当中的方法只有final，static，private和构造方法是前期绑定的。
动态绑定：即晚期绑定，也叫运行时绑定。在运行时根据具体对象的类型进行绑定。在java中，几乎所有的方法都是后期绑定的。

一. 加载：

查找并加载类的二进制数据

加载时类加载过程的第一个阶段，在加载阶段，虚拟机需要完成以下三件事情：

1.   通过一个类的全限定名来获取其定义的二进制字节流。
2.   将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
3.   在Java堆中生成一个代表这个类的java.lang.Class对象，作为对方法区中这些数据的访问入口。

相对于类加载的其他阶段而言，加载阶段（准确地说，是加载阶段获取类的二进制字节流的动作）是可控性最强的阶段，因为开发人员既可以使用系统提供的类加载器来完成加载，也可以自定义自己的类加载器来完成加载。

加载阶段完成后，虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区之中，而且在Java堆中也创建一个java.lang.Class类的对象，这样便可以通过该对象访问方法区中的这些数据。

二.连接:

验证：确保被加载的类的正确性

验证是连接阶段的第一步，这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。验证阶段大致会完成4个阶段的检验动作：

文件格式验证：验证字节流是否符合Class文件格式的规范；例如：是否以0xCAFEBABE开头、主次版本号是否在当前虚拟机的处理范围之内、常量池中的常量是否有不被支持的类型。

元数据验证：对字节码描述的信息进行语义分析（注意：对比javac编译阶段的语义分析），以保证其描述的信息符合Java语言规范的要求；例如：这个类是否有父类，除了java.lang.Object之外。

字节码验证：通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。

符号引用验证：确保解析动作能正确执行。

验证阶段是非常重要的，但不是必须的，它对程序运行期没有影响，如果所引用的类经过反复验证，那么可以考虑采用-Xverifynone参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。

准备：为类的静态变量分配内存，并将其初始化为默认值
准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些内存都将在方法区中分配。对于该阶段有以下几点需要注意：

这时候进行内存分配的仅包括类变量（static即静态变量），而不包括实例变量，实例变量会在对象实例化时随着对象一块分配在Java堆中。
这里所设置的初始值通常情况下是数据类型默认的零值（如0、0L、null、false等），而不是被在Java代码中被显式地赋予的值。

举例： 假设一个类变量的定义为：public static int value = 3；

那么变量value在准备阶段过后的初始值为0，而不是3，因为这时候尚未开始执行任何Java方法，而把value赋值为3的putstatic指令是在程序编译后，存放于类构造器 （）方法之中的，所以把value赋值为3的动作将在初始化阶段才会执行。

注意：
1. 这里还需要注意如下几点：
2. 对基本数据类型来说，对于类变量（static）和全局变量，如果不显式地对其赋值而直接使用，则系统会为其赋予默认的零值，而对于局部变量来说，在使用前必须显式地为其赋值，否则编译时不通过。
3. 对于同时被static和final修饰的常量，必须在声明的时候就为其显式地赋值，否则编译时不通过；而只被final修饰的常量则既可以在声明时显式地为其赋值，也可以在类初始化时显式地为其赋值，总之，在使用前必须为其显式地赋值，系统不会为其赋予默认零值。
4. 对于引用数据类型reference来说，如数组引用、对象引用等，如果没有对其进行显式地赋值而直接使用，系统都会为其赋予默认的零值，即null。
5. 如果在数组初始化时没有对数组中的各元素赋值，那么其中的元素将根据对应的数据类型而被赋予默认的零值。
如果类字段的字段属性表中存在ConstantValue属性，即同时被final和static修饰，那么在准备阶段变量value就会被初始化为ConstValue属性所指定的值。

假设上面的类变量value被定义为： public static final int value = 3；

编译时Javac将会为value生成ConstantValue属性，在准备阶段虚拟机就会根据ConstantValue的设置将value赋值为3。回忆上一篇博文中对象被动引用的第2个例子，便是这种情况。我们可以理解为static final常量在编译期就将其结果放入了调用它的类的常量池中
1. 如果常量引用的是一个固定值，那么加不加static的效果是一样的，除非声明为public的公共常量，需要加上static，可以直接调用。
2. 如果常量引用的是一个函数，或者其他对象的赋值，那么就必须加上static了，要不，你就为莫名其妙的错误而头大了。
  
  final修饰的变量一旦初始化就不能被改变，但每次创建对象都会被初始化。
  static final修饰的变量只能被初始化一次，而且一旦初始化就不能被改变。
  
  所以在声明常量时，static+final可以更加保险，避免出现不必要的问题。

解析： 把类中的符号引用转换为直接引用
解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程，解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行。符号引用就是一组符号来描述目标，可以是任何字面量。

直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。

三.初始化

初始化，为类的静态变量赋予正确的初始值，JVM负责对类进行初始化，主要对类变量进行初始化。在Java中对类变量进行初始值设定有两种方式：

①声明类变量是指定初始值

②使用静态代码块为类变量指定初始值

JVM初始化步骤:

假如这个类还没有被加载和连接，则程序先加载并连接该类
假如该类的直接父类还没有被初始化，则先初始化其直接父类
假如类中有初始化语句，则系统依次执行这些初始化语句

类初始化时机：只有当对类的主动使用的时候才会导致类的初始化，类的主动使用包括以下六种：

创建类的实例，也就是new的方式
访问某个类或接口的静态变量，或者对该静态变量赋值
调用类的静态方法
反射（如Class.forName(“com.shengsiyuan.Test”)）
初始化某个类的子类，则其父类也会被初始化
Java虚拟机启动时被标明为启动类的类（Java Test），直接使用java.exe命令来运行某个主类

四.结束生命周期

在如下几种情况下，Java虚拟机将结束生命周期

执行了System.exit()方法
程序正常执行结束
程序在执行过程中遇到了异常或错误而异常终止
由于操作系统出现错误而导致Java虚拟机进程终止

2.什么是ClassLoader？

ClassLoader顾名思义就是类加载器。

2.1.作用：

ClassLoader负责将Class加载到JVM中，他就好比开会对门口的接待员，负责给进入会场的不同等级嘉宾发放入会证明。
ClassLoader除了能将Class加载到JVM之中之外，还有一个重要的作用就是审核每个类应该由谁加载，它是一种父优先的等级加载机制。
ClassLoader将Class字节码重新解析成JVM统一要求的对象格式。

2.2.寻找类加载器

先来一个小例子:

package com.neo.classloader;
public class ClassLoaderTest {
     public static void main(String[] args) {
        ClassLoader loader = Thread.currentThread().getContextClassLoader();
        System.out.println(loader);
        System.out.println(loader.getParent());
        System.out.println(loader.getParent().getParent());
    }
}

运行后，输出结果：

1
2
3

sun.misc.Launcher$AppClassLoader@64fef26a
sun.misc.Launcher$ExtClassLoader@1ddd40f3
null

从上面的结果可以看出，并没有获取到ExtClassLoader的父Loader，原因是Bootstrap Loader（引导类加载器）是用C语言实现的，找不到一个确定的返回父Loader的方式，于是就返回null。

这几种类加载器的层次关系如下图所示：

wpsC239.tmp

注意：这里父类加载器并不是通过继承关系来实现的，而是采用组合实现的。

站在Java虚拟机的角度来讲，只存在两种不同的类加载器：启动类加载器：它使用C++实现（这里仅限于Hotspot，也就是JDK1.5之后默认的虚拟机，有很多其他的虚拟机是用Java语言实现的），是虚拟机自身的一部分；所有其他的类加载器：这些类加载器都由Java语言实现，独立于虚拟机之外，并且全部继承自抽象类java.lang.ClassLoader，这些类加载器需要由启动类加载器加载到内存中之后才能去加载其他的类。

站在Java开发人员的角度来看，

2.3.类加载器可以大致划分为以下三类：

启动类加载器：Bootstrap ClassLoader，负责加载存放在JDK\jre\lib(JDK代表JDK的安装目录，下同)下，或被-Xbootclasspath参数指定的路径中的，并且能被虚拟机识别的类库（如rt.jar，所有的java.*开头的类均被Bootstrap ClassLoader加载）。启动类加载器是无法被Java程序直接引用的。(JVM服务自身，独立：无父加载器，也无子加载器)

扩展类加载器：Extension ClassLoader，该加载器由sun.misc.Launcher$ExtClassLoader实现，它负责加载DK\jre\lib\ext目录中，或者由java.ext.dirs系统变量指定的路径中的所有类库（如javax.*开头的类），开发者可以直接使用扩展类加载器。（服务jvm员工会员，服务的特定目标在System.getProperty(“java.ext.dirs”）目录下)

应用程序类加载器：Application ClassLoader，该类加载器由sun.misc.Launcher$AppClassLoader来实现，它负责加载用户类路径（ClassPath）所指定的类，开发者可以直接使用该类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。（服务普通会员，所有在System.getProperty(“java.class.path”）目录下的类都可以被这个类加载器加载，这个目录就是我们经常用到的classpath）

应用程序都是由这三种类加载器互相配合进行加载的，如果有必要，我们还可以加入自定义的类加载器（父加载器为AppclassLoader，因为不管调用哪个父类构造器，创建的对象都必须最终调用getSystemClassLoader()作为父加载器。而getSystemClassLoader()方法获取到的正是AppClassLoader）。因为JVM自带的ClassLoader只是懂得从本地文件系统加载标准的java class文件，因此如果编写了自己的ClassLoader，便可以做到如下几点：

在执行非置信代码之前，自动验证数字签名。
动态地创建符合用户特定需要的定制化构建类。
从特定的场所取得java class，例如数据库中和网络中。

2.4.JVM类加载机制

全盘负责，当一个类加载器负责加载某个Class时，该Class所依赖的和引用的其他Class也将由该类加载器负责载入，除非显示使用另外一个类加载器来载入。
父类委托，先让父类加载器试图加载该类，只有在父类加载器无法加载该类时才尝试从自己的类路径中加载该类。
缓存机制，缓存机制将会保证所有加载过的Class都会被缓存，当程序中需要使用某个Class时，类加载器先从缓存区寻找该Class，只有缓存区不存在，系统才会读取该类对应的二进制数据，并将其转换成Class对象，存入缓存区。这就是为什么修改了Class后，必须重启JVM，程序的修改才会生效。

2.5.类加载的三种方式(两类方式)

两类方式：

隐式加载：所谓隐式加载就是不通过在代码里调用ClassLoader来加载需要的类，而是通过JVM来自动加载需要的类到内存的方式。例如，当我们在类中继承或者引用某个类时，JVM在解析这个类时发现引用的类不在内存中，那么就会自动将这些类加载到内存中。
显式加载： 相反的显式加载就是我们在代码中通过调用ClassLoader类来加载个类一个类的方式，例如，调用this.getClass.getClassloader().loadClass()或者 Class.forName(),或者我们自己实现ClassLoader的findClass()方法等。

其实这两种方式是混合使用的，例如，我们通过自定义的ClassLoader显式加载一个类时，这个类中又引用了其他类，那么这些类就是隐式加载的。

常用的三种方式：

命令行启动应用时候由JVM初始化加载(隐式加载)
通过Class.forName()方法动态加载（显式加载）
通过ClassLoader.loadClass()方法动态加载（显式加载）

例子：

package com.neo.classloader;
public class loaderTest { 
        public static void main(String[] args) throws ClassNotFoundException { 
                ClassLoader loader = HelloWorld.class.getClassLoader(); 
                System.out.println(loader); 
                //使用ClassLoader.loadClass()来加载类，不会执行初始化块 
                loader.loadClass("Test2"); 
                //使用Class.forName()来加载类，默认会执行初始化块 
//                Class.forName("Test2"); 
                //使用Class.forName()来加载类，并指定ClassLoader，初始化时不执行静态块 
//                Class.forName("Test2", false, loader); 
        } 
}

demo类：

public class Test2 { 
        static { 
                System.out.println("静态初始化块执行了！"); 
        } 
}

分别切换加载方式，会有不同的输出结果。

Class.forName()和ClassLoader.loadClass()区别：

Class.forName()：将类的.class文件加载到jvm中之外，还会对类进行解释，执行类中的static块；

ClassLoader.loadClass()：只干一件事情，就是将.class文件加载到jvm中，不会执行static中的内容,只有在newInstance才会去执行static块。

注：

Class.forName(name, initialize, loader)带参函数也可控制是否加载static块。并且只有调用了newInstance()方法采用调用构造函数，创建类的对象。

2.6.双亲委派模型

双亲委派模型的工作流程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把请求委托给父加载器去完成，依次向上，因此，所有的类加载请求最终都应该被传递到顶层的启动类加载器中，只有当父加载器在它的搜索范围中没有找到所需的类时，即无法完成该加载，子加载器才会尝试自己去加载该类。

双亲委派机制:

1、当AppClassLoader加载一个class时，它首先不会自己去尝试加载这个类，而是把类加载请求委派给父类加载器ExtClassLoader去完成。

2、当ExtClassLoader加载一个class时，它首先也不会自己去尝试加载这个类，而是把类加载请求委派给BootStrapClassLoader去完成。

3、如果BootStrapClassLoader加载失败（例如在$JAVA_HOME/jre/lib里未查找到该class），会使用ExtClassLoader来尝试加载；

4、若ExtClassLoader也加载失败，则会使用AppClassLoader来加载，如果AppClassLoader也加载失败，则会报出异常ClassNotFoundException。

ClassLoader源码分析：

1
2
3

public Class<?> loadClass(String name) throws ClassNotFoundException {
        return loadClass(name, false);
    }

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 {
                   	//如果不存在父类加载器，就检查是否是由启动类加载器加载的类，通过调用本地方法native Class findBootstrapClass(String name)
                       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;
       }
   }

findClass源码：（jdk 1.8）

由于findClass没有进行实现，所以直接抛出没有找到类的异常。

1
2
3

protected Class<?> findClass(String name) throws ClassNotFoundException {
        throw new ClassNotFoundException(name);
    }

双亲委派模型意义：

系统类防止内存中出现多份同样的字节码
保证Java程序安全稳定运行

JVM在判定两个class是否相同时，不仅要判断两个类名是否相同，而且要判断是否由同一个类加载器实例加载的。只有两者同时满足的情况下，JVM才认为这两个class是相同的。

2.7.ClassLoader类结构分析

我们经常会用到或扩展ClassLoader,主要会用到如图6-1所示的几个方法，以及它们的重载方法。

defineClass方法：defineClass方法用来将byte字节流解析成JVM能够识别的Class对象，有了这个方法意味着我们不仅仅可以通过class文件实例化对象，还可以通过其他方式实例化对象，如我们通过网络接收到一个类的字节码，拿这个字节码流直接创建类的Class对象形式实例化对象。注意，如果直接调用这个方法生成类的Class对象，这个类的Class对象还没有resolve（解析，在Linking时进行，不是固定的）,这个resolve将会在这个对象真正实例化时才进行。

defineClass通常是和findClass方法一起使用的，我们通过直接覆盖ClassLoader父类的findClass方法来实现类的加载规则，从而取得要加载类的字节码。然后调用defineClass方法生成类的Class对象，如果你想在类被加载到JVM中时就被链接(Link),那么可以接着调用另办一个 resolveClass方法(决定什么时候对类进行解析),当然你也可以选择让JVM来解决什么时候才链接这个类。

如果你不想重新定义加载类的规则，也没有复杂的处理逻辑，只想在运行时能够加载自己指定的一个类，那么你可以用 this.getClass().getClassLoader().loadClass(“class”)调用ClassLoader的loadClass方法以获取这个类的Class对象，这个loadClass还有重载方法，你同样可以决定在什么时候解析这个类。

ClassLoader是个抽象类，它还有很多子类,我们如果要实现自己的ClassLoader，一般都会继承URLClassLoader这个字类，因为这个类已经帮我们实现了大部分工作，我们只需要在适当的地方做些修改就好了，就像我们要实现Servlet时通常会直接继HttpServlet —样。

前面介绍的这几个方法都是我们在扩展ClassLoader时需要用到的，ClassLoader 还提供了另外一些辅助方法，如获取 class 文件的法 getResource ,getResourceAsStream 等，还有就是获取SystemClassLoader的方法等。

2.8.自定义类加载器

通常情况下，我们都是直接使用系统类加载器。但是，有的时候，我们也需要自定义类加载器。比如应用是通过网络来传输 Java 类的字节码，为保证安全性，这些字节码经过了加密处理，这时系统类加载器就无法对其进行加载，这样则需要自定义类加载器来实现。自定义类加载器一般都是继承自 ClassLoader 类，从上面对 loadClass 方法来分析来看，我们只需要重写 findClass 方法即可（在上面源码已经说明，在loadClass中未找到类最后会调用findClass方法）。下面我们通过一个示例来演示自定义类加载器的流程：

package com.neo.classloader;

import java.io.*;


public class MyClassLoader extends ClassLoader {

    private String root;

    protected Class<?> findClass(String name) throws ClassNotFoundException {
        byte[] classData = loadClassData(name);
        if (classData == null) {
            throw new ClassNotFoundException();
        } else {
            return defineClass(name, classData, 0, classData.length);
        }
    }

    private byte[] loadClassData(String className) {
        String fileName = root + File.separatorChar
                + className.replace('.', File.separatorChar) + ".class";
        try {
            InputStream ins = new FileInputStream(fileName);
            ByteArrayOutputStream baos = new ByteArrayOutputStream();
            int bufferSize = 1024;
            byte[] buffer = new byte[bufferSize];
            int length = 0;
            while ((length = ins.read(buffer)) != -1) {
                baos.write(buffer, 0, length);
            }
            return baos.toByteArray();
        } catch (IOException e) {
            e.printStackTrace();
        }
        return null;
    }

    public String getRoot() {
        return root;
    }

    public void setRoot(String root) {
        this.root = root;
    }

    public static void main(String[] args)  {

        MyClassLoader classLoader = new MyClassLoader();
        classLoader.setRoot("E:\\temp");

        Class<?> testClass = null;
        try {
            testClass = classLoader.loadClass("com.neo.classloader.Test2");
            Object object = testClass.newInstance();
            System.out.println(object.getClass().getClassLoader());
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        } catch (InstantiationException e) {
            e.printStackTrace();
        } catch (IllegalAccessException e) {
            e.printStackTrace();
        }
    }
}

自定义类加载器的核心在于对字节码文件的获取，如果是加密的字节码则需要在该类中对文件进行解密。由于这里只是演示，我并未对class文件进行加密，因此没有解密的过程。这里有几点需要注意：

这里传递的文件名需要是类的全限定性名称，即com.paddx.test.classloading.Test格式的，因为 defineClass 方法是按这种格式进行处理的。
最好不要重写loadClass方法，因为这样容易破坏双亲委托模式。
这类Test 类本身可以被 AppClassLoader 类加载，因此我们不能把 com/paddx/test/classloading/Test.class 放在类路径下。否则，由于双亲委托机制的存在，会直接导致该类由AppClassLoader 加载，而不会通过我们自定义类加载器来加载。

2.9.常见加载类错误分析

ClassNotFoundExecption

ClassNotFoundExecption 异常是平常碰到的最多的。这个异常通常发生在显式加载类的时候。

public class ClassNotFoundExceptionTest
{
    public static void main(String[] args) {
        try {
            Class.forName("NotFoundClass");
        }catch (ClassNotFoundException e){
            e.printStackTrace();
        }
    }
}

显式加载一个类通常有：

通过类 Class 中的 forName() 方法

通过类 ClassLoader 中的 loadClass() 方法
通过类 ClassLoader 中的 findSystemClass() 方法

出现这种错误其实就是当 JVM 要加载指定文件的字节码到内存时，并没有找到这个文件对应的字节码，也就是这个文件并不存在。解决方法就是检查在当前的 classpath 目录下有没有指定的文件。

NoClassDefFoundError

在JavaDoc中对NoClassDefFoundError的产生可能的情况就是使用new关键字、属性引用某个类、继承了某个接口或者类，以及方法的某个参数中引用了某个类，这时就会触发JVM或者类加载器实例尝试加载类型的定义，但是该定义却没有找到，影响了执行路径。换句话说，在编译时这个类是能够被找到的，但是在执行时却没有找到。

解决这个错误的方法就是确保每个类引用的类都在当前的classpath下面。

UnsatisfiedLinkError

该错误通常是在 JVM 启动的时候，如果 JVM 中的某个 lib 删除了，就有可能报这个错误。

public class UnsatisfiedLinkErrorTest
{
    public native void nativeMethod();
    static {
        System.loadLibrary("NoLib");
    }
    public static void main(String[] args) {
        new UnsatisfiedLinkErrorTest().nativeMethod();  //解析native标识的方法时JVM找不到对应的库文件
    }
}

ClassCastException

该错误通常出现强制类型转换时出现这个错误。

public class ClassCastExceptionTest
{
    public static Map m = new HashMap(){
        {
            put("a", "2");
        }
    };
    public static void main(String[] args) {
        Integer integer = (Integer) m.get("a"); //将m强制转换成Integer类型
        System.out.println(integer);
    }
}

注意：JVM 在做类型转换时的规则：

对于普通对象，对象必须是目标类的实例或目标类的子类的实例。如果目标类是接口，那么会把它当作实现了该接口的一个子类。
对于数组类型，目标类必须是数组类型或 java.lang.Object、java.lang.Cloneable、java.io.Serializable。

如果不满足上面的规则，JVM 就会报错，有两种方式可避免错误：

在容器类型中显式的指明这个容器所包含的对象类型。
先通过 instanceof 检查是不是目标类型，然后再进行强制类型的转换。

ExceptionInInitializerError

public class ExceptionInInitializerErrorTest
{
    public static Map m = new HashMap(){{
        m.put("a", "2");
    }};
    public static void main(String[] args) {
        Integer integer = (Integer) m.get("a");
        System.out.println(integer);
    }
}

在初始化这个类时，给静态属性 m 赋值时出现了异常导致抛出错误 ExceptionInInitializerError。

NoSuchMethodError

NoSuchMethodError代表这个类型确实存在，但是一个不正确的版本被加载了。为了解决这个问题我们可以使用 ‘verbose:class’ 来判断该JVM加载的到底是哪个版本。
LinkageError

有时候事情会变得更糟，和 ClassCastException 本质一样，加载自不同位置的相同类在同一段逻辑（比如：方法）中交互时，会出现 LinkageError 。

LinkageError 需要观察哪个类被不同的类加载器加载了，在哪个方法或者调用处发生（交汇）的，然后才能想解决方法，解决方法无外乎两种。第一，还是不同的类加载器加载，但是相互不再交汇影响，这里需要针对发生问题的地方做一些改动，比如更换实现方式，避免出现上述问题；第二，冲突的类需要由一个Parent类加载器进行加载。LinkageError 和ClassCastException 本质是一样的，加载自不同类加载器的类型，在同一个类的方法或者调用中出现，如果有转型操作那么就会抛 ClassCastException ，如果是直接的方法调用处的参数或者返回值解析，那么就会产生 LinkageError 。

（参考书籍以及博客：

《深入分析javaweb技术内幕》，

博客：http://blog.csdn.net/ns_code/article/details/17881581

博客：https://www.cnblogs.com/ityouknow/p/5603287.html

博客: https://blog.csdn.net/coslay/article/details/40709921

博客：https://segmentfault.com/a/1190000008491597

）

深入分析ClassLoader工作机制

深入分析ClassLoader工作机制

1.java类的加载机制

1.1 .什么是类的加载

1.2.类的生命周期

一. 加载：

二.连接:

验证：确保被加载的类的正确性

准备：为类的静态变量分配内存，并将其初始化为默认值

解析：把类中的符号引用转换为直接引用

三.初始化

四.结束生命周期

2.什么是ClassLoader？

2.1.作用：

2.2.寻找类加载器

2.3.类加载器可以大致划分为以下三类：

2.4.JVM类加载机制

2.5.类加载的三种方式(两类方式)

2.6.双亲委派模型

2.7.ClassLoader类结构分析

2.8.自定义类加载器

2.9.常见加载类错误分析

深入分析ClassLoader工作机制

1.java类的加载机制

1.1 .什么是类的加载

1.2.类的生命周期

一. 加载：

二.连接:

验证：确保被加载的类的正确性

准备：为类的静态变量分配内存，并将其初始化为默认值

解析： 把类中的符号引用转换为直接引用

三.初始化

四.结束生命周期

2.什么是ClassLoader？

2.1.作用：

2.2.寻找类加载器

2.3.类加载器可以大致划分为以下三类：

2.4.JVM类加载机制

2.5.类加载的三种方式(两类方式)

2.6.双亲委派模型

2.7.ClassLoader类结构分析

2.8.自定义类加载器

2.9.常见加载类错误分析

解析：把类中的符号引用转换为直接引用