java类加载器原理

A. java 类加载机制有什么用

AVA类加载机制详解

“代码编译的结果从本地机器码转变为字节码，是存储格式发展的一小步，却是变成语言发展的一大步”，这句话出自《深入理解JAVA虚拟机》一书，后面关于jvm的系列文章主要都是参考这本书。

JAVA源码编译由三个过程组成：

1、源码编译机制。

2、类加载机制

3、类执行机制

我们这里主要介绍编译和类加载这两种机制。

一、源码编译

代码编译由JAVA源码编译器来完成。主要是将源码编译成字节码文件（class文件）。字节码文件格式主要分为两部分：常量池和方法字节码。

二、类加载

类的生命周期是从被加载到虚拟机内存中开始，到卸载出内存结束。过程共有七个阶段，其中到初始化之前的都是属于类加载的部分

加载----验证----准备----解析-----初始化----使用-----卸载

系统可能在第一次使用某个类时加载该类，也可能采用预加载机制来加载某个类，当运行某个java程序时，会启动一个java虚拟机进程，两次运行的java程序处于两个不同的JVM进程中，两个jvm之间并不会共享数据。

1、加载阶段

这个流程中的加载是类加载机制中的一个阶段，这两个概念不要混淆，这个阶段需要完成的事情有：

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

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

3）在java堆中生成一个代表这个类的Class对象，作为访问方法区中这些数据的入口。

由于第一点没有指明从哪里获取以及怎样获取类的二进制字节流，所以这一块区域留给我开发者很大的发挥空间。这个我在后面的类加载器中在进行介绍。

2、准备阶段

这个阶段正式为类变量（被static修饰的变量）分配内存并设置类变量初始值，这个内存分配是发生在方法区中。

1、注意这里并没有对实例变量进行内存分配，实例变量将会在对象实例化时随着对象一起分配在JAVA堆中。

2、这里设置的初始值，通常是指数据类型的零值。

private static int a = 3;

这个类变量a在准备阶段后的值是0，将3赋值给变量a是发生在初始化阶段。

3、初始化阶段

初始化是类加载机制的最后一步，这个时候才正真开始执行类中定义的JAVA程序代码。在前面准备阶段，类变量已经赋过一次系统要求的初始值，在初始化阶段最重要的事情就是对类变量进行初始化，关注的重点是父子类之间各类资源初始化的顺序。

java类中对类变量指定初始值有两种方式：1、声明类变量时指定初始值；2、使用静态初始化块为类变量指定初始值。

初始化的时机

1）创建类实例的时候，分别有：1、使用new关键字创建实例；2、通过反射创建实例；3、通过反序列化方式创建实例。

new Test();
Class.forName(“com.mengdd.Test”);

2）调用某个类的类方法（静态方法）

Test.doSomething();

3）访问某个类或接口的类变量，或为该类变量赋值。

int b=Test.a;
Test.a=b;

4）初始化某个类的子类。当初始化子类的时候，该子类的所有父类都会被初始化。

5）直接使用java.exe命令来运行某个主类。

除了上面几种方式会自动初始化一个类，其他访问类的方式都称不会触发类的初始化，称为被动引用。

1、子类引用父类的静态变量，不会导致子类初始化。

执行结果：

MIGU

用final修饰某个类变量时，它的值在编译时就已经确定好放入常量池了，所以在访问该类变量时，等于直接从常量池中获取，并没有初始化该类。

初始化的步骤

1、如果该类还没有加载和连接，则程序先加载该类并连接。

2、如果该类的直接父类没有加载，则先初始化其直接父类。

3、如果类中有初始化语句，则系统依次执行这些初始化语句。

在第二个步骤中，如果直接父类又有直接父类，则系统会再次重复这三个步骤来初始化这个父类，依次类推，JVM最先初始化的总是java.lang.Object类。当程序主动使用任何一个类时，系统会保证该类以及所有的父类都会被初始化。

B. java工作原理

Java工作原理
由四方面组成：

（1）Java编程语言
（2）Java类文件格式
（3）Java虚拟机
（4）Java应用程序接口
当编辑并运行一个Java程序时，需要同时涉及到这四种方面。使用文字编辑软件（例如记事本、写字板、UltraEdit等）或集成开发环境（Eclipse、MyEclipse等）在Java源文件中定义不同的类 ，通过调用类（这些类实现了Java API）中的方法来访问资源系统，把源文件编译生成一种二进制中间码，存储在class文件中，然后再通过运行与操作系统平台环境相对应的Java虚拟机来运行class文件，执行编译产生的字节码，调用class文件中实现的方法来满足程序的Java API调用 。

