作为一个程序猿,只知道怎么用是远远不够的。
起码,你须要知道为什么能够这么用。即我们所谓底层的东西。
那究竟什么是底层呢?我认为这不能一概而论。以我如今的知识水平而言:对于Web开发人员,TCP/IP、HTTP等等协议可能就是底层;对于C、C++程序猿。内存、指针等等可能就是底层的东西。那对于Java开发人员,你的Java代码执行所在的JVM可能就是你所须要去了解、理解的东西。
我会在接下来的一段时间,和读者您一起去学习JVM,全部内容均參考自《深入理解Java虚拟机:JVM高级特性与最佳实践》(第二版)。感谢作者。
系列文章第一篇:JVM系列文章(一):Java内存区域分析。
系列文章第二篇:JVM系列文章(二):垃圾回收机制。
一、什么是类载入机制
二、类载入的时机
(有点绕啊这东西)
什么时候进行初始化?有且仅仅有下面5种情况(称为对一个类进行主动引用):
1.遇到new(使用newkeyword实例化对象)、getstatic(获取一个类的静态字段,final修饰符修饰的静态字段除外)、putstatic(设置一个类的静态字段,final修饰符修饰的静态字段除外)和invokestatic(调用一个类的静态方法)这4条字节码指令时,假设类还没有初始化。则必须首先对其初始化
2.使用java.lang.reflect包中的方法对类进行反射调用时,假设类还没有初始化,则必须首先对其初始化
3.当初始化一个类时,假设其父类还没有初始化。则必须首先初始化其父类
4.当虚拟机启动时,须要指定一个主类(main方法所在的类)。虚拟机会首选初始化这个主类
5.使用JDK1.7的动态语言支持时,假设一个java.lang.invoke.MethodHandle实例最后的解析结果为REF_getStatic、REF_putstatic、REF_invokeStatic的方法句柄,而且这种方法句柄所相应的类没有进行过初始化,则须要先触发其初始化。
三、类载入的过程
1.载入
2.验证
1)文件格式验证
仅仅有通过这个阶段的验证后,字节流才会进入内存的方法区进行存储。所以后面的3个验证阶段所有是基于方法区的存储结构进行的。不会再直接操作字节流。
2)元数据验证
3)字节码验证
进行数据流和控制流分析,即对类的方法体进行校验分析以保证被校验类的方法在执行时不会做出危害虚拟机安全的行为(如:保证跳转指令不会跳转到方法体以外的字节码指令上等)
即使一个方法通过了字节码验证,也不能说明其一定是安全的(通过程序去校验程序逻辑是无法做到绝对准确的)
4)符号引用验证
3.准备
假设类字段的字段属性表中包括ConstantValue属性。那在准备阶段变量就会被初始化为ConstantValue属性所指定的值,即假设a变量定义变为public final static int a = 123;。编译时javac会为a生成ConstantValue属性,准备阶段虚拟机就会依据ConstantValue的设置将a的值置为123
。
4.解析
1)符号引用:以一组符号来描写叙述所引用的目标,符号能够是不论什么形式的字面量。仅仅要使用时能够无歧义的定位到目标就可以。
符号引用与虚拟机实现的内存布局无关,引用目标并不一定已经载入到内存中
2)直接引用:直接指向目标的指针、相对偏移量或一个能间接定位到目标的句柄,直接引用与虚拟机实现的内存布局相关,假设有了直接引用,引用目标必然已经载入到内存中
虚拟机规范并未规定解析动作发生的详细时间,仅要求在运行anewarray、checkcast、getfield、getstatic、instanceof、invokeinterface、invokespecial、invokestatic、invokevirtual、multianewarray、new、putfield和putstatic这13个用于操作符号引用的字节码指令之前,先对它们所使用的符号引用进行解析。
而在类装载器装载People类时,此时能够通过虚拟机获取Tool类 的实际内存地址,因此便能够既将符号org.simple.Tool替换为Tool类的实际内存地址,及直接引用地址。
5.初始化
四、类载入器
实现这个动作的代码模块称为类载入器。
即比較两个类是否“相等”,仅仅有在这两个类是由同一个类载入器载入的前提下才有意义。“相等”包含代表类的Class对象的equals()方法、isAssinableFrom()方法、isInstance()方法的返回结果,也包含使用instanceofkeyword做对象所属关系判定等情况。
双亲委派模型
开发人员能够直接使用。
工作过程:
假设一个类载入器收到了类载入的请求,它首先不会自己去尝试载入这个类。而是把这个请求委派给父类载入器去完毕,每个层次的类载入器都是如此,因此全部的载入请求终于都应该传递到顶层的启动类载入器中,仅仅有当父类载入器反馈自己无法完毕这个请求(它的搜索范围中没有找到所需的类)时,子载入器才会尝试自己去载入。
能够看一下ClassLoader类中的loadClassInternal方法,虚拟机调用该方法载入类:
plaincopy
- // This method is invoked by the virtual machine to load a class.
- private synchronized Class loadClassInternal(String name)
- throws ClassNotFoundException{
- return loadClass(name);
- }
- //Invoking this method is equivalent to invoking loadClass(name,false).
- public Class<?> loadClass(String name) throws ClassNotFoundException {
- return loadClass(name, false);
- }
- //Subclasses of ClassLoader are encouraged to override findClass(String),
- //rather than this method.
- protected synchronized Class<?> loadClass(String name, boolean resolve)
- throws ClassNotFoundException{
- // First, check if the class has already been loaded
- Class c = findLoadedClass(name);
- if (c == null) {
- try {
- 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.
- c = findClass(name);
- }
- }
- if (resolve) {
- resolveClass(c); }
- return c;
- }
通过loadClass方法的源码能够看出,类载入器会先检查类是否已经被载入过。假设没有载入过则调用父类载入器载入该类(假设父类载入器为空则默认使用启动类载入器作为父类载入器)。假设父类载入器载入失败。调用自己的findClass方法进行载入
比起重写loadClass方法,JDK更推荐通过重写findClass方法实现自己定义类载入器(详见备注1)
来看看JDK对findClass方法的描写叙述:
plaincopy
- /**
- * Finds the class with the specified binary name.
- * This method should be overridden by class loader implementations that
- * follow the delegation model for loading classes, and will be invoked by
- * the loadClass method after checking the parent class loader
- * for the requested class. The default implementation
- * throws a ClassNotFoundException.
- *
- * @param name
- * The binary name of the class
- *
- * @return The resulting Class object
- *
- * @throws ClassNotFoundException
- * If the class could not be found
- *
- * @since 1.2
- */
- protected Class<?
> findClass(String name) throws ClassNotFoundException {
- throw new ClassNotFoundException(name);
- }
对loadClass方法中的resolveClass方法也比較好奇。顺带查看了下这种方法的作用:
plaincopy
- /**Links the specified class. This (misleadingly named) method may be
- * used by a class loader to link a class. If the class has already
- * been linked, then this method simply returns. Otherwise, the class
- * is linked as described in the "Execution" chapter of the Java Language
- * Specification.
- */
- protected final void resolveClass(Class<?> c) {
- resolveClass0(c);
- }
- private native void resolveClass0(Class c);
能够发现虚拟机将调用该方法完毕类的连接过程,类的连接过程详见:http://blog.csdn.net/a19881029/article/details/17068191
查看ClassLoader类的源码会发现非常多方法是通过调用本地方法(native修饰符修饰的方法)的方式实现的
使用双亲委派模型组织类载入器之间的关系的优点是:Java类随着它的类载入器一起具备了一种带有优先级的层次关系。
比如:java.lang.Object类。它存放在rt.jar中,不管哪一个类载入器要载入这个类。终于都会委派给启动类载入器进行载入,启动类载入器在其搜索范围内能够搜索到的仅仅有rt.jar中的java.lang.Object类(详见备注2),这样能够保证Object类始终由启动类载入器从rt.jar中的java.lang.Object载入得到,确保了Object类的唯一性(详见备注3)
假设没有使用双亲委派模型,由各个类载入器自行载入的话。假设用户自己实现一个名为java.lang.Object类,并用自己定义的类载入器进行载入,系统中将出现多个不同的Object类,Java类型体系中最基础的行为将无法保证,应用程序也将变得一片混乱
备注:
1。为什么JDK不推荐通过重写loadClass方法实现自己定义类载入器?
通过重写findClass方法实现自己定义类载入器:当调用loadClass方法载入类时,因为自己定义类载入器没有重写loadClass方法,实际调用的是ClassLoader类的loadClass方法,该方法保证假设父类可以载入所需载入的类,则把载入动作托付给父类完毕,当全部父类都无法完毕载入动作时,才把载入动作交由自己定义类载入器的findClass方法完毕,全然符合Java类载入器双亲委派模型的设计思路
通过重写loadClass方法实现自己定义类载入器:当调用loadClass方法载入类时,将直接调用自己定义类载入器中重写的loadClass方法完毕载入动作,假设重写的loadClass方法中没有实现首先尝试将载入动作托付给父类完毕这一过程。将打破双亲委派模型的设计思路,设计是能够被打破的,可是须要更好的理由(JDBC。JNDI就打破了双亲委派模型)
当然,假设在重写的loadCLass方法中首先尝试让父类载入器完毕载入过程。则本质上也是没有没有问题的,仅仅是依旧别扭罢了,首先就是为什么不使用现成的实现?其次假设父类载入器无法完毕载入动作。还是要把载入过程托付给自己定义类载入器的findClass方法,关键问题是,在ClassLoader类中,findClass是一个空方法,也就是说你还是得重写自己的findClass方法。绕了一大圈,又回来了,除非你能确定父类载入器可以完毕载入动作,这时将不会调用自己定义类载入器的findClass方法。只是这样一来,你为什么要实现自己的类载入器?综上。使用重写findClass方法实现自己定义的类载入器就对了,只是以下依旧尝试了一下通过重写loadClass方法实现自己定义类载入器:
plaincopy
- //-XX:+TraceClassLoading
- public class MyClassLoader extends ClassLoader{
- @Override
- public Class<?> loadClass(String name) throws ClassNotFoundException {
- return super.loadClass(name);
- }
- @Override
- public Class<?> findClass(String name) throws ClassNotFoundException {
- System.out.println("Use myclassloader findClass method.");
- //name = com.test.Test
- //fileName = Test.class
- String fileName = name.substring(name.lastIndexOf(".")+1)+".class";
- byte[] bytes = loadClassData("e:\\"+fileName);
- return defineClass(name, bytes, 0, bytes.length);
- }
- public byte[] loadClassData(String name) {
- try {
- FileInputStream fileInput = new FileInputStream(new File(name));
- ByteArrayOutputStream bytesOutput = new ByteArrayOutputStream();
- int b = 0;
- while ((b = fileInput.read()) != -1) {
- bytesOutput.write(b);
- }
- return bytesOutput.toByteArray();
- } catch (Exception e) {
- e.printStackTrace();
- }
- return null;
- }
- public static void main(String[] args){
- MyClassLoader myClassLoader = new MyClassLoader();
- try {
- Class<?
extends Object> testClass = myClassLoader.loadClass("com.test.Test");
- Object obj = testClass.newInstance();
- System.out.println(obj.getClass().getName());
- System.out.println(obj.hashCode());
- } catch (Exception e) {
- e.printStackTrace();
- }
- }
- }
还是将Test.class文件放置在e盘下:
plaincopy
- ......
- Use myclassloader findClass method.
- [Loaded java.io.ByteArrayOutputStream from shared objects file]
- [Loaded com.test.Test from __JVM_DefineClass__]
- com.test.Test
- 827574
- ......
当然假设Test.class文件与MyCLassLoader.class文件放置在同一个路径下,应用程序类载入器(也就是MyClassLoader类载入器的父类载入器)将完毕Test类的载入动作,此时不会跳进MyClassLoader类的findClass方法,执行结果例如以下:
plaincopy
- ......
- [Loaded com.test.Test from file:/E:/eclipseProject/jvm/bin/]
- com.test.Test
- 21174459
- ......
2,在自己定义类载入器中。使用defineClass方法载入一个我自己实现的java.lang.Object类
plaincopy
- package java.lang;
- public class Object {
- public Object(){}
- }
执行时抛出以下的异常(被禁止的包名称):
plaincopy
- java.lang.SecurityException: Prohibited package name: java.lang
其实,载入全部以"java."开头的类都会抛出这个异常,这应该是出于JDK对其自身实现的基础类的保护
plaincopy
- ......
- if ((name != null) && name.startsWith("java.")) {
- throw new SecurityException("Prohibited package name: " +
- name.substring(0, name.lastIndexOf('.')));
- }
- ......
3,比較2个类是否相等,仅仅有在这两个类是由同一个类载入器载入的前提之下才有意义,否则,即使这2个类是源于同一个Class文件。仅仅要载入它们的类载入器不同,这2个类必然不相等(个人觉得这是非常easy理解的,同一个Class文件被2个不同的Java进程载入所产生的2个类肯定是不同的。推断2个类相等,终于推断的还是其指向的已分配内存区是否为同一个,对于2个独立的Java进程。其使用的内存空间是没有交集的)