本文共 8910 字,大约阅读时间需要 29 分钟。
如果类没有进行过初始化,则需要先触发其初始化。虚拟机规范则是严格规定了有且只有5种情况必须立即对类进行“初始化”(而加载、验证、准备自然需要在此之前开始):
类的生命周期包括7个阶段:加载(Loading)、验证(Verification)、准备(Preparation)、解析(Resolution)、初始化(Initialization)、使用(Using)和卸载(Unloading)。其中验证、准备、解析3个部分统称为连接(Linking)。
解析阶段在某些情况下可以在初始化阶段之后再开始,这是为了支持Java语言的运行时绑定(也称为动态绑定或晚期绑定)。
(了解)接下来我们详细讲解一下Java虚拟机中类加载的全过程,也就是加载、验证、准备、解析和初始化这5个阶段所执行的具体动作。
这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求,并且不会危害虚拟机自身的安全。
准备阶段是正式为类变量分配内存并设置类变量初始值的阶段,这些变量所使用的内存都将在方法区中进行分配。
假设一个类变量的定义为:
public static int value=123;
那变量value在准备阶段过后的初始值为0而不是123,因为这时候尚未开始执行任何Java方法,而把value赋值为123的putstatic指令是程序被编译后,存放于类构造器()方法之中,所以把value赋值为123的动作将在初始化阶段才会执行。
虚拟机将常量池内的符号引用替换为直接引用的过程。
在准备阶段,变量已经赋过一次系统要求的初始值,而在初始化阶段,则根据程序员通过程序制定的主观计划去初始化类变量和其他资源,或者可以从另外一个角度来表达:初始化阶段是执行类构造器<clinit>()方法的过程。
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>()方法中有耗时很长的操作,就可能造成多个进程阻塞,在实际应用中这种阻塞往往是很隐蔽的。
类加载器可以分为:启动类加载器、扩展类加载器、应用程序类加载器、自定义类加载器。他们的关系一般如下:
这个类将器负责将存放在<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); }}
这个加载器由sun.misc.Launcher $ExtClassLoader实现,它负责加载<JAVA_HOME>\lib\ext目录中的,或者被java.ext.dirs系统变量所指定的路径中的所有类库,开发者可以直接使用扩展类加载器。
这个类加载器由sun.misc.Launcher $App-ClassLoader实现。由于这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值,所以一般也称它为系统类加载器。它负责加载用户类路径(ClassPath)上所指定的类库,开发者可以直接使用这个类加载器,如果应用程序中没有自定义过自己的类加载器,一般情况下这个就是程序中默认的类加载器。
双亲委派模型的工作过程是:如果一个类加载器收到了类加载的请求,它首先不会自己去尝试加载这个类,而是把这个请求委派给父类加载器去完成,每一个层次的类加载器都是如此,因此所有的加载请求最终都应该传送到顶层的启动类加载器中,只有当父加载器反馈自己无法完成这个加载请求(它的搜索范围中没有找到所需的类)时,子加载器才会尝试自己去加载。
使用双亲委派模型来组织类加载器之间的关系,有一个显而易见的好处就是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():遵循双亲委派机制,只有父类找不到时,才按照自己的方式加载。
先定义一个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:灵活的类加载器架构转载地址:http://qejwi.baihongyu.com/