C. java中类加载器是怎么工作的

JVM将类加载过程分为三个步骤：装载（Load），链接（Link）和初始化(Initialize)
链接又分为三个步骤，验证、准备、解析
1) 装载：查找并加载类的二进制数据；
2)链接：
验证：确保被加载类的正确性；
准备：为类的静态变量分配内存，并将其初始化为默认值；
解析：把类中的符号引用转换为直接引用；
3)初始化：为类的静态变量赋予正确的初始值；
那为什么我要有验证这一步骤呢？首先如果由编译器生成的class文件，它肯定是符合JVM字节码格式的，但是万一有高手自己写一个class文件，让JVM加载并运行，用于恶意用途，就不妙了，因此这个class文件要先过验证这一关，不符合的话不会让它继续执行的，也是为了安全考虑吧。
准备阶段和初始化阶段看似有点牟盾，其实是不牟盾的，如果类中有语句：private static int a = 10，它的执行过程是这样的，首先字节码文件被加载到内存后，先进行链接的验证这一步骤，验证通过后准备阶段，给a分配内存，因为变量a是static的，所以此时a等于int类型的默认初始值0，即a=0,然后到解析（后面在说），到初始化这一步骤时，才把a的真正的值10赋给a,此时

D. java虚拟机工作原理

从宏观上介绍一下Java虚拟机的工作原理。从最初编写的Java源文件（.java文件）是如何一步步执行的，如下图所示，首先Java源文件经过前端编译器（javac或ECJ）将.java文件编译为Java字节码文件，然后JRE加载Java字节码文件，载入系统分配给JVM的内存区，然后执行引擎解释或编译类文件，再由即时编译器将字节码转化为机器码。主要介绍下图中的类加载器和运行时数据区两个部分。

E. java解释器如何加载类

类加载次序：1、静态代码块或者静态方法－>2、main方法调用到的方法
对象加载次序:1、静态代码块或者静态方法－>2、非静态代码块或者非静态方法－>3、对象的构造方法。
但是有一段代码没有办法解释。代码忘了，过段时间丢上来
个人感觉应该好像不大对劲，我觉得应该是:
类装载时，1、静态代码块或者静态方法被调用
然后是程序的运行，main调用到的方法会被执行，如果是新建一个对象，则
2、非静态代码块或者非静态方法－>3、对象的构造方法顺序执行。

===============================================

首先我们要分析类加载原理，java中默认有三种类加载器：引导类加载器，扩展类加载器，系统类加载器(也叫应用类加载器)引导类加载器负责加载jdk中的系统类，这种类加载器都是用c语言实现的，在java程序中没有办法获得这个类加载器，对于java程序是一个概念而已，基本上不用考虑它的存在，像String,Integer这样的类都是由引导类加载器加载器的.
扩展类加载器负责加载标准扩展类，一般使用java实现，这是一个真正的java类加载器，负责加载jre/lib/ext中的类，和普通的类加载器一样，其实这个类加载器对我们来说也不是很重要，我们可以通过java程序获得这个类加载器。
系统类加载器，加载第一个应用类的加载器(其实这个定义并不准确,下面你将会看到)，也就是执行java MainClass 时加载MainClass的加载器，这个加载器使用java实现，使用的很广泛，负责加载classpath中指定的类。

类加载器之间有一定的关系(父子关系)，我们可以认为扩展类加载器的父加载器是引导类加载器(当然不这样认为也是可以的，因为引导类加载器表现在java中就是一个null),不过系统类加载器的父加载器一定是扩展类加载器，类加载器在加载类的时候会先给父加载器一个机会，只有父加载器无法加载时才会自己去加载。

