Java虚拟机为Java程序提供运行时环境，其中一项重要的任务就是管理类和对象的生命周期。类的生命周期从被类被加载、连接和初始化开始，到类被卸载结束。当类处于生命周期中时，它的二进制数据位于方法区内，在堆区内还会有一个相应的描述这个类的Class对象。只有当类处于生命周期中时，Java程序才能使用它，比如调用类的静态属性和方法，或者创建类的实例。
一、Java虚拟机及程序的生命周期
当通过java命令运行一个Java程序时，就启动了一个Java虚拟机进程。Java虚拟机进程从启动到终止的过程，称为Java虚拟机的生命周期。在以下情况下，Java虚拟机将结束生命周期。
（1）程序正常执行结束。
（2）程序在执行中因为出现异常或错误而异常终止。
（3）执行了System.exit()方法。
（4）由于操作系统出现错误而导致Java虚拟机进程终止。
当Java虚拟机处于生命周期中时，它的总任务就是运行Java程序。Java程序从开始运行到终止的过程称为程序的生命周期，它和Java虚拟机的生命周期是一致的。
二、类的加载、连接和初始化
当Java程序需要使用某个类时，Java虚拟机会确保这个类已经被加载、连接和初始化。其中连接过程又包括验证、准备和解析这三个子步骤。这些步骤必须严格地按以下顺序执行。
（1）加载：查找并加载类的二进制数据。
（2）连接：包括验证、准备和解析类的二进制数据。
①验证：确保被加载类的正确性。
②准备：为类的静态变量分配内存，并将其初始化为默认值。
③解析：把类中的符号引用转换为直接引用。
（3）初始化：给类的静态变量赋予正确的初始值。
在类或接口被加载和连接的时机上，Java虚拟机规范给实现提供了一定的灵活性，但是它严格定义了初始化的时机，所有的Java虚拟机实现必须在每个类或接口被Java程序“首次主动使用”时才初始化它们。Java程序对类的使用方式可分为两种：主动使用和被动使用。
1、类的加载
类的加载是指把类的.class文件中的二进制数据读入到内存中，把它存放在运行时数据区的方法区内，然后在堆区创建一个java.lang.Class对象，用来封装类在方法区内的数据结构。
Java虚拟机能够从多种来源加载类的二进制数据，包括：
（1）从本地文件系统中加载类的.class文件，这是最常见的加载方式。
（2）通过网络下载类的.class文件。
（3）从ZIP、JAR或其他类型的归档文件中提取.class文件。
（4）从一个专有数据库中提取.class文件。
（5）把一个Java源文件动态编译为.class文件。
类的加载的最终产品是位于运行时数据区的堆区的Class对象。Class对象封装了类在方法区内的数据结构，并且向Java程序提供了访问类在方法区内的数据结构的接口。
类的加载是由类加载器完成的。类加载器可分为两种：
（1）Java虚拟机自带的加载器，包括启动类加载器、扩展类加载器和系统类加载器。
（2）用户自定义的加载器，是java.lang.ClassLoader类的子类的实例，用户可以通过它来定制类的加载方式。
类加载器并不需要等到某个类被“首次主动使用”时再加载它，Java虚拟机规范允许类加载器在预料到某个类将要被使用时就预先加载它，如果在预先加载过程中遇到.class文件缺失或者存在错误，类加载器必须等到程序首次主动使用该类时才报告错误（抛出一个LinkageError错误）。如果这个类一直没有被使用，那么类加载器将不会报告错误。
2、类的验证
当类被加载后，就进入连接阶段。连接就是把已经读入到内存的类的二进制数据合并到虚拟机的运行时环境中去。
连接的第一步就是类的验证，保证被加载的类有正确的内部结构，并且与其他类协调一致。如果Java虚拟机检查到错误，那么就会抛出相应的Error对象。
之所以要对二进制文件进行验证，是因为这个.class文件可能是由正常的Java编译器生成的，也有可能的是由黑客特制的（黑客试图通过它来破坏虚拟机的运行时环境），类的验证能提高程序的健壮性，确保程序被安全地执行。
类的验证主要包括以下内容：
（1）类文件的结构检查：确保类文件遵从Java类文件的固定格式。
（2）语义检查：确保类本身符合Java语言的语法规定，不如验证final类型的类没有子类，以及final类型的方法没有被覆盖。
（3）字节码验证：确保字节码流可以被Java虚拟机安全地执行。字节码流代表Java方法（包括静态方法和实例方法），它是由被称作操作码的单字节指令组成的序列，每一个操作码后都跟着一个或多个操作数。字节码验证步骤会检查每个操作码是否合法，即是否有着合法的操作数。（这里类似汇编语言）
（4）二进制兼容的验证：确保相互引用的类之间协调一致。例如在Worker类的gotoWork()方法中会调用Car类的run()方法，假如不存在（当Worker类和Car类的版本不兼容，就会出现这种问题），就会抛出NoSuchMethodError错误。
3、类的准备
在准备阶段，Java虚拟机为类的静态变量分配内存，并设置默认的初始值。这里的内存应该是指方法区，静态变量存放在方法区里。
4、类的解析
在解析阶段，Java虚拟机会把类的二进制数据中的符号引用替换为直接引用。例如在Worker类的gotoWork()方法中会引用Car类的run()方法。
public void gotoWork(){
car.run(); //这段代码在Worker类的二进制数据中表示为符号引用
}
在Worker类的二进制数据中，包含了一个对Car类的run()方法的符号引用，它由run()方法的全名和相关描述符组成。在解析阶段，Java虚拟机会把这个符号引用直接替换为一个指针，该指针指向Car类的run()方法在方法区内的内存位置，这个指针就是直接引用。
5、类的初始化
在初始化阶段，Java虚拟机执行类的初始化语句，为类的静态变量赋予初始值。在程序中，静态变量的初始化有两种途径：
（1）在静态变量的声明处进行初始化。
（2）在静态代码块中进行初始化。
ps：在本章中，如果未加特别说明，类的静态变量都是指不能作为编译时常量的静态变量。Java编译器和虚拟机对于编译时常量有着特殊的处理方式。
静态变量的声明语句，以及静态代码块都被看做类的初始化语句，Java虚拟机会按照初始化语句在类文件中的先后顺序来依次执行它们。
Java虚拟机初始化一个类包含以下步骤：
（1）假如这个类还没有被加载和连接，那就先进行加载和连接。
（2）假如类存在直接的父类，并且这个父类还没有被初始化，那就先初始化直接的父类。
（3）假如类中存在初始化语句，那就依次执行这些初始化语句。
当初始化一个类的直接父类时，也需要重复以上步骤，这会确保当程序主动使用一个类时，这个类及所有父类（包括直接父类和间接父类）都已经被初始化。程序中第一个被初始化的类是Object类。
6、类的初始化的时机
Java虚拟机只有在程序首次主动使用一个类或接口时才会初始化它。
只有六种活动被看做是程序对类或接口的主动使用：
（1）创建一个类的实例。创建类的实例的途径包括：用new语句创建实例，或者通过反射、克隆及反序列化手段来创建实例。
（2）调用类的静态方法。
（3）访问某个类或接口的静态变量，或者对该静态变量赋值。
（4）调用Java API中某些反射方法，比如调用Class.forName("Worker")方法，假如Worker类还没有被初始化，那么forName()方法就会初始化Worker类，然后返回代表这个Worker类的Class实例。forName()方法是java.lang.Class类的静态方法。
（5）初始化一个类的子类。例如对Sub类的初始化，可看做是对它父类Base类的主动使用，因此会先初始化Base类。
（6）Java虚拟机启动时被标明为启动类的类。例如对于“java Sample"命令，Sample类就是启动类，Java虚拟机会先初始化它。
除了上述6中情况，其他使用Java类的方式都被看作是被动使用，都不会导致类的初始化。
下面结合具体的例子来解释类的初始化时机。
（1）对于final类型的静态变量，如果在编译时就能计算出变量的取值，那么这种变量被看做编译时常量。Java程序中对类的编译时常量的使用，被看做是对类的被动使用，不会导致类的初始化。例如：
public static final int a=3*2;//变量a是编译时常量 public static final int b=(int)(Math.random()*5);//变量b不是编译时常量
这样做的原因是：当Java编译器在编译这段代码生成.class文件的时候，它不会再字节码中保存关于这个编译时常量a的符号引用，而是直接在字节码流中嵌入常量值6，也就是说所有在用到这个编译时常量的地方在编译的时候直接被替换成了常量6。因此当程序访问到这个编译时常量的时候，客观上，无须初始化这个类。所以，当Java虚拟机加载并连接这个类时，不会在方法区内为它的编译时常量a分配内存。
（2）对于final类型的静态变量，如果在编译时不能计算出变量的取值，那么程序对类的这种变量的使用，被看作是对类的主动使用，会导致类的初始化。前面的变量b就是这种变量，当访问到这个变量的时候，Java虚拟机会初始化这个变量所在的类，使得变量b在方法区内拥有特定的内存和初始值。
（3）当Java虚拟机初始化一个类时，要求它的所有父类都已经被初始化，但是这条规则并不适用于接口。
①在初始化一个类时，并不会先初始化它实现的接口。
②在初始化一个接口时，并不会先初始化它的父接口。
因此，一个父接口并不会因为它的子接口或者实现类的初始化而初始化。只有当程序首次使用特定接口的静态变量时，才会导致该接口的初始化。
（4）只有当程序访问的静态变量或静态方法的确在当前类或接口中定义时，才可看作是对类或接口的主动使用。这里解释一下，当父类中定义了某个静态变量或者静态方法后，其他类可以用该父类的子类名访问该静态变量或者静态方法，这时候只会初始化父类，而不会初始化子类。
（5）调用ClassLoader类的loadClass()方法加载一个类，并不是对类的主动使用，不会导致类的初始化。
ClassLoader loader=ClassLoader.getSystemClassLoader();
Class objClass=loader.loadClass("Base");//加载Base
objClass=Class.forName("Base");//初始化Base
三、类加载器
类加载器用来把类加载到Java虚拟机中。从JDK1.2版本开始，类的加载过程采用父亲委托机制，这种机制能更好的保证Java平台的安全。在此委托机制中，除了Java虚拟机自带的根类加载器以外，其余的类加载器都有且只有一个父加载器。当Java程序请求加载器loader1加载Sample类时，loader1首先委托自己的父加载器去加载Sample类，若父加载器能加载，则父加载器完成加载任务，否则才由加载器loader1本身加载Sample类。
Java虚拟机自带了一下集中加载器：
（1）根（Bootstrap）类加载器：该加载器没有父加载器。它负责加载虚拟机的核心类库，如java.lang.*等。根类加载器从系统属性（解释一下？？？）sun.boot.class.path所指定的目录中加载类库。根类加载器的实现依赖于底层操作系统，属于虚拟机的实现的一部分，它并没有继承java.lang.ClassLoader类。
（2）扩展（Extension）类加载器：它的父加载器为根类加载器。它从java.ext.dirs系统属性所指定的目录中加载类库，或者从JDK的安装目录的jre\lib\ext子目录（扩展目录）下加载类库，如果把用户创建的JAR文件按放在这个目录下，也会自动由扩展类加载器加载。扩展类加载器是纯Java类，是java.lang.ClassLoader类的子类。
（3）系统（System）类加载器：也称为应用类加载器，它的父类加载器为扩展类加载器。它从环境变量classpath或者系统属性java.class.path所指定的目录中加载类，它是用户自定义的类加载器的默认父加载器。系统类加载器是纯Java类，是java.lang.ClassLoader类的子类。
除了以上虚拟机自带的加载器以外，用户还可以定制自己的类加载器。Java提供了抽象类java.lang.ClassLoader，所有用户自定义的类加载器应该继承ClassLoader类。
package loadtester;
public class Sample {
public static void main(String[] args) {
Class c;
ClassLoader cl,cl1;
cl = ClassLoader.getSystemClassLoader(); //获得系统加载器
System.out.println(cl); //打印系统加载器
while (cl != null) { //打印父加载器
cl1=cl;
cl = cl.getParent();
System.out.println(cl1+"'s parent is "+cl);
}
try {
c = Class.forName("java.lang.Object"); //获得代表Object类的Class实例
cl = c.getClassLoader(); //获得加载Object类的加载器
System.out.println("java.lang.Object's loader is " + cl);
c = Class.forName("loadtester.Sample"); //获得代表Sample类的Class实例
cl = c.getClassLoader(); //获得加载Sample类的加载器
System.out.println("Sample's loader is " + cl);
} catch (Exception e) {
e.printStackTrace();
}
}
}
/****************************************************
* 作者：孙卫琴 *
* 来源：<<Java面向对象编程>> *
* 技术支持网址：www.javathinker.org *
***************************************************/
注意，Java虚拟机并不会向Java程序提供根类加载器的引用，而是用”null“来表示根类加载器，这样做是为了保护Java虚拟机的安全，防止黑客利用根类加载器来加载非法的类，从而破坏Java虚拟机的核心代码。
1、类加载的父亲委托机制
在父亲委托机制中，各个加载器按照父子关系形成了树形结构，除了根类加载器以外，其余的类加载器都有且只有一个父类加载器。例如，loader2的父亲为loader1，loader1的父亲为系统类加载器。假设Java程序要求loader2加载Sample类，代码如下：
Class sampleClass=loader2.loadClass("Sample");
loader2首先从自己的命名空间中查找Sample类是否已经被加载，如果已经加载，就直接返回代表Sample类的Class对象的引用。
如果Sample类还没有被加载，loader2首先请求loader1代为加载，loader1在请求系统类加载器代为加载，系统类加载器再请求扩展类加载器代为加载，扩展类加载器再请求根类加载器代为加载。若根类加载器和扩展类加载器都不能加载，则系统类加载器尝试加载，若能加载成功，则将Sample类所对应的Class对象的引用返回给loader1，loader1再将引用返回给loader2，从而成功将Sample类加载进虚拟机。若系统类加载器不能加载Sample类，则loader1尝试加载Sample类，若loader1也不能加载，则loader2尝试加载。若所有的父加载器及loader2本身都不能加载，则抛出ClassNotFoundException异常。
若有一个类加载器能成功加载Sample类，那么这个类加载器被称为定义类加载器，所有能成功返回Class对象的引用的类加载器（包括定义类加载器）都被称为初始类加载器。
需要指出的是，加载器之间的父子关系实际上指的是加载器对象之间的包装关系，而不是类之间的继承关系。一对父子加载器可能是同一个类加载器类的两个实例，也可能不是。在子加载器对象中包装了一个父加载器对象。例如以下loader1和loader2都是MyClassLoader类的实例，并且loader2包装了loader1，loader1是loader2的父加载器。
ClassLoader loader1=new MyClassLoader();
//参数loader1将作为loader2的父加载器
ClassLoader loader2=new MyClassLoader(loader1);
父亲委托机制的优点是能够提高系统软件的安全性。因为在此机制下，用户自定义的类加载器不可能加载应该由父加载器加载的可靠类，从而防止不可靠甚至恶意的代码代替由父加载器加载的可靠代码。例如，java.lang.Object类总是由根类加载器加载，其他任何用户自定义的类加载器都不可能加载含有恶意代码的java.lang.Object类。
（1）命名空间
每个类加载器都有自己的命名空间，命名空间由该加载器及所有父加载器所加载的类组成。在同一个命名空间里，不会出现类的完整名字（包括类的包名）相同的两个类；在不同的命名空间里，有可能会出现类的完整名字（包括类的包名）相同的两个类。
（2）运行时包
由同一个类加载器加载的属于相同包的类组成了运行时包。决定两个类是不是属于同一个运行时包，不仅要看它们的包名是否相同，还要看定义类加载器是否相同。只有属于同一运行时包的类才能互相访问包可见（即默认访问级别）的类和类成员。这样的限制能避免用户自定义的类冒充核心类库的类，去访问核心类库的包可见成员。假设用户自己定义了一个类java.lang.Spy，并由用户自定义的类加载器加载，由于java.lang.Spy和核心类库java.lang.*由不同的加载器加载，它们属于不同的类加载器加载，由于它们属于不同的运行时包，所以java.lang.Spy不能访问核心类库java.lang包中的包可见成员。
2、创建用户自定义的类加载器
虽然在绝大多数情况下，系统默认提供的类加载器实现已经可以满足需求。但是在某些情况下，您还是需要为应用开发出自己的类加载器。比如您的应用通过网络来传输 Java 类的字节代码，为了保证安全性，这些字节代码经过了加密处理。这个时候您就需要自己的类加载器来从某个网络地址上读取加密后的字节代码，接着进行解密和验证，最后定义出要在 Java 虚拟机中运行的类来。
要创建用户自己的类加载器，只需要扩展java.lang.ClassLoader类，然后覆盖它的findClass(string name)方法即可，该方法根据参数指定的类的名字，返回对应的Class对象的引用。
在创建类加载器对象的时候，如果不指定显示指定父加载器，那么它的父加载器就是系统类加载器。
当子级加载器委托父级类加载器来加载时，如果父级不能加载，子级才调用findclass()方法来加载，而如果父级能完成加载，则子级就不用再来加载这个类了。 这样就避免了一个Java虚拟机中的多个类装载器为同一个类创建多份字节码数据的情况 一般，我们在自定义的类装载器不覆盖ClassLoader的loadClass()方法，而是覆盖其findClass()方法，这样就可以继续采用委托模式，同时又能在父级类不能加载时，自身能调用findClass()方法来加载。
依据一个类的存放位置，这个类最终只能由一个特定的类装载器装载。对于一个已被父级类装载器装载的类来说，Java虚拟机默认也使用这个父级类装载器去装载它所调用的其他类，由于父级类装载器不会委托子级类装载器去装载类，所以，在一般情况下，一个已被父级类装载器装载的类无法调用那些只能被子级类装载器发现和装载的其他类。
不同类加载器的命名空间存在以下关系：
（1）同一个命名空间内的类相互可见。
（2）子加载器的命名空间包含所有父加载器的命名空间。因此由子加载器加载的类能看见父加载器加载的类。例如系统类加载器加载的类能看见根类加载器加载的类。
（3）由父加载器加载的类不能看见子加载器加载的类。
（4）如果两个加载器之间没有直接或者间接的父子关系，那么他们各自加载的类相互不可见。
所谓类A能看见类B，就是指在类A的程序代码中可以引用类B的名字。
当两个不同命名空间内的类相互不可见时，可采用Java反射机制来访问对方实力的属性和方法。
3、URLClassLoader类
在JDK的java.net包中，提供了一个功能比较强大的URLClassLoader类，它扩展了ClassLoader类。他不仅能从本地文件系统中加载类，还可以从网上加载类。Java程序可直接用URLClassLoader类作为用户自定义的类加载器。URLClassLoader类提供了一下形式的构造方法：
URLClassLoader(URL[] urls)//父加载器为系统类加载器
URLClassLoader(URL[] urls, ClassLoader parent)//parent参数指定父加载器
四、类的卸载
当Sample类被加载、连接和初始化以后，它的生命周期就开始了。当代表Sample类的Class对象不再被引用，即不可触及时，Class对象就会结束生命周期，Sample类在方法区的数据也会被卸载，从而结束Sample类的生命周期。由此可见，一个类何时结束生命周期，取决于代表它的Class对象何时结束生命周期。
由Java虚拟机自带的类加载器所加载的类，在虚拟机的生命周期中，始终不会被卸载。Java虚拟机自带的类加载器包括根类加载器、扩展类加载器和系统类加载器。Java虚拟机本身会始终引用这些类加载器，而这些类加载器则会始终引用它们所加载的类的Class对象，因此这些Class对象始终是可触及的。
由用户自定义的类加载器所加载的类是可以被卸载的。