前言：

2.类加载过程

加载是类加载(Class Loading)过程的一个阶段。

1).通过一个类的全名来获取定义此类的二进制字节流。

2).将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。

3).在内存中生成一个代表这个类的java.lang.Class 对象，作为方法区这个类的各种数据的访问入口。

Java并没有指明二进制字节流要从一个Class文件中获取

• 从ZIP包中读取，JAR,WAR,EAR格式的基础
• 从网络中获取，Applet应用
• 运行时计算生成，动态代理技术，java.lang.reflect.Proxy
• 由其他文件生成，JSP应用，由JSP文件生成对应的Class类

非数组类的加载：

可以使用系统提供的引导类加载器来完成，也可以由用户自定义的类加载器去完成，开发人员可以通过定义自己的类加载器去控制字节流的获取方式(重写类加载器的loadClass()方法)

数组类的加载：

数组类本身不通过类加载器创建，由Java虚拟机直接创建。但数组类与类加载器仍然有很密切的关系，因为数组类的元素类型（Element Type,数组去掉所有维度的类型，即：数组中存储的数据类型）最终要靠类加载器去创建。

数组类的创建过程遵循以下规则：

• 如果数组的组件类型(Component Type,指数组去掉一个维度的类型)是引用类型，那就递归采用上面定义的加载过程去加载这个组件类型，数组将在该类加载器的类名称空间上被标识。
• 如果数组的组件类型不是引用类型（如int[]数组），Java虚拟机将会把数组标记为与引导类加载器关联。
• 数组类的可见性与它的组件类型的可见性一致，如果组件类型不是引用类型，那数组类的可见性将默认为public。

加载阶段完成后，虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区之中，方法区中的数据存储格式由虚拟机实现自行定义。然后在内存中实例化一个java.lang.Class类的对象（虽然是对象，但是存放在方法区里面），作为程序访问方法区中的这些类型数据的外部接口。

加载阶段与连接阶段的部分内容是交叉进行的，加载没完成，连接阶段可能已经开始。但是两个阶段的开始时间仍然保持着固定的先后顺序。

是连接阶段的第一步，确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。

如果验证到输入的字节流不符合Class文件格式的约束，虚拟机就会抛出java.lang.VerifyError异常或其子类异常。

验证阶段大致分下面4个动作：

1.文件格式验证

验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理。

• 魔数是否以0xCAFEBABE开头
• 主，次版本号是否在当前虚拟机处理范围之内
• 常量池的常量中是否有不被支持的常量类型
• 指向常量的各种索引值中是否有指向不存在的常量或不符合类型的常量
• CONSTANT_Utf8_info型的常量中是否有不符合UTF8编码的数据
• Class文件中各个部分及文件本身是否有被删除的或附加的其他信息

通过了这个阶段的验证后，字节流才会进入内存的方法区中进行存储。后面就会基于方法区的存储结构进行验证，不直接操作字节流了。

2.元数据验证

• 类是否有父类(除了java.lang.Object外，所有类都应当有父类)
• 类的父类是否继承了不允许被继承的类（final修饰的类）
• 如果类不是抽象类，是否实现了器父类或接口中要求实现的所有方法
• 类中的字段，方法是否与父类产生矛盾(如：覆盖了父类的final字段)

3.字节码验证

是整个验证过程中最复杂的一个阶段，主要目的是通过数据流和控制流分析，确定程序语义是合法的。对类的方法体进行校验分析，保证被校验类的方法在运行时不会做出危害虚拟机安全的事件，如：

• 保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作，不会出现例如：在操作栈放置了一个int类型，使用时却按long类型来加载入本地变量表中。
• 保证跳转指令不会跳转到方法体以外的字节码指令上
• 保证方法体中的类型转换是有效的。

4.符号引用验证

在虚拟机将符号引用转化为直接引用时发生，转化动作在--解析阶段发生。符号引用验证可以看做是对类自身以外(常量池中的各种符号引用)的信息进行匹配性校验

