作为一个程序员,仅仅知道怎么用是远远不够的。起码,你需要知道为什么可以这么用,即我们所谓底层的东西。
那到底什么是底层呢?我觉得这不能一概而论。以我现在的知识水平而言:对于Web开发者,TCP/IP、HTTP等等协议可能就是底层;对于C、C++程序员,内存、指针等等可能就是底层的东西。那对于Java开发者,你的Java代码运行所在的JVM可能就是你所需要去了解、理解的东西。
我会在接下来的一段时间,和读者您一起去学习JVM,所有内容均参考自《深入理解Java虚拟机:JVM高级特性与最佳实践》(第二版),感谢作者。
系列文章第一篇:JVM系列文章(一):Java内存区域分析。
系列文章第二篇:JVM系列文章(二):垃圾回收机制。
一、什么是类加载机制
二、类加载的时机
什么时候进行初始化?有且只有以下5种情况(称为对一个类进行主动引用):
1.遇到new(使用new关键字实例化对象)、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)文件格式验证
2)元数据验证
3)字节码验证
进行数据流和控制流分析,即对类的方法体进行校验分析以保证被校验类的方法在运行时不会做出危害虚拟机安全的行为(如:保证跳转指令不会跳转到方法体以外的字节码指令上等)
即使一个方法通过了字节码验证,也不能说明其一定是安全的(通过程序去校验程序逻辑是无法做到绝对准确的)
4)符号引用验证
3.准备
4.解析
1)符号引用:以一组符号来描述所引用的目标,符号可以是任何形式的字面量,只要使用时可以无歧义的定位到目标即可。符号引用与虚拟机实现的内存布局无关,引用目标并不一定已经加载到内存中
2)直接引用:直接指向目标的指针、相对偏移量或一个能间接定位到目标的句柄,直接引用与虚拟机实现的内存布局相关,如果有了直接引用,引用目标必定已经加载到内存中
虚拟机规范并未规定解析动作发生的具体时间,仅要求在执行anewarray、checkcast、getfield、getstatic、instanceof、invokeinterface、invokespecial、invokestatic、invokevirtual、multianewarray、new、putfield和putstatic这13个用于操作符号引用的字节码指令之前,先对它们所使用的符号引用进行解析。5.初始化
四、类加载器
双亲委派模型
工作过程:
如果一个类加载器收到了类加载的请求,它首先不会自己去尝试加载这个类,而是把这个请求委派给父类加载器去完成,每一个层次的类加载器都是如此,因此所有的加载请求最终都应该传递到顶层的启动类加载器中,只有当父类加载器反馈自己无法完成这个请求(它的搜索范围中没有找到所需的类)时,子加载器才会尝试自己去加载。
可以看一下ClassLoader类中的loadClassInternal方法,虚拟机调用该方法加载类:
- // 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方法的描述:
- /**
- * 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方法也比较好奇,顺带查看了下这个方法的作用:
- /**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方法实现自定义类加载器:
- //-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盘下:
- ......
- 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方法,运行结果如下:
- ......
- [Loaded com.test.Test from file:/E:/eclipseProject/jvm/bin/]
- com.test.Test
- 21174459
- ......
2,在自定义类加载器中,使用defineClass方法加载一个我自己实现的java.lang.Object类
- package java.lang;
- public class Object {
- public Object(){}
- }
运行时抛出下面的异常(被禁止的包名称):
- java.lang.SecurityException: Prohibited package name: java.lang
事实上,加载所有以"java."开头的类都会抛出这个异常,这应该是出于JDK对其自身实现的基础类的保护
- ......
- if ((name != null) && name.startsWith("java.")) {
- throw new SecurityException("Prohibited package name: " +
- name.substring(0, name.lastIndexOf('.')));
- }
- ......
3,比较2个类是否相等,只有在这两个类是由同一个类加载器加载的前提之下才有意义,否则,即使这2个类是源于同一个Class文件,只要加载它们的类加载器不同,这2个类必定不相等(个人认为这是很容易理解的,同一个Class文件被2个不同的Java进程加载所产生的2个类肯定是不同的。判断2个类相等,最终判断的还是其指向的已分配内存区是否为同一个,对于2个独立的Java进程,其使用的内存空间是没有交集的)