文章目录
1.类加载的时机
如果类没有进行过初始化，则需要先触发其初始化。虚拟机规范则是严格规定了有且只有5种情况必须立即对类进行“初始化”（而加载、验证、准备自然需要在此之前开始）：
- 创建类的实例(new 的方式)。访问某个类或接口的静态变量，或者对该静态变量赋值，调用类的静态方法（类.xxx调用）
- 反射的方式
- 初始化某个类的子类，则其父类也会被初始化
- Java虚拟机启动时被标明为启动类的类，直接使用java.exe命令来运行某个主类（包含main方法的那个类）
- 当使用JDK1.7的动态语言支持时
2.类的生命周期
类的生命周期包括7个阶段：加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸载（Unloading）。其中验证、准备、解析3个部分统称为连接（Linking）。
解析阶段在某些情况下可以在初始化阶段之后再开始，这是为了支持Java语言的运行时绑定（也称为动态绑定或晚期绑定）。
（了解）接下来我们详细讲解一下Java虚拟机中类加载的全过程，也就是加载、验证、准备、解析和初始化这5个阶段所执行的具体动作。
2.1加载
- 通过一个类的全限定名来获取定义此类的二进制字节流。
- 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
- 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。
2.2验证
这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。
2.3准备
准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配。
假设一个类变量的定义为：
public static int value=123;
那变量value在准备阶段过后的初始值为0而不是123，因为这时候尚未开始执行任何Java方法，而把value赋值为123的putstatic指令是程序被编译后，存放于类构造器()方法之中，所以把value赋值为123的动作将在初始化阶段才会执行。
2.4解析
虚拟机将常量池内的符号引用替换为直接引用的过程。
- 符号引用：符号引用与虚拟机实现的内存布局无关，引用的目标并不一定已经加载到内存中。
- 直接引用：直接引用是和虚拟机实现的内存布局相关的。如果有了直接引用，那引用的目标必定已经在内存中存在。
2.5初始化
在准备阶段，变量已经赋过一次系统要求的初始值，而在初始化阶段，则根据程序员通过程序制定的主观计划去初始化类变量和其他资源，或者可以从另外一个角度来表达：初始化阶段是执行类构造器<clinit>()方法的过程。
- <clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块（static{}块）中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序所决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访问：
public class Test{
static{
i=0; //给变量赋值可以正常编译通过
System.out.print(i); //这句编译器会提示"非法向前引用"
}
static int i=1；
}
-
<clinit>()方法与类的构造函数（或者说实例构造器<init>()方法）不同，它不需要显式地调用父类构造器，虚拟机会保证在子类的<init>()方法执行之前，父类的 <clinit>()方法已经执行完毕。因此在虚拟机中第一个被执行的<clinit>()方法的类肯定是java.lang.Object。
-
<clinit>()方法对于类或接口来说并不是必需的，如果一个类中没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类生成<clinit>()方法。
-
接口中定义的变量使用时，接口才会初始化：接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此接口与类一样都会生<clinit>()方法。但接口与类不同的是，执行接口的<clinit>()方法不需要先执行父接口的<clinit>()方法。只有当父接口中定义的变量使用时，父接口才会初始化。另外，接口的实现类在初始化时也一样不会执行接口的<clinit>()方法。
-
虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确地加锁、同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的<clinit>()方法，其他线程都需要阻塞等待，直到活动线程执行<clinit>()方法完毕。如果在一个类的<clinit>()方法中有耗时很长的操作，就可能造成多个进程阻塞，在实际应用中这种阻塞往往是很隐蔽的。
3.类加载器
类加载器可以分为：启动类加载器、扩展类加载器、应用程序类加载器、自定义类加载器。他们的关系一般如下：
3.1启动类加载器（Bootstrap ClassLoader）
这个类将器负责将存放在<JAVA_HOME>\lib目录中的，或者被-Xbootclasspath参数所指定的路径中的，并且是虚拟机识别的（仅按照文件名识别，如rt.jar，名字不符合的类库即使放在lib目录中也不会被加载）类库加载到虚拟机内存中。
启动类加载器无法被Java程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给引导类加载器，那直接使用null指定父类加载器即可：
public class MyClassLoader extends ClassLoader{
protected MyClassLoader(ClassLoader parent) {
super(parent);
}
// 使用ClassLoader父类的构造方法：根据ClassLoader中loadClass可以知道，设置父类加载器为null会使用Bootstrap ClassLoader来加载
protected MyClassLoader() {
this(null);
}
}
3.2扩展类加载器（Extension ClassLoader）
这个加载器由sun.misc.Launcher $ExtClassLoader实现，它负责加载<JAVA_HOME>\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器。
3.3应用程序类加载器（Application ClassLoader）
这个类加载器由sun.misc.Launcher $App-ClassLoader实现。由于这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值，所以一般也称它为系统类加载器。它负责加载用户类路径（ClassPath）上所指定的类库，开发者可以直接使用这个类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。
4.类加载机制：双亲委派机制
4.1工作过程
双亲委派模型的工作过程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。
使用双亲委派模型来组织类加载器之间的关系，有一个显而易见的好处就是Java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object，它存放在rt.jar之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。相反，如果没有使用双亲委派模型，由各个类加载器自行去加载的话，如果用户自己编写了一个称为java.lang.Object的类，并放在程序的ClassPath中，那系统中将会出现多个不同的Object类，Java类型体系中最基础的行为也就无法保证，应用程序也将会变得一片混乱。
双亲委派模型对于保证Java程序的稳定运作很重要，但它的实现却非常简单，实现双亲委派的代码都集中在java.lang.ClassLoader的loadClass()方法之中，逻辑清晰易懂：先检查是否已经被加载过，若没有加载则调用父加载器的loadClass()方法，若父加载器为空则默认使用启动类加载器作为父加载器。如果父类加载失败，抛出ClassNotFoundException异常后，再调用自己的findClass()方法进行加载。
以下为ClassLoader中的代码：
// The parent class loader for delegation
// Note: VM hardcoded the offset of this field, thus all new fields
// must be added *after* it.
// 父类加载器
private final ClassLoader parent;
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 {
// 父类加载器加载，如果父类加载器为空，使用最顶级的Bootstrap类加载器来加载
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.
// 如果以上步骤还没找到类，就按照自己定义的类加载器中重写的findClass方法加载
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;
}
}
双亲委派的具体逻辑就实现在这个方法之中，JDK1.2之后已不提倡用户再去覆盖loadClass()方法，而应当把自己的类加载逻辑写到findClass()方法中，在loadClass()方法的逻辑里如果父类加载失败，则会调用自己的findClass()方法来完成加载，这样就可以保证新写出来的类加载器是符合双亲委派规则的。
重写loadClass()：不遵循双亲委派机制，按照自己的方式加载。
重写findClass()：遵循双亲委派机制，只有父类找不到时，才按照自己的方式加载。
4.2观察类加载器的加载顺序
先定义一个java.lang.String
package java.lang;
public class String {
public String(String string) {
System.out.println("自定义的java.lang.String类");
}
}
再定义一个Person类
public class Person{}
我们可以使用自定义的类加载器来加载以上两个类：
import java.io.ByteArrayOutputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.InputStream;
import java.net.URL;
import java.net.URLDecoder;
public class Main {
public static void main(String[] args) throws Exception{
// 父加载器为空，使用Bootstrap ClassLoader加载
System.out.println(new MyClassLoader(null).getParent());//null
// 无参构造方法，会使用AppClassLoader作为父类加载器
System.out.println(new MyClassLoader());
System.out.println(new MyClassLoader().getParent());//App
System.out.println(new MyClassLoader().getParent().getParent());//Ext
System.out.println(new MyClassLoader().getParent().getParent().getParent());//null
// 父加载器默认为AppClassLoader，使用loadClass方法加载类，从上往下加载
Class<?> cls = new MyClassLoader().loadClass("Person");
// 使用loadClass遵循双亲委派机制从上往下加载，会加载到jdk的String
Class<?> stringClazz = new MyClassLoader().loadClass("java.lang.String");
String abc = (String) stringClazz.getConstructor(String.class)
.newInstance("ABC");
System.out.println(abc);
//出现异常：不能自定义java.开头的包
Class<?> stringClazz2 = new MyClassLoader().findClass("java.lang.String");
}
}
class MyClassLoader extends ClassLoader{
protected MyClassLoader(ClassLoader parent) {
super(parent);
}
protected MyClassLoader() {
super();
}
/**
* 通过指定的文件路路径进行类的文件加载，实际上就是进行二进制文件读取
* @return 类文件数据
* @throws Exception
*/
private byte[] loadClassData(String className) throws Exception {
URL target = getClass().getClassLoader().getResource(".");
String path = URLDecoder.decode(target.getPath(), "UTF-8");
InputStream input = new FileInputStream(
path + File.separator + className + ".class");
// 取得所有字节内容，放到内存中
ByteArrayOutputStream bos = new ByteArrayOutputStream();
// 读取缓冲区
byte[] data = new byte[20];
int temp = 0;
while ((temp = input.read(data))!=-1){
bos.write(data,0,temp);
}
byte[] result = bos.toByteArray();
input.close();
bos.close();
return result;
}
/**
* 重写findClass表示遵循双亲委派模型，因为类的加载还是通过loadClass方法进入的
* @param name
* @return
* @throws ClassNotFoundException
*/
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
try {
byte[] classData = this.loadClassData(name.replaceAll("\\.", "/"));
return super.defineClass(name, classData,0, classData.length);
} catch (Exception e) {
throw new ClassNotFoundException();
}
}
}
类加载器给⽤用户提供最⼤大的帮助为：可以通过动态的路径进行类的加载操作。
比较两个类相等的前提：必须是由同一个类加载器加载的前提下才有意义。否则，即使两个类来源于同一个Class文件，被同一个虚拟机加载，只要加载他们的类加载器不同，那么这两个类注定不相等。
类加载相关问题
能否自定义类加载器加载自定义的java.lang.Object类?
答：遵循双亲委派机制的类加载，是不会加载到自定义的java.lang.Object类，如果是不遵循双亲委派机制的加载，类加载会效验，不允许java.开头的类进行加载。
jdk如何保证一定是调用jdk提供给的java.lang.Object类？
答：双亲委派机制。
扩展阅读：《深入Java虚拟机》
9.2.1 Tomcat：正统的类加载器架构
9.2.2 OSGI：灵活的类加载器架构
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