• 符号引用中通过字符串描述的全限定名是否能找到对应的类。
• 在指定类中是否存在符合方法的字段描述以及简单名称所描述的方法和字段。
• 符号引用中的类，字段，方法的访问性（private,protected,public,default）是否可被当前类访问。

符号引用验证的目的就是确保解析动作能正常执行，如果无法通过就会抛出异常，如：java.lang.NoSuchMethodError

注意：

验证阶段是非常重要的，但不是一定必要的阶段（对程序运行期没有影响），如果运行的全部代码都被反复使用和验证过，那么在实施阶段可以考虑通过参数-Xverify:none 来关闭类验证措施，以缩短虚拟机类加载的时间。

正式为类变量分配内存并设置类变量初始化的阶段，这些变量所使用的内存当将在方法区中进行分配。只对类变量进行内存分配(static修饰)，不包括实例变量。

初始值为数据类型的零值，如：

public static int  value = http://www.mamicode.com/123;

准备阶段后为0，在类初始化后value才被赋值为123。

特殊情况：

public static final int value = http://www.mamicode.com/123;

编译时Javac将会为value生成ConstantValue属性，在准备阶段就会根据ConstantValue将value值设置为123。

将常量池内的符号引用替换为直接引用。

• 符号引用(Symbolic References)：符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关，引用的目标并不一定已经加载到内存中。符号引用的字面量形式已经明确定义在Java虚拟机规范的Class文件格式中。
• 直接引用(Direct References)：直接引用可以是直接指向目标的指针，相对偏移量或是一个能间接定位到目标的句柄。直接引用与虚拟机实现的内存布局相关，同一个符号引用在不用虚拟机实例上翻译出来的直接引用一般不同。如果有了直接引用，那引用的目标必定已经在内存中存在。

前面类的加载过程中，除了在加载阶段用户应用程序可以通过自定义类加载器参与外，其余动作完全由虚拟机主导和控制。到了初始化阶段，才真正开始执行类中定义的Java程序代码。

准备阶段，变量会赋一次初始值，在初始化阶段，会根据程序员的计划去初始化类变量和其他资源。即执行类构造器<clinit>()方法的过程。

• <clinit>()方法由编译器自动收集类中的所有类变量的赋值动作和静态语句块(static{})中的语句合并产生。执行顺序就是源文件中语句的顺序。定义在静态语句块后的变量，静态语句块可以赋值但不能访问。如：

public class TestClass {

	static {
		i = 0;// 可以正常编译通过
		// System.out.println(i);报错
	}
	static int i = 1;

	public static void main(String[] args) {
		System.out.println(i);// 1
	}
}

• <clinit>()方法与类的构造函数不同，它不需要显示地调用父类构造器，虚拟机会保证在子类的<clinit>()方法执行之前，父类的<clinit>()方法已经执行完毕。因此在虚拟机中第一个被执行的<clinit>()方法的类肯定是java.lang.Object
• 由于父类的<clinit>()方法先执行，也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作。
• <clinit>()方法对于类或接口不是必需的，如果一个类没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类生成<clinit>()方法
• 接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此接口与类一样都会生成<clinit>()方法。只有当父接口中定义的变量使用时，父接口才会初始化。
• 虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确地加锁，同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的<clinit>()方法，其他线程都需要阻塞等待，直到活动线程执行<clinit>()方法完毕。如果在一个类的<clinit>()方法中有耗时很长的操作，就可能造成多个进程阻塞，在实际应用中这种阻塞是很隐蔽的。

同一个类加载器下，<clinit>()只会初始化一次。

public class DeadLoopClass {
	static {
		if (true) {// 不加if语句，编译器提示错误
			System.out.println(Thread.currentThread() + "init DeadLoopClass");
			while (true) {
			}
		}
	}
}