我们无法获得引导类加载器，因为它是使用c实现的，而且使用引导类加载器加载的类通过getClassLoader方法返回的是null.所以无法直接操作引导类加载器，但是我们可以根据Class.getClassLoader方法是否为null判断这个类是不是引导类加载器加载的，可以通过下面的方法获得引导类加载器加载的类路径(每个jar包或者文件夹对应了一个URL);
sun.misc.Launcher.getBootstrapClassPath().getURLs()
你可以直接在你的main函数中输出就可以了
System.out.println(java.util.Arrays.asList(sun.misc.Launcher.getBootstrapClassPath().getURLs()).toString());
得到的结果是：
[file:/C:/Program%20Files/Java/j2re1.4.2_10/lib/rt.jar,
file:/C:/Program%20Files/Java/j2re1.4.2_10/lib/i18n.jar,
file:/C:/Program%20Files/Java/j2re1.4.2_10/lib/sunrsasign.jar,
file:/C:/Program%20Files/Java/j2re1.4.2_10/lib/jsse.jar,
file:/C:/Program%20Files/Java/j2re1.4.2_10/lib/jce.jar,
file:/C:/Program%20Files/Java/j2re1.4.2_10/lib/charsets.jar,
file:/C:/Program%20Files/Java/j2re1.4.2_10/classes]

其实我们是可以指定引导类加载器的类路径的，java提供了一个-Xbootclasspath参数，不过这个参数不是标准参数。
java -Xbootclasspath: 运行时指定引导类加载器的加载路径(jar文件或者目录)
java -Xbootclasspath/p:和上面的相同，不过把这个路径放到原来的路径前面
java -Xbootclasspath/a:这个就是在原引导类路径后面添加类路径。
上面我们有提过加载第一个应用类未必就是系统加载器。
如果我把这个应用类的路径放到引导类路径中，它将会被引导类加载器加载，大致这样
java -Xbootclasspath/a:myjar.jar MainClass
如果MainClass在myjar.jar中,那么这个类将会被引导类加载器加载。
如果希望看详情，使用-verbose参数，为了看的更清楚，使用重定向，大致为(windows下)：
java -verbose -Xbootclasspath/a:myjar.jar MainClass -> C:\out.txt
通过这个参数我们可以实现自己的系统类，比如替换掉java.lang.Object的实现，自己可以扩展
一些方法，不过这样做似乎没有好处，因为那就不是标准了。

我们最关心的还是系统类加载器，一般都认为系统类加载器是加载应用程序第一个类的加载器，
也就是java MainClass命令中加载MainClass的类加载器，这种说法虽然不是很严谨，但基本上还是可以这样认为的，因为我们很少会改变引导类加载器和扩展类加载器的默认行为。应该说系统类加载器负责加载classpath路径中的而且没有被扩展类加载器加载的类(当然也包括引导类加载器加载的)。如果classpath中有这个类，但是这个类也在扩展类加载器的类路径，那么系统类加载器将没有机会加载它。
我们很少改变扩展类加载器的行为，所以一般你自己定义的类都是系统类加载器加载器的。

获得系统类加载器非常简单，假设MyClass是你定义的一个类
MyClass.class.getClassLoader()返回的就是系统类加载器，当然这种方法无法保证绝对正确，我们可以使用更简单而且一定正确的方式：
ClassLoader.getSystemClassLoader()获得系统类加载器。我们知道ClassLoader是一个抽象类，所以系统类加载器肯定是ClassLoader的一个子类实现。我们来看看它是什么
ClassLoader.getSystemClassLoader().getClass();
结果是class sun.misc.Lancher$AppClassLoader
可以看出这是sun的一个实现，从名字可以看出是一个内部类，目前我也没有看到这个源代码，似乎还不是很清晰：
我们在看看它的父类是什么：
ClassLoader.getSystemClassLoader().getClass().getSuperclass();
结果是：class java.net.URLClassLoader
这个是j2se的标准类，它的父类是SecureClassLoader,而SecureClassLoader是继承ClassLoader的。
现在整个关系应该很清楚，我们会看到几乎所有的ClassLoader实现都是继承URLClassLoader的。
因为系统类加载器是非常重要的，而且是我们可以直接控制的，所以我们后面还会介绍，不过先来看一下扩展类
加载器以及它们之间的关系。

