对象的创建
对象(讨论的对象限于普通Java对象，不包括数组和Class对象等)的创建是一个怎样的过程？
所以，我们按照图上的过程来进行对象创建过程的分析。
Java对象创建时机
我们知道，一个对象在可以被使用之前必须要被正确地实例化。在Java代码中，有很多行为可以引起对象的创建，最为直观的一种就是使用new关键字来调用一个类的构造函数显式地创建对象，这种方式在Java规范中被称为 : **由执行类实例创建表达式而引起的对象创建。**除此之外，我们还可以使用反射机制(Class类的newInstance方法、使用Constructor类的newInstance方法)、使用Clone方法、使用反序列化等方式创建对象。下面笔者分别对此进行一一介绍：
1). 使用new关键字创建对象
这是我们最常见的也是最简单的创建对象的方式，通过这种方式我们可以调用任意的构造函数（无参的和有参的）去创建对象。比如：
Student student = new Student();
2). 使用Class类的newInstance方法(反射机制)
我们也可以通过Java的反射机制使用Class类的newInstance方法来创建对象，事实上，这个newInstance方法调用无参的构造器创建对象，比如：
Student student2 = (Student)Class.forName("Student类全限定名").newInstance();
或者：
Student stu = Student.class.newInstance();
3). 使用Constructor类的newInstance方法(反射机制)
java.lang.relect.Constructor类里也有一个newInstance方法可以创建对象，该方法和Class类中的newInstance方法很像，但是相比之下，Constructor类的newInstance方法更加强大些，我们可以通过这个newInstance方法调用有参数的和私有的构造函数，比如：
public class Student {
private int id;
public Student(Integer id) {
this.id = id;
}
public static void main(String[] args) throws Exception {
Constructor<Student> constructor = Student.class
.getConstructor(Integer.class);
Student stu3 = constructor.newInstance(123);
}
}
使用newInstance方法的这两种方式创建对象使用的就是Java的反射机制，事实上Class的newInstance方法内部调用的也是Constructor的newInstance方法。
4). 使用Clone方法创建对象
无论何时我们调用一个对象的clone方法，JVM都会帮我们创建一个新的、一样的对象，特别需要说明的是，用clone方法创建对象的过程中并不会调用任何构造函数。关于如何使用clone方法以及浅克隆/深克隆机制，我们下面进行探究。简单而言，要想使用clone方法，我们就必须先实现Cloneable接口并实现其定义的clone方法，这也是原型模式的应用。比如：
public class Student implements Cloneable{
private int id;
public Student(Integer id) {
this.id = id;
}
@Override
protected Object clone() throws CloneNotSupportedException {
// TODO Auto-generated method stub
return super.clone();
}
public static void main(String[] args) throws Exception {
Constructor<Student> constructor = Student.class
.getConstructor(Integer.class);
Student stu3 = constructor.newInstance(123);
Student stu4 = (Student) stu3.clone();
}
}
延伸：克隆
1、克隆的定义与意义
顾名思义，克隆就是制造一个对象的副本。一般地，根据所要克隆的对象的成员变量中是否含有引用类型，可以将克隆分为两种：浅克隆(Shallow Clone) 和 深克隆(Deep Clone)，默认情况下使用Object中的clone方法进行克隆就是浅克隆，即完成对象域对域的拷贝。
(1). Object 中的 clone() 方法
在使用clone()方法时，若该类未实现 Cloneable 接口，则抛出 java.lang.CloneNotSupportedException 异常。下面我们以Employee这个例子进行说明：
public class Employee {
private String name;
private double salary;
private Date hireDay;
...
public static void main(String[] args) throws CloneNotSupportedException {
Employee employee = new Employee();
employee.clone();
System.out.println("克隆完成...");
}
}/* Output:
~Exception in thread "main" java.lang.CloneNotSupportedException: P1_1.Employee
*///:
(2). Cloneable 接口
Cloneable 接口是一个标识性接口，即该接口不包含任何方法（甚至没有clone()方法），但是如果一个类想合法的进行克隆，那么就必须实现这个接口。下面我们看JDK对它的描述：
A class implements the Cloneable interface to indicate to the java.lang.Object.clone() method that it is legal for that method to make a field-for-field copy of instances of that class.
类实现了Cloneable接口，以向java.lang.Object.clone()方法表明，该方法对该类的实例进行字段对字段的复制是合法的。
Invoking Object’s clone method on an instance that does not implement the Cloneable interface results in the exception CloneNotSupportedException being thrown.
在未实现Cloneable接口的实例上调用Object的clone方法会导致抛出异常CloneNotSupportedException。
By convention, classes that implement this interface should override Object.clone (which is protected) with a public method.
按照惯例，实现此接口的类应使用公共方法覆盖Object.clone（受保护）。
Note that this interface does not contain the clone() method. Therefore, it is not possible to clone an object merely by virtue of the fact that it implements this interface. Even if the clone method is invoked reflectively, there is no guarantee that it will succeed.
请注意，此接口不包含clone（）方法。 因此，仅仅通过实现该接口的事实来克隆对象是不可能的。 即使反射调用clone方法，也无法保证它会成功。
/**
* @author unascribed
* @see java.lang.CloneNotSupportedException
* @see java.lang.Object#clone()
* @since JDK1.0
*/
public interface Cloneable {
}
2、Clone & Copy
假设现在有一个Employee对象，Employee tobby = new Employee(“CMTobby”,5000)，通常, 我们会有这样的赋值Employee tom=tobby，这个时候只是简单了copy了一下reference，tom 和 tobby 都指向内存中同一个object，这样tom或者tobby对对象的修改都会影响到对方。打个比方，如果我们通过tom.raiseSalary()方法改变了salary域的值，那么tobby通过getSalary()方法得到的就是修改之后的salary域的值，显然这不是我们愿意看到的。如果我们希望得到tobby所指向的对象的一个精确拷贝，同时两者互不影响，那么我们就可以使用Clone来满足我们的需求。Employee
cindy=tobby.clone()，这时会生成一个新的Employee对象，并且和tobby具有相同的属性值和方法。
3、Shallow Clone & Deep Clone
Clone是如何完成的呢？Object中的clone()方法在对某个对象实施克隆时对其是一无所知的，它仅仅是简单地执行域对域的copy，这就是Shallow Clone。这样，问题就来了，以Employee为例，它里面有一个域hireDay不是基本类型的变量，而是一个reference变量，经过Clone之后克隆类只会产生一个新的Date类型的引用，它和原始引用都指向同一个 Date 对象，这样克隆类就和原始类共享了一部分信息，显然这种情况不是我们愿意看到的，过程下图所示：
这个时候，我们就需要进行 Deep Clone了，以便对那些引用类型的域进行特殊的处理，例如本例中的hireDay。我们可以重新定义 clone方法，对hireDay做特殊处理，如下代码所示：
class Employee implements Cloneable
{
private String name;
private int id;
private Date hireDay;
...
@Override
public Object clone() throws CloneNotSupportedException {
Employee cloned = (Employee) super.clone();
// Date 支持克隆且重写了clone()方法，Date 的定义是：
// public class Date implements java.io.Serializable, Cloneable, Comparable<Date>
cloned.hireDay = (Date) hireDay.clone() ;
return cloned;
}
}
因此，Object 在对某个对象实施 Clone 时，对其是一无所知的，它仅仅是简单执行域对域的Copy。 其中，对八种基本类型的克隆是没有问题的，但当对一个引用类型进行克隆时，只是克隆了它的引用。因此，克隆对象和原始对象共享了同一个对象成员变量，故而提出了深克隆 ： 在对整个对象浅克隆后，还需对其引用变量进行克隆，并将其更新到浅克隆对象中去。
4、一个克隆的示例
在这里，我们通过一个简单的例子来说明克隆在Java中的使用，如下所示：
// 子类 Manger
public class Manger extends Employee implements Cloneable {
private String edu;
public Manger(String name, double salary, Date hireDay, String edu) {
super(name, salary, hireDay);
this.edu = edu;
}
public String getEdu() {
return edu;
}
public void setEdu(String edu) {
this.edu = edu;
}
@Override
public String toString() {
return this.getName() + " : " + this.getSalary() + " : "
+ this.getHireDay() + " : " + this.getEdu();
}
@Override
public int hashCode() {
final int prime = 31;
int result = super.hashCode();
result = prime * result + ((edu == null) ? 0 : edu.hashCode());
return result;
}
@Override
public boolean equals(Object obj) {
if (this == obj)
return true;
if (!super.equals(obj))
return false;
if (getClass() != obj.getClass())
return false;
Manger other = (Manger) obj;
if (edu == null) {
if (other.edu != null)
return false;
} else if (!edu.equals(other.edu))
return false;
return true;
}
public static void main(String[] args) throws CloneNotSupportedException {
Manger manger = new Manger("Rico", 20000.0, new Date(), "NEU");
// 输出manger
System.out.println("Manger对象 = " + manger.toString());
Manger clonedManger = (Manger) manger.clone();
// 输出克隆的manger
System.out.println("Manger对象的克隆对象 = " + clonedManger.toString());
System.out.println("Manger对象和其克隆对象是否相等： "
+ manger.equals(clonedManger) + "\r\n");
// 修改、输出manger
manger.setEdu("TJU");
System.out.println("修改后的Manger对象 = " + manger.toString());
// 再次输出manger
System.out.println("原克隆对象= " + clonedManger.toString());
System.out.println("修改后的Manger对象和原克隆对象是否相等： "
+ manger.equals(clonedManger));
}
}
/* Output:
Manger对象 = Rico : 20000.0 : Mon Mar 13 15:36:03 CST 2017 : NEU
Manger对象的克隆对象 = Rico : 20000.0 : Mon Mar 13 15:36:03 CST 2017 : NEU
Manger对象和其克隆对象是否相等： true
修改后的Manger对象 = Rico : 20000.0 : Mon Mar 13 15:36:03 CST 2017 : TJU
原克隆对象= Rico : 20000.0 : Mon Mar 13 15:36:03 CST 2017 : NEU
修改后的Manger对象和原克隆对象是否相等： false
*///:
5、Clone()方法的保护机制
在Object中clone()是被申明为 protected 的，这样做是有一定的道理的。以 Employee 类为例，如果我们在Employee中重写了protected Object clone()方法，就大大限制了可以“克隆”Employee对象的范围，即可以保证只有在和Employee类在同一包中类及Employee类的子类里面才能“克隆”Employee对象。进一步地，如果我们没有在Employee类重写clone()方法，则只有Employee类及其子类才能够“克隆”Employee对象。
6、注意事项
Clone()方法的使用比较简单，注意如下几点即可：
什么时候使用shallow Clone，什么时候使用deep Clone？
这个主要看具体对象的域是什么性质的，基本类型还是引用类型。
- 调用Clone()方法的对象所属的类(Class)必须实现 Clonable 接口，否则在调用Clone方法的时候会抛出CloneNotSupportedException；
- 所有数组对象都实现了 Clonable 接口，默认支持克隆；
- 如果我们实现了Clonable 接口，但没有重写Object类的clone方法，那么执行域对域的拷贝；
明白 String 在克隆中的特殊性
String 在克隆时只是克隆了它的引用。
奇怪的是，在修改克隆后的String对象时，其原来的对象并未改变。原因是：String是在内存中不可以被改变的对象。虽然在克隆时，源对象和克隆对象都指向了同一个String对象，但当其中一个对象修改这个String对象的时候，会新分配一块内存用来保存修改后的String对象并将其引用指向新的String对象，而原来的String对象因为还存在指向它的引用，所以不会被回收。这样，对于String而言，虽然是复制的引用，但是当修改值的时候，并不会改变被复制对象的值。所以在使用克隆时，我们可以将 String类型 视为与基本类型，只需浅克隆即可。
5). 使用(反)序列化机制创建对象
当我们反序列化一个对象时，JVM会给我们创建一个单独的对象，在此过程中，JVM并不会调用任何构造函数。为了反序列化一个对象，我们需要让我们的类实现Serializable接口，比如：
public class Student implements Cloneable, Serializable {
private int id;
public Student(Integer id) {
this.id = id;
}
@Override
public String toString() {
return "Student [id=" + id + "]";
}
public static void main(String[] args) throws Exception {
Constructor<Student> constructor = Student.class
.getConstructor(Integer.class);
Student stu3 = constructor.newInstance(123);
// 写对象
ObjectOutputStream output = new ObjectOutputStream(
new FileOutputStream("student.bin"));
output.writeObject(stu3);
output.close();
// 读对象
ObjectInputStream input = new ObjectInputStream(new FileInputStream(
"student.bin"));
Student stu5 = (Student) input.readObject();
System.out.println(stu5);
}
}
虚拟机遇到一条new指令时，首先将去检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有，那必须执行相应的类加载过程。
探究：类加载机制
一、类加载机制概述
我们知道，一个.java文件在编译后会形成相应的一个或多个Class文件（若一个类中含有内部类，则编译后会产生多个Class文件），但这些Class文件中描述的各种信息，最终都需要加载到虚拟机中之后才能被运行和使用。事实上，虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验，转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型的过程就是虚拟机的类加载机制。
与那些在编译时需要进行连接工作的语言不同，在Java语言里面，类型的加载和连接都是在程序运行期间完成，这样会在类加载时稍微增加一些性能开销，但是却能为Java应用程序提供高度的灵活性，Java中天生可以动态扩展的语言特性多态就是依赖运行期动态加载和动态链接这个特点实现的。例如，如果编写一个使用接口的应用程序，可以等到运行时再指定其实际的实现。这种组装应用程序的方式广泛应用于Java程序之中。
二. 类加载的时机
Java类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载（Loading）、验证（Verification）、准备(Preparation)、解析(Resolution)、初始化(Initialization)、使用(Using) 和 卸载(Unloading)七个阶段。其中准备、验证、解析3个部分统称为连接（Linking），如图所示：
加载、验证、准备、初始化和卸载这5个阶段的顺序是确定的，类的加载过程必须按照这种顺序按部就班地开始，而解析阶段则不一定：它在某些情况下可以在初始化阶段之后再开始，这是为了支持Java语言的运行时绑定（也称为动态绑定或晚期绑定）。以下陈述的内容都已HotSpot为基准。特别需要注意的是，类的加载过程必须按照这种顺序按部就班地“开始”，而不是按部就班的“进行”或“完成”，因为这些阶段通常都是相互交叉地混合式进行的，也就是说通常会在一个阶段执行的过程中调用或激活另外一个阶段。
了解了Java类的生命周期以后，那么我们现在来回答第一个问题：虚拟机什么时候才会加载Class文件并初始化类呢？
1、类加载时机
什么情况下虚拟机需要开始加载一个类呢？虚拟机规范中并没有对此进行强制约束，这点可以交给虚拟机的具体实现来自由把握。
2、类初始化时机
那么，什么情况下虚拟机需要开始初始化一个类呢？这在虚拟机规范中是有严格规定的，虚拟机规范指明 有且只有五种情况必须立即对类进行初始化（而这一过程自然发生在加载、验证、准备之后）：
1) 遇到new、getstatic、putstatic或invokestatic这四条字节码指令,如果类没有进行过初始化，则需要先对其进行初始化。生成这四条指令的最常见的Java代码场景是：使用new关键字实例化对象的时候；
读取或设置一个类的静态字段（被final修饰，已在编译器把结果放入常量池的静态字段除外）的时候；
调用一个类的静态方法的时候。
2) 使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发其初始化。
3) 当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。
4) 当虚拟机启动时，用户需要指定一个要执行的主类（包含main()方法的那个类），虚拟机会先初始化这个主类。
5) 当使用jdk1.7动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getstatic,REF_putstatic,REF_invokeStatic的方法句柄，并且这个方法句柄所对应的类没有进行初始化，则需要先出触发其初始化。
注意，对于这五种会触发类进行初始化的场景，虚拟机规范中使用了一个很强烈的限定语**：“有且只有”，这五种场景中的行为称为对一个类进行主动引用**。除此之外，所有引用类的方式，都不会触发初始化，称为被动引用。
特别需要指出的是，类的实例化与类的初始化是两个完全不同的概念：
类的实例化是指创建一个类的实例(对象)的过程；
类的初始化是指为类中各个类成员(被static修饰的成员变量)赋初始值的过程，是类生命周期中的一个阶段。
3、被动引用的几种经典场景
1)、通过子类引用父类的静态字段，不会导致子类初始化
public class SSClass{
static{
System.out.println("SSClass");
}
}
public class SClass extends SSClass{
static{
System.out.println("SClass init!");
}
public static int value = 123;
public SClass(){
System.out.println("init SClass");
}
}
public class SubClass extends SClass{
static{
System.out.println("SubClass init");
}
static int a;
public SubClass(){
System.out.println("init SubClass");
}
}
public class NotInitialization{
public static void main(String[] args){
System.out.println(SubClass.value);
}
}/* Output:
SSClass
SClass init!
123
*///:~
对于静态字段，只有直接定义这个字段的类才会被初始化，因此通过其子类来引用父类中定义的静态字段，只会触发父类的初始化而不会触发子类的初始化。在本例中，由于value字段是在类SClass中定义的，因此该类会被初始化；此外，在初始化类SClass时，虚拟机会发现其父类SSClass还未被初始化，因此虚拟机将先初始化父类SSClass，然后初始化子类SClass，而SubClass始终不会被初始化。
2)、通过数组定义来引用类，不会触发此类的初始化
public class NotInitialization{
public static void main(String[] args){
SClass[] sca = new SClass[10];
}
}
上述案例运行之后并没有任何输出，**说明虚拟机并没有初始化类SClass。**但是，这段代码触发了另外一个名为[Lcn.edu.tju.rico.SClass的类的初始化。从类名称我们可以看出，这个类代表了元素类型为SClass的一维数组，它是由虚拟机自动生成的，直接继承于Object的子类，创建动作由字节码指令newarray触发。
3)、常量在编译阶段会存入调用类的常量池中，本质上并没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化
public class ConstClass{
static{
System.out.println("ConstClass init!");
}
public static final String CONSTANT = "hello world";
}
public class NotInitialization{
public static void main(String[] args){
System.out.println(ConstClass.CONSTANT);
}
}/* Output:
hello world
*///:~
上述代码运行之后，只输出 “hello world”，这是因为虽然在Java源码中引用了ConstClass类中的常量CONSTANT，但是编译阶段将此常量的值“hello world”存储到了NotInitialization常量池中，对常量ConstClass.CONSTANT的引用实际都被转化为NotInitialization类对自身常量池的引用了。也就是说，实际上NotInitialization的Class文件之中并没有ConstClass类的符号引用入口，这两个类在编译为Class文件之后就不存在关系了。
接口的加载过程与类加载过程稍有一些不同，针对接口需要做一些特殊说明：接口也有初始化过程，这点与类是一致的，上面的代码都是用静态代码块“static｛｝“来输出初始化信息的，而接口中不能使用“static｛｝“语句块，但编译器仍然会为接口生成“clinit()“类构造器，用于初始化接口中所定义的成员变量。接口与类真正有所区别的是：当一个类在初始化时，要求其父类全部都已经初始化过了，但是一个接口在初始化时，并不要求其父接口全部都完成了初始化，只有在真正使用到父接口的时候（如引用接口中定义的常量）才会初始化。
延伸：初始化与实例化的区别
class A{
public A(){
……//初始化
}
public static void main(String args[]){
A a(指定一个类型为A的引用A)=new A()(实例化，初始化就是执行A的构造函数，见上，如无则调用默认的);
}
只有 A a;既不是初始化，也不是实例化，只是一个声明而已。
A a = new A（）；//new A 才是实例化
初始化，比如，你声明了一个对象引用，Object o = null；这就是把这个引用初始化一下
初始化:在程序RUN的一瞬间，什么类啊，静态的东西啊（静态块，静态方法，静态属性），刷刷刷的就在内存中加载（你可以看作初始化）了，只加载一次。
实例化:然后main方法开始运行（这就是为什么main方法必须是静态的原因），然后执行main中的代码语句，执行到new对象时，才会实例化对象。
记住：类加载，只执行一次，即只有有一个类对象（注意不是实例对象），无论你以后怎么个new法，新new的都是实例对象。
三. 类加载过程
现在我们一一学习一下JVM在加载、验证、准备、解析和初始化五个阶段是如何对每个类进行操作的。
1、加载（Loading）
1）通过一个类的全限定名来获取定义此类的二进制字节流。 （并没有指明要从一个Class文件中获取，可以从其他渠道，譬如：网络、动态生成、数据库等）；
2）将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
3）在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。
加载阶段和连接阶段（Linking）的部分内容（如一部分字节码文件格式验证动作）是交叉进行的，加载阶段尚未完成，连接阶段可能已经开始，但这些夹在加载阶段之中进行的动作，仍然属于连接阶段的内容，这两个阶段的开始时间仍然保持着固定的先后顺序。
特别地，第一件事情(通过一个类的全限定名来获取定义此类的二进制字节流)是由类加载器完成的，具体涉及JVM预定义的类加载器、双亲委派模型等内容，详情请参见我的转载博文《深入理解Java类加载器(一)：Java类加载原理解析》中的说明，此不赘述。
延伸:限定类名
限定类名，就是类名全称，带包路径的用点隔开，例如: java.lang.String。
非限定(non-qualified)类名也叫短名，就是我们平时说的类名，不带包的，例如：String。
非限定类名是相对于限定类名来说的，在Java中有很多类，不同的类之间会存在相同的函数或者方法，所以有时候就需要限定类名来调包。 而如果不存在相同的函数或者方法 ，就可以使用非限定(non-qualified)类名。
2、验证（Verification）
验证是连接阶段的第一步，这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。 验证阶段大致会完成4个阶段的检验动作：
- 文件格式验证：验证字节流是否符合Class文件格式的规范(例如，是否以魔术0xCAFEBABE开头、主次版本号是否在当前虚拟机的处理范围之内、常量池中的常量是否有不被支持的类型)
- 元数据验证：对字节码描述的信息进行语义分析，以保证其描述的信息符合Java语言规范的要求(例如：这个类是否有父类，除了java.lang.Object之外)；
- 字节码验证：通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的;
- 符号引用验证：确保解析动作能正确执行。
验证阶段是非常重要的，但不是必须的，它对程序运行期没有影响。如果所引用的类经过反复验证，那么可以考虑采用**-Xverifynone参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。**
3、准备(Preparation)
准备阶段是正式为类变量(static 成员变量)分配内存并设置类变量初始值（零值）的阶段，这些变量所使用的内存都将在方法区中进行分配。这时候进行内存分配的仅包括类变量，而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在堆中。其次，这里所说的初始值“通常情况”下是数据类型的零值，假设一个类变量的定义为：
public static int value = 123;
那么，变量value在准备阶段过后的值为0而不是123。因为这时候尚未开始执行任何java方法，而把value赋值为123的putstatic指令是程序被编译后，存放于类构造器方法()之中，所以把value赋值为123的动作将在初始化阶段才会执行。至于“特殊情况”是指：当类字段的字段属性是ConstantValue时，会在准备阶段初始化为指定的值，所以标注为final之后，value的值在准备阶段初始化为123而非0。
public static final int value = 123;
4、解析(Resolution)
解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行。
5、初始化(Initialization)
类初始化阶段是类加载过程的最后一步。在前面的类加载过程中，除了在加载阶段用户应用程序可以通过自定义类加载器参与之外，其余动作完全由虚拟机主导和控制。到了初始化阶段，才真正开始执行类中定义的java程序代码(字节码)。
在准备阶段，变量已经赋过一次系统要求的初始值(零值)；而在初始化阶段，则根据程序猿通过程序制定的主观计划去初始化类变量和其他资源，或者更直接地说：初始化阶段是执行类构造器()方法的过程。()方法是由**编译器自动收集类中的所有类变量的赋值动作和静态语句块static{}中的语句合并产生的，**编译器收集的顺序是由语句在源文件中出现的顺序所决定的，**静态语句块只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访问。**如下：
public class Test{
static{
i=0;
System.out.println(i);//Error：Cannot reference a field before it is defined（非法向前应用）
}
static int i=1;
}
那么注释报错的那行代码，改成下面情形，程序就可以编译通过并可以正常运行了。
public class Test{
static{
i=0;
//System.out.println(i);
}
static int i=1;
public static void main(String args[]){
System.out.println(i);
}
}/* Output:
1
*///:~
类构造器()与实例构造器()不同，它不需要程序员进行显式调用，虚拟机会保证在子类类构造器()执行之前，父类的类构造()执行完毕。由于父类的构造器()先执行，也就意味着父类中定义的静态语句块/静态变量的初始化要优先于子类的静态语句块/静态变量的初始化执行。特别地，类构造器()对于类或者接口来说并不是必需的，如果一个类中没有静态语句块，也没有对类变量的赋值操作，那么编译器可以不为这个类生产类构造器()。
虚拟机会保证一个类的类构造器()在多线程环境中被正确的加锁、同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的类构造器()，其他线程都需要阻塞等待，直到活动线程执行()方法完毕。特别需要注意的是，在这种情形下，其他线程虽然会被阻塞，但如果执行()方法的那条线程退出后，其他线程在唤醒之后不会再次进入/执行()方法，因为 在同一个类加载器下，一个类型只会被初始化一次。如果在一个类的()方法中有耗时很长的操作，就可能造成多个线程阻塞，在实际应用中这种阻塞往往是隐藏的，如下所示：
public class DealLoopTest {
static{
System.out.println("DealLoopTest...");
}
static class DeadLoopClass {
static {
if (true) {
System.out.println(Thread.currentThread()
+ "init DeadLoopClass");
while (true) { // 模拟耗时很长的操作
}
}
}
}
public static void main(String[] args) {
Runnable script = new Runnable() { // 匿名内部类
public void run() {
System.out.println(Thread.currentThread() + " start");
DeadLoopClass dlc = new DeadLoopClass();
System.out.println(Thread.currentThread() + " run over");
}
};
Thread thread1 = new Thread(script);
Thread thread2 = new Thread(script);
thread1.start();
thread2.start();
}
}/* Output:
DealLoopTest...
Thread[Thread-1,5,main] start
Thread[Thread-0,5,main] start
Thread[Thread-1,5,main]init DeadLoopClass
*///:~
如上述代码所示，在初始化DeadLoopClass类时，线程Thread-1得到执行并在执行这个类的类构造器() 时，由于该方法包含一个死循环，因此久久不能退出。
四. 典型案例分析
我们知道，在Java中， 创建一个对象常常需要经历如下几个过程：父类的类构造器() -> 子类的类构造器() -> 父类的成员变量和实例代码块 -> 父类的构造函数 -> 子类的成员变量和实例代码块 -> 子类的构造函数。
那么，我们看看下面的程序的输出结果：
public class StaticTest {
public static void main(String[] args) {
staticFunction();
}
static StaticTest st = new StaticTest();
static { //静态代码块
System.out.println("1");
}
{ // 实例代码块
System.out.println("2");
}
StaticTest() { // 实例构造器
System.out.println("3");
System.out.println("a=" + a + ",b=" + b);
}
public static void staticFunction() { // 静态方法
System.out.println("4");
}
int a = 110; // 实例变量
static int b = 112; // 静态变量
}/* Output:
2
3
a=110,b=0
1
4
*///:~
大家能得到正确答案吗？虽然笔者勉强猜出了正确答案，但总感觉怪怪的。因为在初始化阶段，当JVM对类StaticTest进行初始化时，首先会执行下面的语句：
static StaticTest st = new StaticTest();
也就是实例化StaticTest对象，但这个时候类都没有初始化完毕啊，能直接进行实例化吗？事实上，这涉及到一个根本问题就是：实例初始化不一定要在类初始化结束之后才开始初始化。下面我们结合类的加载过程说明这个问题。
我们知道，类的生命周期是：加载->验证->准备->解析->初始化->使用->卸载，并且只有在准备阶段和初始化阶段才会涉及类变量的初始化和赋值，因此我们只针对这两个阶段进行分析：
首先，在类的准备阶段需要做的是为类变量（static变量）分配内存并设置默认值(零值)，因此在该阶段结束后，类变量st将变为null、b变为0。特别需要注意的是，如果类变量是final的，那么编译器在编译时就会为value生成ConstantValue属性，并在准备阶段虚拟机就会根据ConstantValue的设置将变量设置为指定的值。也就是说，如果上述程度对变量b采用如下定义方式时：
static final int b=112
那么，在准备阶段b的值就是112，而不再是0了。
此外，在类的初始化阶段需要做的是执行类构造器()，需要指出的是，类构造器本质上是编译器收集所有静态语句块和类变量的赋值语句按语句在源码中的顺序合并生成类构造器()。因此，对上述程序而言，JVM将先执行第一条静态变量的赋值语句：
st = new StaticTest ()
即“在类都没有初始化完毕之前，能直接进行实例化相应的对象吗？”。事实上，从Java角度看，我们知道一个类初始化的基本常识，那就是：在同一个类加载器下，一个类型只会被初始化一次。所以，一旦开始初始化一个类型，无论是否完成，后续都不会再重新触发该类型的初始化阶段了(只考虑在同一个类加载器下的情形)。因此，在实例化上述程序中的st变量时，实际上是把实例初始化嵌入到了静态初始化流程中，并且在上面的程序中，嵌入到了静态初始化的起始位置。这就导致了实例初始化完全发生在静态初始化之前，当然，这也是导致a为110b为0的原因。
因此，上述程序的StaticTest类构造器()的实现等价于：
public class StaticTest {
<clinit>(){
a = 110; // 实例变量
System.out.println("2"); // 实例代码块
System.out.println("3"); // 实例构造器中代码的执行
System.out.println("a=" + a + ",b=" + b); // 实例构造器中代码的执行
类变量st被初始化
System.out.println("1"); //静态代码块
类变量b被初始化为112
}
}
因此，上述程序会有上面的输出结果。下面，我们对上述程序稍作改动，如下所示：
public class StaticTest {
public static void main(String[] args) {
staticFunction();
}
static StaticTest st = new StaticTest();
static {
System.out.println("1");
}
{
System.out.println("2");
}
StaticTest() {
System.out.println("3");
System.out.println("a=" + a + ",b=" + b);
}
public static void staticFunction() {
System.out.println("4");
}
int a = 110;
static int b = 112;
static StaticTest st1 = new StaticTest();
}
在程序最后的一行，增加以下代码行：
static StaticTest st1 = new StaticTest();
那么，此时程序的输出又是什么呢？如果你对上述的内容理解很好的话，不难得出结论(只有执行完上述代码行后，StaticTest类才被初始化完成)，即：
2
3
a=110,b=0
1
2
3
a=110,b=112
4
Java类加载的方式
虚拟机设计团队把类加载阶段中的**“通过一个类的全限定名来获取描述此类的二进制字节流"这个动作放在了 java 虚拟机外部去实现，以便让应用程序自己决定如何去获取需要的类。实现这个动作的代码模块称为"类加载器”。
类加载器在 java 程序中起到的作用远远不限于类的加载阶段。在运行阶段，比较两个类是否「相等」，只有在这两个类来源于用一个 Class文件，被同一个虚拟机加载，并且使同一个类加载器加载，这两个类才会相等。**
这里所指的「相等」，包括代表类的 Class 对象的 equals 方法、isAssignableFrom方法、isInstance 方法的返回结果，也包括使用 instanceof 关键字做对象所属关系判定等情况。
1.类加载器体系结构
从java虚拟机的角度来讲，只存在两种不同的类加载器：
1）一种是启动类加载器，这个类加载器使用C++语言实现，是虚拟机自身的一部分；
2）另一种就是所有其他的类加载器，这些类加载器都由java语言实现，独立于虚拟机外部，并且全都继承自抽象类java.lang.ClassLoader。
从java开发人员的角度来看，类加载器还可以划分得更细致一些，绝大部分java程序都会使用到以下3种系统的提供的类加载器，Java中的类加载器体系结构如下：
- 1）BootStrap ClassLoader：启动类加载器，负责加载存放在%JAVA_HOME%\lib目录中的，或者被-Xbootclasspath参数所指定的路径中的，并且被java虚拟机识别的(仅按照文件名识别，如rt.jar，名字不符合的类库，即使放在指定路径中也不会被加载)类库加载到虚拟机的内存中，启动类加载器无法被java程序直接引用。用户在编写自定义类加载器时，如果需要把加载器请求委派给引导类加载器，那直接使用null代替即可。
- 2）Extension ClassLoader：扩展类加载器，由sun.misc.Launcher$ExtClassLoader实现，负责加载%JAVA_HOME%\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器。
- 3）Application ClassLoader：应用程序类加载器，由sun.misc.Launcher $App-ClassLoader实现。由于这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值，所以一般也称它为系统类加载器。它负责加载用户类路径（ClassPath）上所指定的类库，开发者可以直接使用这个类加载器，如果应用程序中没有定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。
上图类加载器的这种层次关系，称为类加载器的双亲委派模型。双亲委派模型要求除了顶层的启动类加载器外，其余的加载器都应当有自己的父类加载器。这里的类加载器虽然是父子类加载器关系，但是没有使用继承，而是使用了组合关系。
2、双亲委派模型
从JDK1.2开始，java虚拟机规范推荐开发者使用双亲委派模式(ParentsDelegation Model)进行类加载，其加载过程如下：
(1).如果一个类加载器收到了类加载请求，它首先不会自己去尝试加载这个类，而是把类加载请求委派给父类加载器去完成。
(2).每一层的类加载器都把类加载请求委派给父类加载器，直到所有的类加载请求都应该传递给顶层的启动类加载器。
(3).如果顶层的启动类加载器无法完成加载请求，子类加载器尝试去加载，如果连最初发起类加载请求的类加载器也无法完成加载请求时，将会抛出ClassNotFoundException，而不再调用其子类加载器去进行类加载。
双亲委派模式的类加载机制的优点是java类它的类加载器一起具备了一种带优先级的层次关系，越是基础的类，越是被上层的类加载器进行加载，保证了java程序的稳定运行。
双亲委派模型的实现却非常简单,实现双亲委派的代码都集中在java.lang.ClassLoader的loadClass()方法之中,如下面代码所示，先检查是否已经被加载过，若没有加载则调用父加载器的loadClass()方法，若父加载器为空则默认使用启动类加载器作为父加载器。如果父类加载失败，抛出异常后，再调用自己的findClass()方法加载。
public Class<?> loadClass(String name) throws ClassNotFoundException {
return loadClass(name, false);
}
protected synchronized Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException {
// 首先判断该类型是否已经被加载
Class c = findLoadedClass(name);
if (c == null) {
//如果没有被加载，就委托给父类加载或者委派给启动类加载器加载
try {
if (parent != null) {
//如果存在父类加载器，就委派给父类加载器加载
c = parent.loadClass(name, false);
} else { // 递归终止条件
// 由于启动类加载器无法被Java程序直接引用，因此默认用 null 替代
// parent == null就意味着由启动类加载器尝试加载该类，
// 即通过调用 native方法 findBootstrapClass0(String name)加载
c = findBootstrapClass0(name);
}
} catch (ClassNotFoundException e) {
// 如果父类加载器不能完成加载请求时，再调用自身的findClass方法进行类加载，若加载成功，findClass方法返回的是defineClass方法的返回值
// 注意，若自身也加载不了，会产生ClassNotFoundException异常并向上抛出
c = findClass(name);
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
加载器体系结构给人的直观印象是：应用程序类加载器的父类加载器是标准扩展类加载器，标准扩展类加载器的父类加载器是启动类加载器，下面我们就用代码具体测试一下：
public class LoaderTest {
public static void main(String[] args) {
try {
System.out.println(ClassLoader.getSystemClassLoader());
System.out.println(ClassLoader.getSystemClassLoader().getParent());
System.out.println(ClassLoader.getSystemClassLoader().getParent().getParent());
} catch (Exception e) {
e.printStackTrace();
}
}
}/* Output:
[email protected]
[email protected]
null
*///
通过以上的代码输出，我们知道：通过java.lang.ClassLoader.getSystemClassLoader()可以直接获取到应用程序类加载器，并且可以判定应用程序类加载器的父加载器是标准扩展类加载器，但是我们试图获取标准扩展类加载器的父类加载器时却得到了null。事实上，由于启动类加载器无法被Java程序直接引用，因此JVM默认直接使用 null 代表启动类加载器。我们还是借助于代码分析一下，首先看一下java.lang.ClassLoader抽象类中默认实现的两个构造函数：
protected ClassLoader() {
SecurityManager security = System.getSecurityManager();
if (security != null) {
security.checkCreateClassLoader();
}
//默认将父类加载器设置为系统类加载器，getSystemClassLoader()获取系统类加载器
this.parent = getSystemClassLoader();
initialized = true;
}
protected ClassLoader(ClassLoader parent) {
SecurityManager security = System.getSecurityManager();
if (security != null) {
security.checkCreateClassLoader();
}
//强制设置父类加载器
this.parent = parent;
initialized = true;
}
紧接着，我们再看一下ClassLoader抽象类中parent成员的声明：
// The parent class loader for delegation
private ClassLoader parent;
声明为私有变量的同时并没有对外提供可供派生类访问的public或者protected设置器接口（对应的setter方法），结合前面的测试代码的输出，我们可以推断出：
1．系统类加载器（AppClassLoader）调用ClassLoader(ClassLoader parent)构造函数将父类加载器设置为标准扩展类加载器(ExtClassLoader)。（因为如果不强制设置，默认会通过调用getSystemClassLoader()方法获取并设置成系统类加载器，这显然和测试输出结果不符。）
2．扩展类加载器（ExtClassLoader）调用ClassLoader(ClassLoader parent)构造函数将父类加载器设置为null（null 本身就代表着引导类加载器）。（因为如果不强制设置，默认会通过调用getSystemClassLoader()方法获取并设置成系统类加载器，这显然和测试输出结果不符。）
事实上，这就是启动类加载器、标准扩展类加载器和系统类加载器之间的委派关系。
类加载双亲委派示例
下面我们就来看一个综合的例子，首先在IDE中建立一个简单的java应用工程，然后写一个简单的JavaBean如下：
package classloader.test.bean;
public class TestBean {
public TestBean() { }
}
在现有当前工程中另外建立一个测试类（ClassLoaderTest.java）内容如下：
测试一：
package classloader.test.bean;
public class ClassLoaderTest {
public static void main(String[] args) {
try {
//查看当前系统类路径中包含的路径条目
System.out.println(System.getProperty("java.class.path"));
//调用加载当前类的类加载器（这里即为系统类加载器）加载TestBean
Class typeLoaded = Class.forName("classloader.test.bean.TestBean");
//查看被加载的TestBean类型是被那个类加载器加载的
System.out.println(typeLoaded.getClassLoader());
} catch (Exception e) {
e.printStackTrace();
}
}
}/* Output:
I:\AlgorithmPractice\TestClassLoader\bin
[email protected]
*///:~
测试二：
将当前工程输出目录下的TestBean.class打包进test.jar剪贴到/lib/ext目录下（现在工程输出目录下和JRE扩展目录下都有待加载类型的class文件）。再运行测试一测试代码，结果如下：
I:\AlgorithmPractice\TestClassLoader\bin
[email protected]
对比测试一和测试二，我们明显可以验证前面说的双亲委派机制：系统类加载器在接到加载classloader.test.bean.TestBean类型的请求时，首先将请求委派给父类加载器（标准扩展类加载器），标准扩展类加载器抢先完成了加载请求。
测试三：
将test.jar拷贝一份到/lib下，运行测试代码，输出如下：
I:\AlgorithmPractice\TestClassLoader\bin
[email protected]
测试三和测试二输出结果一致。那就是说，放置到/lib目录下的TestBean对应的class字节码并没有被加载，这其实和前面讲的双亲委派机制并不矛盾。**虚拟机出于安全等因素考虑，不会加载<JAVA_HOME>/lib目录下存在的陌生类，换句话说，虚拟机只加载<JAVA_HOME>/lib目录下它可以识别的类。因此，开发者通过将要加载的非JDK自身的类放置到此目录下期待启动类加载器加载是不可能的。**做个进一步验证，删除<JAVA_HOME>/lib/ext目录下和工程输出目录下的TestBean对应的class文件，然后再运行测试代码，则将会有ClassNotFoundException异常抛出。
除此之外，ClassLoader 还负责加载 Java 应用所需的资源，如图像文件和配置文件等，ClassLoader 中与加载类相关的方法如下：
3.用户自定义类加载器
通过前面的分析，我们可以看出，**除了和本地实现密切相关的启动类加载器之外，包括标准扩展类加载器和系统类加载器在内的所有其他类加载器我们都可以当做自定义类加载器来对待，唯一区别是是否被虚拟机默认使用。**前面的内容中已经对java.lang.ClassLoader抽象类中的几个重要的方法做了介绍，这里就简要叙述一下一般 用户自定义类加载器的工作流程（可以结合后面问题解答一起看）：
- 1、首先检查请求的类型是否已经被这个类装载器装载到命名空间中了，如果已经装载，直接返回；否则转入步骤2；
- 2、委派类加载请求给父类加载器（更准确的说应该是双亲类加载器，真实虚拟机中各种类加载器最终会呈现树状结构），如果父类加载器能够完成，则返回父类加载器加载的Class实例；否则转入步骤3；
- 3、调用本类加载器的findClass（…）方法，试图获取对应的字节码。如果获取的到，则调用defineClass（…）导入类型到方法区；如果获取不到对应的字节码或者其他原因失败,向上抛异常给loadClass（…）， loadClass（…）转而调用findClass（…）方法处理异常，直至完成递归调用。
必须指出的是，这里所说的自定义类加载器是指JDK1.2以后版本的写法，即不覆写改变java.lang.loadClass(…)已有委派逻辑情况下。整个加载类的过程如下图：
4.常见问题分析
1、由不同的类加载器加载的指定类还是相同的类型吗？
**在Java中，一个类用其完全匹配类名(fully qualified class name)作为标识，这里指的完全匹配类名包括包名和类名。但在JVM中，一个类用其 全名 和 一个ClassLoader的实例 作为唯一标识，不同类加载器加载的类将被置于不同的命名空间。**我们可以用两个自定义类加载器去加载某自定义类型（注意不要将自定义类型的字节码放置到系统路径或者扩展路径中，否则会被系统类加载器或扩展类加载器抢先加载），然后用获取到的两个Class实例进行java.lang.Object.equals（…）判断，将会得到不相等的结果，如下所示：
public class TestBean {
public static void main(String[] args) throws Exception {
// 一个简单的类加载器，逆向双亲委派机制
// 可以加载与自己在同一路径下的Class文件
ClassLoader myClassLoader = new ClassLoader() {
@Override
public Class<?> loadClass(String name)
throws ClassNotFoundException {
try {
String filename = name.substring(name.lastIndexOf(".") + 1)
+ ".class";
InputStream is = getClass().getResourceAsStream(filename);
if (is == null) {
return super.loadClass(name); // 递归调用父类加载器
}
byte[] b = new byte[is.available()];
is.read(b);
return defineClass(name, b, 0, b.length);
} catch (Exception e) {
throw new ClassNotFoundException(name);
}
}
};
Object obj = myClassLoader.loadClass("classloader.test.bean.TestBean")
.newInstance();
System.out.println(obj.getClass());
System.out.println(obj instanceof classloader.test.bean.TestBean);
}
}/* Output:
class classloader.test.bean.TestBean
false
*///:~
我们发现，obj 确实是类classloader.test.bean.TestBean实例化出来的对象，但当这个对象与类classloader.test.bean.TestBean做所属类型检查时却返回了false。这是因为虚拟机中存在了两个TestBean类，一个是由系统类加载器加载的，另一个则是由我们自定义的类加载器加载的，虽然它们来自同一个Class文件，但依然是两个独立的类，因此做所属类型检查时返回false。
2、在代码中直接调用Class.forName(String name)方法，到底会触发那个类加载器进行类加载行为？
**Class.forName(String name)默认会使用调用类的类加载器来进行类加载。**我们直接来分析一下对应的jdk的代码：
//java.lang.Class.java
publicstatic Class<?> forName(String className) throws ClassNotFoundException {
return forName0(className, true, ClassLoader.getCallerClassLoader());
}
//java.lang.ClassLoader.java
// Returns the invoker's class loader, or null if none.
static ClassLoader getCallerClassLoader() {
// 获取调用类（caller）的类型
Class caller = Reflection.getCallerClass(3);
// This can be null if the VM is requesting it
if (caller == null) {
return null;
}
// 调用java.lang.Class中本地方法获取加载该调用类（caller）的ClassLoader
return caller.getClassLoader0();
}
//java.lang.Class.java
//虚拟机本地实现，获取当前类的类加载器，前面介绍的Class的getClassLoader()也使用此方法
native ClassLoader getClassLoader0();
延伸：Reflection的getCallerClass的使用
Reflection的getCallerClass的使用：可以得到调用者的类.
0 和小于0 - 返回 Reflection类
1 - 返回自己的类
2 - 返回调用者的类
-
- …层层上传。
package lee;
import sun.reflect.Reflection;
public class Test
{
public static void main(String[] args)
{
Test2 test=new Test2();
test.g();
}
}
class Test2
{
public void g(){
gg();
}
public void gg(){
System.out.println("-1 : "+Reflection.getCallerClass(-1));
System.out.println("0 : "+Reflection.getCallerClass(0));
System.out.println("1 : "+Reflection.getCallerClass(1));
System.out.println("2 : "+Reflection.getCallerClass(2));
System.out.println("3 : "+Reflection.getCallerClass(3));
System.out.println("4 : "+Reflection.getCallerClass(4));
System.out.println("5 : "+Reflection.getCallerClass(5));
}
}
-1 : class sun.reflect.Reflection
0 : class sun.reflect.Reflection
1 : class lee.Test2
2 : class lee.Test2
3 : class lee.Test
4 : null
5 : null
3、在编写自定义类加载器时，如果没有设定父加载器，那么父加载器是谁？
**前面讲过，在不指定父类加载器的情况下，默认采用系统类加载器。**可能有人觉得不明白，现在我们来看一下JDK对应的代码实现。众所周知，我们编写自定义的类加载器直接或者间接继承自java.lang.ClassLoader抽象类，对应的无参默认构造函数实现如下：
//摘自java.lang.ClassLoader.java
protected ClassLoader() {
SecurityManager security = System.getSecurityManager();
if (security != null) {
security.checkCreateClassLoader();
}
this.parent = getSystemClassLoader();
initialized = true;
}
我们再来看一下对应的getSystemClassLoader()方法的实现：
private static synchronized void initSystemClassLoader() {
//...
sun.misc.Launcher l = sun.misc.Launcher.getLauncher();
scl = l.getClassLoader();
//...
}
我们可以写简单的测试代码来测试一下：
System.out.println(sun.misc.Launcher.getLauncher().getClassLoader());
本机对应输出如下：
[email protected]
所以，我们现在可以相信当自定义类加载器没有指定父类加载器的情况下，默认的父类加载器即为系统类加载器。
Ps:更多关于自定义类加载器待学习后面将陆续发出来。对象创建过程的后面内容将在《JVM学习笔记（七）对象创建过程（下）》中发布。链接：https://blog.csdn.net/qq_37692087/article/details/84674597