开启多个线程去执行DeadLoopClass的初始化：会阻塞

	public static void main(String[] args) {
		Runnable script = new Runnable() {
			@Override
			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();
	}

3.类加载器

类加载器用来实现类的加载动作。对任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。判断两个类是否"相等"，必须是在这两个类被同一个类加载器加载的前提下。

	public static void main(String[] args) {
		ClassLoader myClassLoader = new ClassLoader() {
			@Override
			public Class<?> loadClass(String name) {
				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) {
					e.printStackTrace();
				}
				return null;
			}
		};
		try {
			Object obj = myClassLoader.loadClass("com.test.JedisTest");
			System.out.println(obj.getClass());// class java.lang.Class
			System.out.println(obj instanceof com.test.JedisTest);// false
																	// 由自定义的类加载器加载的类
		} catch (ClassNotFoundException e) {
			e.printStackTrace();
		}
	}

上面虚拟机中存在了两个com.test.JedisTest类，一个由虚拟机自带的类加载器加载，一个由自定义的类加载器加载。所以做对象类型检查时返回false。

从Java虚拟机角度来讲，只存在两种不同的类加载器：一种是启动类加载器(Bootstrap ClassLoader),由C++语言实现，是虚拟机自身的一部分;另一种是所有其他的类加载器，由Java语言实现，独立于虚拟机外部，全部继承抽象类java.lang.ClassLoader

从开发人员角度来看，类加载器大致分一下三种：

• 启动类加载器(Bootstrap ClassLoader)：负责将存放在\lib目录中的，或被-Xbootclasspath参数指定的路径中的，并且是虚拟机识别的类库加载到虚拟机中。如,rt.jar。名字不符合即使放在目录中也不被加载。如果需要把加载请求委派给引导类加载器，直接使用null代替即可。
• 扩展类加载器(Extension ClassLoader)：由sum.misc.Launcher$ExtClassLoader实现，负责加载<Java_Home>\lib\ext目录中的，或者被java.ext.dir系统变量所指定的路径中的所有类库。开发者可以直接使用扩展类加载器。
• 应用程序类加载器(Application ClassLoader)：由sun.misc.Launcher$App-ClassLoader实现。是ClassLoader中的getSystemClassLoader()方法的返回值，所以也称为系统类加载器。负责加载用户路径(ClassPath)上所指定的类库，如果应用程序中没有自定义过自己的类加载器，这个就是默认的加载器，开发人员可以直接使用这个类加载器。

上图即为双亲委派模型(Parents Delegation Model)。除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。父子之间的关系不以继承实现，而是使用组合关系来复用父加载器的代码。

工作流程：如果类加载器收到类加载的请求，会先将请求委派给父类加载器完成，每一个层次的类加载器都是如此，因此所有加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈无法完成这个加载请求，子加载器才会尝试自己去加载。

好处：如类java.lang.Object，存放在rt.jar中，无论哪个类加载器要加载这个类，都会委派到启动类加载器中，所以Object类在程序的各种类加载器环境中都是同一个类。相反，如果没有使用双亲委派模型，用户自定义了一个java.lang.Object类，被加载后虚拟机中就存在多个Object类，造成混乱。

该模型对于保证Java程序的稳定运作很重要，实现也很简单。java.lang.ClassLoader.loadClass()方法中实现。

双亲委派模型并不是一个强制性的约束模型，而是Java设计者推荐给开发者的类加载器实现方式。为了向前兼容，JDK1.2之后添加了新的protected方法findClass()，在此之前，用户主要重写loadClass()方法。

双亲委派模型很好地解决了各个类加载器的基础类的统一问题。之所以称为"基础"，是因为它们总是作为被用户代码调用的API，但如果基础类要回调用户的代码怎么办？

如：JNDI服务

JNDI的目的是对资源进行集中管理和查找，需要调用由独立厂商实现并部署在应用程序的ClassPath下的JNDI接口提供者的代码。

为此，java设计引入了 线程上下文类加载器(Thread Context ClassLoader)。这个类加载器可以通过java.lang.Thread类的setContextClassLoaser()方法进行设置，如果创建线程时还未设置，将从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器。

有了上下文类加载器，JNDI服务使用这个类加载器去加载所需要的SPI代码，也就是父类加载器去请求子类加载器去完成类加载的动作，实际上打通了双亲委派模型的层次结构来逆向使用类加载器。违背了双亲委派模型的一般性原则。

jvm笔记5--虚拟机类加载机制