扩展类加载器似乎是一个不起眼的角色，它负责加载java的标准扩展(jre/lib/ext目录下的所有jar)，它其实就是一个普通的加载器，看得见摸得着的。
首先的问题是怎么知道扩展类加载器在哪里?
的确没有直接途径获得扩展类加载器，但是我们知道它是系统类加载器的父加载器，我们已经很容易的获得系统类加载器了，所以我们可以间接的获得扩展类加载器：
ClassLoader.getSystemClassLoader().getParent().getClass();
其实是通过系统类加载器间接的获得了扩展类加载器，看看是什么东西：
结果是：class sun.misc.Launcher$ExtClassLoader
这个类和系统类加载器一样是一个内部类，而且定义在同一个类中。
同样看看它的父类是什么：
ClassLoader.getSystemClassLoader().getParent().getClass().getSuperclass();
可以看出结果也是class java.net.URLClassLoader
扩展类加载jre/lib/ext目录下的所有类，包括jar,目录下的所有类(目录名不一定要classes).
现在可以回答上面的问题了，你写一个HelloWorld，放到jre/lib/ext/下的某个目录
比如 jre/lib/ext/myclass/HelloWorld.class
然后在你classpath也设置一份到这个类的路径，结果执行java HelloWorld时，这个类是被扩展类加载器加载器的，可以这样证明
public static void main(String[] args){
System.out.println("loaded by"+HelloWorld.class.getClassLoader().getClass());
System.out.println("Hello World");
}
结果可以得到class sun.misc.Launcher$ExtClassLoader
当然如果你把jre/lib/ext下myclass这个目录删除，仍然可以运行，但是这样结果是
class sun.misc.Lancher$AppClassLoader
如果你不知道这个过程的话，假设在你扩展类路径下有一份classpath中的拷贝，或者是比较低的版本，当你使用新的版本时会发现没有起作用，知道这个过程你就不会觉得奇怪了。另外就是两个不同的类加载器是可以加载一个同名的类的，也就是说虽然扩展类加载器加载了某个类，系统类加载器是可以加载自己的版本的，
但是现有的实现都没有这样做，ClassLoader中的方法是会请求父类加载器先加载的，如果你自己定义类加载器完全可以修改这种默认行为，甚至可以让他没有父加载器。

这里给出一个方法如何获得扩展类加载器加载的路径：
String path=System.getProperty("java.ext.dirs");
File dir=new File(path);
if(!dir.exists()||!dir.isDirectory()){
return Collections.EMPTY_LIST;
}
File[] jars=dir.listFiles();
URL[] urls=new URL[jars.length];
for(int i=0;i<jars.length;i++){
urls[i]=sun.misc.URLClassPath.pathToURLs(jars[i].getAbsolutePath())[0];
}
return Arrays.asList(urls);

对于扩展类加载器我们基本上不会去关心，也很少把你自己的jar放到扩展路径，大部分情况下我们都感觉不到它的存在，当然如果你一定要放到这个目录下，一定要知道这个过程，它会优先于classpath中的类。

现在我们应该很清楚知道某个类是哪个加载器加载的，并且知道为什么是它加载的，如果要在运行时获得某个类的类加载器，直接使用Class的getClassLoader()方法就可以了。

用户定义的类一般都是系统类加载器加载的,我们很少直接使用类加载器加载类,我们甚至很少自己加载类。
因为类在使用时会被自动加载，我们用到某个类时该类会被自动加载,比如new A()会导致类A自动被加载，不过这种加载只发生一次。
我们也可以使用系统类加载器手动加载类,ClassLoader提供了这个接口
ClassLoader.getSystemClassLoader().loadClass("classFullName");
这就很明确的指定了使用系统类加载器加载指定的类,但是如果该类能够被扩展类加载器加载,系统类加载器还是不会有机会的。
我们最常用的还是使用Class.forName加载使用的类，这种方式没有指定某个特定的ClassLoader,会使用调用类的ClassLoader。
也就是说调用这个方法的类的类加载器将会用于加载这个类。比如在类A中使用Class.forName加载类B,那么加载类A的类加载器将会用于加载类B,这样两个类的类加载器是同一个。

最后讨论一下如何获得某个类加载器加载了哪些类，这个似乎有一定的使用价值，可以看出哪些类被加载了。其实这个也不是很难，因为ClassLoader中有一个classes成员变量就是用来保存类加载器加载的类列表，而且有一个方法
void addClass(Class c) { classes.addElement(c);}
这个方法被JVM调用。
我们只要利用反射获得classes这个值就可以了,不过classes声明为private的,我们需要修改它的访问权限(没有安全管理器时很容易做到)
classes = ClassLoader.class.getDeclaredField("classes");
classes.setAccessible(true);
List ret=(List) classes.get(cl); //classes是一个Vector
可惜的是对于引导类加载器没有办法获得加载的类，因为它是c实现的,在java中很难控制