精华内容
下载资源
问答
  • 深入理解Java类加载器(ClassLoader)

    万次阅读 多人点赞 2017-06-26 09:34:08
    【版权申明】未经博主同意,谢绝转载!(请尊重原创,博主保留追究权) ...深入理解Java类型信息(Class对象)与反射机制 深入理解Java枚举类型(enum) 深入理解Java注解类型(@Annotation) 深入理解

    【版权申明】未经博主同意,谢绝转载!(请尊重原创,博主保留追究权)
    http://blog.csdn.net/javazejian/article/details/73413292
    出自【zejian的博客】

    关联文章:

    深入理解Java类型信息(Class对象)与反射机制

    深入理解Java枚举类型(enum)

    深入理解Java注解类型(@Annotation)

    深入理解Java类加载器(ClassLoader)

    深入理解Java并发之synchronized实现原理

    Java并发编程-无锁CAS与Unsafe类及其并发包Atomic

    深入理解Java内存模型(JMM)及volatile关键字

    剖析基于并发AQS的重入锁(ReetrantLock)及其Condition实现原理

    剖析基于并发AQS的共享锁的实现(基于信号量Semaphore)

    并发之阻塞队列LinkedBlockingQueue与ArrayBlockingQueue

    本篇博文主要是探讨类加载器,同时在本篇中列举的源码都基于Java8版本,不同的版本可能有些许差异。主要内容如下

    文章目录


    #类加载的机制的层次结构
    每个编写的".java"拓展名类文件都存储着需要执行的程序逻辑,这些".java"文件经过Java编译器编译成拓展名为".class"的文件,".class"文件中保存着Java代码经转换后的虚拟机指令,当需要使用某个类时,虚拟机将会加载它的".class"文件,并创建对应的class对象,将class文件加载到虚拟机的内存,这个过程称为类加载,这里我们需要了解一下类加载的过程,如下:

    • 加载:类加载过程的一个阶段:通过一个类的完全限定查找此类字节码文件,并利用字节码文件创建一个Class对象

    • 验证:目的在于确保Class文件的字节流中包含信息符合当前虚拟机要求,不会危害虚拟机自身安全。主要包括四种验证,文件格式验证,元数据验证,字节码验证,符号引用验证。

    • 准备:为类变量(即static修饰的字段变量)分配内存并且设置该类变量的初始值即0(如static int i=5;这里只将i初始化为0,至于5的值将在初始化时赋值),这里不包含用final修饰的static,因为final在编译的时候就会分配了,注意这里不会为实例变量分配初始化,类变量会分配在方法区中,而实例变量是会随着对象一起分配到Java堆中。

    • 解析:主要将常量池中的符号引用替换为直接引用的过程。符号引用就是一组符号来描述目标,可以是任何字面量,而直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。有类或接口的解析,字段解析,类方法解析,接口方法解析(这里涉及到字节码变量的引用,如需更详细了解,可参考《深入Java虚拟机》)。

    • 初始化:类加载最后阶段,若该类具有超类,则对其进行初始化,执行静态初始化器和静态初始化成员变量(如前面只初始化了默认值的static变量将会在这个阶段赋值,成员变量也将被初始化)。

    这便是类加载的5个过程,而类加载器的任务是根据一个类的全限定名来读取此类的二进制字节流到JVM中,然后转换为一个与目标类对应的java.lang.Class对象实例,在虚拟机提供了3种类加载器,引导(Bootstrap)类加载器、扩展(Extension)类加载器、系统(System)类加载器(也称应用类加载器),下面分别介绍
    ##启动(Bootstrap)类加载器
    启动类加载器主要加载的是JVM自身需要的类,这个类加载使用C++语言实现的,是虚拟机自身的一部分,它负责将 <JAVA_HOME>/lib路径下的核心类库或-Xbootclasspath参数指定的路径下的jar包加载到内存中,注意必由于虚拟机是按照文件名识别加载jar包的,如rt.jar,如果文件名不被虚拟机识别,即使把jar包丢到lib目录下也是没有作用的(出于安全考虑,Bootstrap启动类加载器只加载包名为java、javax、sun等开头的类)。

    ##扩展(Extension)类加载器
    扩展类加载器是指Sun公司(已被Oracle收购)实现的sun.misc.Launcher$ExtClassLoader类,由Java语言实现的,是Launcher的静态内部类,它负责加载<JAVA_HOME>/lib/ext目录下或者由系统变量-Djava.ext.dir指定位路径中的类库,开发者可以直接使用标准扩展类加载器。

    //ExtClassLoader类中获取路径的代码
    private static File[] getExtDirs() {
         //加载<JAVA_HOME>/lib/ext目录中的类库
         String s = System.getProperty("java.ext.dirs");
         File[] dirs;
         if (s != null) {
             StringTokenizer st =
                 new StringTokenizer(s, File.pathSeparator);
             int count = st.countTokens();
             dirs = new File[count];
             for (int i = 0; i < count; i++) {
                 dirs[i] = new File(st.nextToken());
             }
         } else {
             dirs = new File[0];
         }
         return dirs;
     }
    
    

    ##系统(System)类加载器
    也称应用程序加载器是指 Sun公司实现的sun.misc.Launcher$AppClassLoader。它负责加载系统类路径java -classpath-D java.class.path 指定路径下的类库,也就是我们经常用到的classpath路径,开发者可以直接使用系统类加载器,一般情况下该类加载是程序中默认的类加载器,通过ClassLoader#getSystemClassLoader()方法可以获取到该类加载器。
      在Java的日常应用程序开发中,类的加载几乎是由上述3种类加载器相互配合执行的,在必要时,我们还可以自定义类加载器,需要注意的是,Java虚拟机对class文件采用的是按需加载的方式,也就是说当需要使用该类时才会将它的class文件加载到内存生成class对象,而且加载某个类的class文件时,Java虚拟机采用的是双亲委派模式即把请求交由父类处理,它一种任务委派模式,下面我们进一步了解它。
    #理解双亲委派模式

    ##双亲委派模式工作原理
    双亲委派模式要求除了顶层的启动类加载器外,其余的类加载器都应当有自己的父类加载器,请注意双亲委派模式中的父子关系并非通常所说的类继承关系,而是采用组合关系来复用父类加载器的相关代码,类加载器间的关系如下:

    双亲委派模式是在Java 1.2后引入的,其工作原理的是,如果一个类加载器收到了类加载请求,它并不会自己先去加载,而是把这个请求委托给父类的加载器去执行,如果父类加载器还存在其父类加载器,则进一步向上委托,依次递归,请求最终将到达顶层的启动类加载器,如果父类加载器可以完成类加载任务,就成功返回,倘若父类加载器无法完成此加载任务,子加载器才会尝试自己去加载,这就是双亲委派模式,即每个儿子都很懒,每次有活就丢给父亲去干,直到父亲说这件事我也干不了时,儿子自己想办法去完成,这不就是传说中的实力坑爹啊?那么采用这种模式有啥用呢?

    ##双亲委派模式优势
    采用双亲委派模式的是好处是Java类随着它的类加载器一起具备了一种带有优先级的层次关系,通过这种层级关可以避免类的重复加载,当父亲已经加载了该类时,就没有必要子ClassLoader再加载一次。其次是考虑到安全因素,java核心api中定义类型不会被随意替换,假设通过网络传递一个名为java.lang.Integer的类,通过双亲委托模式传递到启动类加载器,而启动类加载器在核心Java API发现这个名字的类,发现该类已被加载,并不会重新加载网络传递的过来的java.lang.Integer,而直接返回已加载过的Integer.class,这样便可以防止核心API库被随意篡改。可能你会想,如果我们在classpath路径下自定义一个名为java.lang.SingleInterge类(该类是胡编的)呢?该类并不存在java.lang中,经过双亲委托模式,传递到启动类加载器中,由于父类加载器路径下并没有该类,所以不会加载,将反向委托给子类加载器加载,最终会通过系统类加载器加载该类。但是这样做是不允许,因为java.lang是核心API包,需要访问权限,强制加载将会报出如下异常

    java.lang.SecurityException: Prohibited package name: java.lang
    

    所以无论如何都无法加载成功的。下面我们从代码层面了解几个Java中定义的类加载器及其双亲委派模式的实现,它们类图关系如下

    从图可以看出顶层的类加载器是ClassLoader类,它是一个抽象类,其后所有的类加载器都继承自ClassLoader(不包括启动类加载器),这里我们主要介绍ClassLoader中几个比较重要的方法。

    • loadClass(String)

      该方法加载指定名称(包括包名)的二进制类型,该方法在JDK1.2之后不再建议用户重写但用户可以直接调用该方法,loadClass()方法是ClassLoader类自己实现的,该方法中的逻辑就是双亲委派模式的实现,其源码如下,loadClass(String name, boolean resolve)是一个重载方法,resolve参数代表是否生成class对象的同时进行解析相关操作。:

      protected Class<?> loadClass(String name, boolean resolve)
            throws ClassNotFoundException
        {
            synchronized (getClassLoadingLock(name)) {
                // 先从缓存查找该class对象,找到就不用重新加载
                Class<?> c = findLoadedClass(name);
                if (c == null) {
                    long t0 = System.nanoTime();
                    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
                        // 如果都没有找到,则通过自定义实现的findClass去查找并加载
                        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;
            }
        }
      

      正如loadClass方法所展示的,当类加载请求到来时,先从缓存中查找该类对象,如果存在直接返回,如果不存在则交给该类加载去的父加载器去加载,倘若没有父加载则交给顶级启动类加载器去加载,最后倘若仍没有找到,则使用findClass()方法去加载(关于findClass()稍后会进一步介绍)。从loadClass实现也可以知道如果不想重新定义加载类的规则,也没有复杂的逻辑,只想在运行时加载自己指定的类,那么我们可以直接使用this.getClass().getClassLoder.loadClass("className"),这样就可以直接调用ClassLoader的loadClass方法获取到class对象。

    • findClass(String)
      在JDK1.2之前,在自定义类加载时,总会去继承ClassLoader类并重写loadClass方法,从而实现自定义的类加载类,但是在JDK1.2之后已不再建议用户去覆盖loadClass()方法,而是建议把自定义的类加载逻辑写在findClass()方法中,从前面的分析可知,findClass()方法是在loadClass()方法中被调用的,当loadClass()方法中父加载器加载失败后,则会调用自己的findClass()方法来完成类加载,这样就可以保证自定义的类加载器也符合双亲委托模式。需要注意的是ClassLoader类中并没有实现findClass()方法的具体代码逻辑,取而代之的是抛出ClassNotFoundException异常,同时应该知道的是findClass方法通常是和defineClass方法一起使用的(稍后会分析),ClassLoader类中findClass()方法源码如下:

      //直接抛出异常
      protected Class<?> findClass(String name) throws ClassNotFoundException {
              throw new ClassNotFoundException(name);
      }
      
    • defineClass(byte[] b, int off, int len)
      defineClass()方法是用来将byte字节流解析成JVM能够识别的Class对象(ClassLoader中已实现该方法逻辑),通过这个方法不仅能够通过class文件实例化class对象,也可以通过其他方式实例化class对象,如通过网络接收一个类的字节码,然后转换为byte字节流创建对应的Class对象,defineClass()方法通常与findClass()方法一起使用,一般情况下,在自定义类加载器时,会直接覆盖ClassLoader的findClass()方法并编写加载规则,取得要加载类的字节码后转换成流,然后调用defineClass()方法生成类的Class对象,简单例子如下:

      protected Class<?> findClass(String name) throws ClassNotFoundException {
      	  // 获取类的字节数组
            byte[] classData = getClassData(name);  
            if (classData == null) {
                throw new ClassNotFoundException();
            } else {
      	      //使用defineClass生成class对象
                return defineClass(name, classData, 0, classData.length);
            }
        }
      

    需要注意的是,如果直接调用defineClass()方法生成类的Class对象,这个类的Class对象并没有解析(也可以理解为链接阶段,毕竟解析是链接的最后一步),其解析操作需要等待初始化阶段进行。

    • resolveClass(Class≺?≻ c)
      使用该方法可以使用类的Class对象创建完成也同时被解析。前面我们说链接阶段主要是对字节码进行验证,为类变量分配内存并设置初始值同时将字节码文件中的符号引用转换为直接引用。

    上述4个方法是ClassLoader类中的比较重要的方法,也是我们可能会经常用到的方法。接看SercureClassLoader扩展了 ClassLoader,新增了几个与使用相关的代码源(对代码源的位置及其证书的验证)和权限定义类验证(主要指对class源码的访问权限)的方法,一般我们不会直接跟这个类打交道,更多是与它的子类URLClassLoader有所关联,前面说过,ClassLoader是一个抽象类,很多方法是空的没有实现,比如 findClass()、findResource()等。而URLClassLoader这个实现类为这些方法提供了具体的实现,并新增了URLClassPath类协助取得Class字节码流等功能,在编写自定义类加载器时,如果没有太过于复杂的需求,可以直接继承URLClassLoader类,这样就可以避免自己去编写findClass()方法及其获取字节码流的方式,使自定义类加载器编写更加简洁,下面是URLClassLoader的类图(利用IDEA生成的类图)

    从类图结构看出URLClassLoader中存在一个URLClassPath类,通过这个类就可以找到要加载的字节码流,也就是说URLClassPath类负责找到要加载的字节码,再读取成字节流,最后通过defineClass()方法创建类的Class对象。从URLClassLoader类的结构图可以看出其构造方法都有一个必须传递的参数URL[],该参数的元素是代表字节码文件的路径,换句话说在创建URLClassLoader对象时必须要指定这个类加载器的到那个目录下找class文件。同时也应该注意URL[]也是URLClassPath类的必传参数,在创建URLClassPath对象时,会根据传递过来的URL数组中的路径判断是文件还是jar包,然后根据不同的路径创建FileLoader或者JarLoader或默认Loader类去加载相应路径下的class文件,而当JVM调用findClass()方法时,就由这3个加载器中的一个将class文件的字节码流加载到内存中,最后利用字节码流创建类的class对象。请记住,如果我们在定义类加载器时选择继承ClassLoader类而非URLClassLoader,必须手动编写findclass()方法的加载逻辑以及获取字节码流的逻辑。了解完URLClassLoader后接着看看剩余的两个类加载器,即拓展类加载器ExtClassLoader和系统类加载器AppClassLoader,这两个类都继承自URLClassLoader,是sun.misc.Launcher的静态内部类。sun.misc.Launcher主要被系统用于启动主应用程序,ExtClassLoader和AppClassLoader都是由sun.misc.Launcher创建的,其类主要类结构如下:

    它们间的关系正如前面所阐述的那样,同时我们发现ExtClassLoader并没有重写loadClass()方法,这足矣说明其遵循双亲委派模式,而AppClassLoader重载了loadCass()方法,但最终调用的还是父类loadClass()方法,因此依然遵守双亲委派模式,重载方法源码如下:

     /**
      * Override loadClass 方法,新增包权限检测功能
      */
     public Class loadClass(String name, boolean resolve)
         throws ClassNotFoundException
     {
         int i = name.lastIndexOf('.');
         if (i != -1) {
             SecurityManager sm = System.getSecurityManager();
             if (sm != null) {
                 sm.checkPackageAccess(name.substring(0, i));
             }
         }
         //依然调用父类的方法
         return (super.loadClass(name, resolve));
     }
    

    其实无论是ExtClassLoader还是AppClassLoader都继承URLClassLoader类,因此它们都遵守双亲委托模型,这点是毋庸置疑的。ok,到此我们对ClassLoader、URLClassLoader、ExtClassLoader、AppClassLoader以及Launcher类间的关系有了比较清晰的了解,同时对一些主要的方法也有一定的认识,这里并没有对这些类的源码进行详细的分析,毕竟没有那个必要,因为我们主要弄得类与类间的关系和常用的方法同时搞清楚双亲委托模式的实现过程,为编写自定义类加载器做铺垫就足够了。ok,前面出现了很多父类加载器的说法,但每个类加载器的父类到底是谁,一直没有阐明,下面我们就通过代码验证的方式来阐明这答案。
    ##类加载器间的关系
    我们进一步了解类加载器间的关系(并非指继承关系),主要可以分为以下4点

    • 启动类加载器,由C++实现,没有父类。

    • 拓展类加载器(ExtClassLoader),由Java语言实现,父类加载器为null

    • 系统类加载器(AppClassLoader),由Java语言实现,父类加载器为ExtClassLoader

    • 自定义类加载器,父类加载器肯定为AppClassLoader。

    下面我们通过程序来验证上述阐述的观点

    /**
     * Created by zejian on 2017/6/18.
     * Blog : http://blog.csdn.net/javazejian [原文地址,请尊重原创]
     */
    //自定义ClassLoader,完整代码稍后分析
    class FileClassLoader extends  ClassLoader{
        private String rootDir;
    
        public FileClassLoader(String rootDir) {
            this.rootDir = rootDir;
        }
        // 编写获取类的字节码并创建class对象的逻辑
        @Override
        protected Class<?> findClass(String name) throws ClassNotFoundException {
           //...省略逻辑代码
        }
    	//编写读取字节流的方法
        private byte[] getClassData(String className) {
            // 读取类文件的字节
            //省略代码....
        }
    }
    
    public class ClassLoaderTest {
    
        public static void main(String[] args) throws ClassNotFoundException {
           
    			 FileClassLoader loader1 = new FileClassLoader(rootDir);
    			
    			  System.out.println("自定义类加载器的父加载器: "+loader1.getParent());
    			  System.out.println("系统默认的AppClassLoader: "+ClassLoader.getSystemClassLoader());
    			  System.out.println("AppClassLoader的父类加载器: "+ClassLoader.getSystemClassLoader().getParent());
    			  System.out.println("ExtClassLoader的父类加载器: "+ClassLoader.getSystemClassLoader().getParent().getParent());
    			
    			/**
    			输出结果:
    			    自定义类加载器的父加载器: sun.misc.Launcher$AppClassLoader@29453f44
    			    系统默认的AppClassLoader: sun.misc.Launcher$AppClassLoader@29453f44
    			    AppClassLoader的父类加载器: sun.misc.Launcher$ExtClassLoader@6f94fa3e
    			    ExtClassLoader的父类加载器: null
    			*/
    
        }
    }
    

    代码中,我们自定义了一个FileClassLoader,这里我们继承了ClassLoader而非URLClassLoader,因此需要自己编写findClass()方法逻辑以及加载字节码的逻辑,关于自定义类加载器我们稍后会分析,这里仅需要知道FileClassLoader是自定义加载器即可,接着在main方法中,通过ClassLoader.getSystemClassLoader()获取到系统默认类加载器,通过获取其父类加载器及其父父类加载器,同时还获取了自定义类加载器的父类加载器,最终输出结果正如我们所预料的,AppClassLoader的父类加载器为ExtClassLoader,而ExtClassLoader没有父类加载器。如果我们实现自己的类加载器,它的父加载器都只会是AppClassLoader。这里我们不妨看看Lancher的构造器源码

    public Launcher() {
            // 首先创建拓展类加载器
            ClassLoader extcl;
            try {
                extcl = ExtClassLoader.getExtClassLoader();
            } catch (IOException e) {
                throw new InternalError(
                    "Could not create extension class loader");
            }
    
            // Now create the class loader to use to launch the application
            try {
    	        //再创建AppClassLoader并把extcl作为父加载器传递给AppClassLoader
                loader = AppClassLoader.getAppClassLoader(extcl);
            } catch (IOException e) {
                throw new InternalError(
                    "Could not create application class loader");
            }
    
            //设置线程上下文类加载器,稍后分析
            Thread.currentThread().setContextClassLoader(loader);
    //省略其他没必要的代码......
            }
        }
    

    显然Lancher初始化时首先会创建ExtClassLoader类加载器,然后再创建AppClassLoader并把ExtClassLoader传递给它作为父类加载器,这里还把AppClassLoader默认设置为线程上下文类加载器,关于线程上下文类加载器稍后会分析。那ExtClassLoader类加载器为什么是null呢?看下面的源码创建过程就明白,在创建ExtClassLoader强制设置了其父加载器为null。

    //Lancher中创建ExtClassLoader
    extcl = ExtClassLoader.getExtClassLoader();
    
    //getExtClassLoader()方法
    public static ExtClassLoader getExtClassLoader() throws IOException{
    
      //........省略其他代码 
      return new ExtClassLoader(dirs);                     
      // .........
    }
    
    //构造方法
    public ExtClassLoader(File[] dirs) throws IOException {
       //调用父类构造URLClassLoader传递null作为parent
       super(getExtURLs(dirs), null, factory);
    }
    
    //URLClassLoader构造
    public URLClassLoader(URL[] urls, ClassLoader parent,
                              URLStreamHandlerFactory factory) {
    

    显然ExtClassLoader的父类为null,而AppClassLoader的父加载器为ExtClassLoader,所有自定义的类加载器其父加载器只会是AppClassLoader,注意这里所指的父类并不是Java继承关系中的那种父子关系。

    #类与类加载器
    ##类与类加载器
    在JVM中表示两个class对象是否为同一个类对象存在两个必要条件

    • 类的完整类名必须一致,包括包名。
    • 加载这个类的ClassLoader(指ClassLoader实例对象)必须相同。

    也就是说,在JVM中,即使这个两个类对象(class对象)来源同一个Class文件,被同一个虚拟机所加载,但只要加载它们的ClassLoader实例对象不同,那么这两个类对象也是不相等的,这是因为不同的ClassLoader实例对象都拥有不同的独立的类名称空间,所以加载的class对象也会存在不同的类名空间中,但前提是覆写loadclass方法,从前面双亲委派模式对loadClass()方法的源码分析中可以知,在方法第一步会通过Class<?> c = findLoadedClass(name);从缓存查找,类名完整名称相同则不会再次被加载,因此我们必须绕过缓存查询才能重新加载class对象。当然也可直接调用findClass()方法,这样也避免从缓存查找,如下

    String rootDir="/Users/zejian/Downloads/Java8_Action/src/main/java/";
    //创建两个不同的自定义类加载器实例
    FileClassLoader loader1 = new FileClassLoader(rootDir);
    FileClassLoader loader2 = new FileClassLoader(rootDir);
    //通过findClass创建类的Class对象
    Class<?> object1=loader1.findClass("com.zejian.classloader.DemoObj");
    Class<?> object2=loader2.findClass("com.zejian.classloader.DemoObj");
    
    System.out.println("findClass->obj1:"+object1.hashCode());
    System.out.println("findClass->obj2:"+object2.hashCode());
    
    /**
      * 直接调用findClass方法输出结果:
      * findClass->obj1:723074861
        findClass->obj2:895328852
        生成不同的实例
      */
    

    如果调用父类的loadClass方法,结果如下,除非重写loadClass()方法去掉缓存查找步骤,不过现在一般都不建议重写loadClass()方法。

    //直接调用父类的loadClass()方法
    Class<?> obj1 =loader1.loadClass("com.zejian.classloader.DemoObj");
    Class<?> obj2 =loader2.loadClass("com.zejian.classloader.DemoObj");
    
    //不同实例对象的自定义类加载器
    System.out.println("loadClass->obj1:"+obj1.hashCode());
    System.out.println("loadClass->obj2:"+obj2.hashCode());
    //系统类加载器
    System.out.println("Class->obj3:"+DemoObj.class.hashCode());
    
    /**
    * 直接调用loadClass方法的输出结果,注意并没有重写loadClass方法
    * loadClass->obj1:1872034366
      loadClass->obj2:1872034366
      Class->    obj3:1872034366
      都是同一个实例
    */
    

    所以如果不从缓存查询相同完全类名的class对象,那么只有ClassLoader的实例对象不同,同一字节码文件创建的class对象自然也不会相同。
    ##了解class文件的显示加载与隐式加载的概念
    所谓class文件的显示加载与隐式加载的方式是指JVM加载class文件到内存的方式,显示加载指的是在代码中通过调用ClassLoader加载class对象,如直接使用Class.forName(name)this.getClass().getClassLoader().loadClass()加载class对象。而隐式加载则是不直接在代码中调用ClassLoader的方法加载class对象,而是通过虚拟机自动加载到内存中,如在加载某个类的class文件时,该类的class文件中引用了另外一个类的对象,此时额外引用的类将通过JVM自动加载到内存中。在日常开发以上两种方式一般会混合使用,这里我们知道有这么回事即可。
    #编写自己的类加载器
    通过前面的分析可知,实现自定义类加载器需要继承ClassLoader或者URLClassLoader,继承ClassLoader则需要自己重写findClass()方法并编写加载逻辑,继承URLClassLoader则可以省去编写findClass()方法以及class文件加载转换成字节码流的代码。那么编写自定义类加载器的意义何在呢?

    • 当class文件不在ClassPath路径下,默认系统类加载器无法找到该class文件,在这种情况下我们需要实现一个自定义的ClassLoader来加载特定路径下的class文件生成class对象。

    • 当一个class文件是通过网络传输并且可能会进行相应的加密操作时,需要先对class文件进行相应的解密后再加载到JVM内存中,这种情况下也需要编写自定义的ClassLoader并实现相应的逻辑。

    • 当需要实现热部署功能时(一个class文件通过不同的类加载器产生不同class对象从而实现热部署功能),需要实现自定义ClassLoader的逻辑。

    ##自定义File类加载器
    这里我们继承ClassLoader实现自定义的特定路径下的文件类加载器并加载编译后DemoObj.class,源码代码如下

    public class DemoObj {
        @Override
        public String toString() {
            return "I am DemoObj";
        }
    }
    
    package com.zejian.classloader;
    
    import java.io.*;
    
    /**
     * Created by zejian on 2017/6/21.
     * Blog : http://blog.csdn.net/javazejian [原文地址,请尊重原创]
     */
    public class FileClassLoader extends ClassLoader {
        private String rootDir;
    
        public FileClassLoader(String rootDir) {
            this.rootDir = rootDir;
        }
    
        /**
         * 编写findClass方法的逻辑
         * @param name
         * @return
         * @throws ClassNotFoundException
         */
        @Override
        protected Class<?> findClass(String name) throws ClassNotFoundException {
            // 获取类的class文件字节数组
            byte[] classData = getClassData(name);
            if (classData == null) {
                throw new ClassNotFoundException();
            } else {
                //直接生成class对象
                return defineClass(name, classData, 0, classData.length);
            }
        }
    
        /**
         * 编写获取class文件并转换为字节码流的逻辑
         * @param className
         * @return
         */
        private byte[] getClassData(String className) {
            // 读取类文件的字节
            String path = classNameToPath(className);
            try {
                InputStream ins = new FileInputStream(path);
                ByteArrayOutputStream baos = new ByteArrayOutputStream();
                int bufferSize = 4096;
                byte[] buffer = new byte[bufferSize];
                int bytesNumRead = 0;
                // 读取类文件的字节码
                while ((bytesNumRead = ins.read(buffer)) != -1) {
                    baos.write(buffer, 0, bytesNumRead);
                }
                return baos.toByteArray();
            } catch (IOException e) {
                e.printStackTrace();
            }
            return null;
        }
    
        /**
         * 类文件的完全路径
         * @param className
         * @return
         */
        private String classNameToPath(String className) {
            return rootDir + File.separatorChar
                    + className.replace('.', File.separatorChar) + ".class";
        }
    
        public static void main(String[] args) throws ClassNotFoundException {
            String rootDir="/Users/zejian/Downloads/Java8_Action/src/main/java/";
            //创建自定义文件类加载器
            FileClassLoader loader = new FileClassLoader(rootDir);
    
            try {
                //加载指定的class文件
                Class<?> object1=loader.loadClass("com.zejian.classloader.DemoObj");
                System.out.println(object1.newInstance().toString());
              
                //输出结果:I am DemoObj
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    }
    
    

    显然我们通过getClassData()方法找到class文件并转换为字节流,并重写findClass()方法,利用defineClass()方法创建了类的class对象。在main方法中调用了loadClass()方法加载指定路径下的class文件,由于启动类加载器、拓展类加载器以及系统类加载器都无法在其路径下找到该类,因此最终将有自定义类加载器加载,即调用findClass()方法进行加载。如果继承URLClassLoader实现,那代码就更简洁了,如下:

    /**
     * Created by zejian on 2017/6/21.
     * Blog : http://blog.csdn.net/javazejian [原文地址,请尊重原创]
     */
    public class FileUrlClassLoader extends URLClassLoader {
    
        public FileUrlClassLoader(URL[] urls, ClassLoader parent) {
            super(urls, parent);
        }
    
        public FileUrlClassLoader(URL[] urls) {
            super(urls);
        }
    
        public FileUrlClassLoader(URL[] urls, ClassLoader parent, URLStreamHandlerFactory factory) {
            super(urls, parent, factory);
        }
    
    
        public static void main(String[] args) throws ClassNotFoundException, MalformedURLException {
            String rootDir="/Users/zejian/Downloads/Java8_Action/src/main/java/";
            //创建自定义文件类加载器
            File file = new File(rootDir);
            //File to URI
            URI uri=file.toURI();
            URL[] urls={uri.toURL()};
    
            FileUrlClassLoader loader = new FileUrlClassLoader(urls);
    
            try {
                //加载指定的class文件
                Class<?> object1=loader.loadClass("com.zejian.classloader.DemoObj");
                System.out.println(object1.newInstance().toString());
              
                //输出结果:I am DemoObj
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    }
    

    非常简洁除了需要重写构造器外无需编写findClass()方法及其class文件的字节流转换逻辑。
    ##自定义网络类加载器
    自定义网络类加载器,主要用于读取通过网络传递的class文件(在这里我们省略class文件的解密过程),并将其转换成字节流生成对应的class对象,如下

    /**
     * Created by zejian on 2017/6/21.
     * Blog : http://blog.csdn.net/javazejian [原文地址,请尊重原创]
     */
    public class NetClassLoader extends ClassLoader {
    
        private String url;//class文件的URL
    
        public NetClassLoader(String url) {
            this.url = url;
        }
    
        @Override
        protected Class<?> findClass(String name) throws ClassNotFoundException {
            byte[] classData = getClassDataFromNet(name);
            if (classData == null) {
                throw new ClassNotFoundException();
            } else {
                return defineClass(name, classData, 0, classData.length);
            }
        }
    
        /**
         * 从网络获取class文件
         * @param className
         * @return
         */
        private byte[] getClassDataFromNet(String className) {
            String path = classNameToPath(className);
            try {
                URL url = new URL(path);
                InputStream ins = url.openStream();
                ByteArrayOutputStream baos = new ByteArrayOutputStream();
                int bufferSize = 4096;
                byte[] buffer = new byte[bufferSize];
                int bytesNumRead = 0;
                // 读取类文件的字节
                while ((bytesNumRead = ins.read(buffer)) != -1) {
                    baos.write(buffer, 0, bytesNumRead);
                }
                //这里省略解密的过程.......
                return baos.toByteArray();
            } catch (Exception e) {
                e.printStackTrace();
            }
            return null;
        }
    
        private String classNameToPath(String className) {
            // 得到类文件的URL
            return url + "/" + className.replace('.', '/') + ".class";
        }
    
    }
    

    比较简单,主要是在获取字节码流时的区别,从网络直接获取到字节流再转车字节数组然后利用defineClass方法创建class对象,如果继承URLClassLoader类则和前面文件路径的实现是类似的,无需担心路径是filePath还是Url,因为URLClassLoader内的URLClassPath对象会根据传递过来的URL数组中的路径判断是文件还是jar包,然后根据不同的路径创建FileLoader或者JarLoader或默认类Loader去读取对于的路径或者url下的class文件。
    ##热部署类加载器
    所谓的热部署就是利用同一个class文件不同的类加载器在内存创建出两个不同的class对象(关于这点的原因前面已分析过,即利用不同的类加载实例),由于JVM在加载类之前会检测请求的类是否已加载过(即在loadClass()方法中调用findLoadedClass()方法),如果被加载过,则直接从缓存获取,不会重新加载。注意同一个类加载器的实例和同一个class文件只能被加载器一次,多次加载将报错,因此我们实现的热部署必须让同一个class文件可以根据不同的类加载器重复加载,以实现所谓的热部署。实际上前面的实现的FileClassLoader和FileUrlClassLoader已具备这个功能,但前提是直接调用findClass()方法,而不是调用loadClass()方法,因为ClassLoader中loadClass()方法体中调用findLoadedClass()方法进行了检测是否已被加载,因此我们直接调用findClass()方法就可以绕过这个问题,当然也可以重新loadClass方法,但强烈不建议这么干。利用FileClassLoader类测试代码如下:

     public static void main(String[] args) throws ClassNotFoundException {
            String rootDir="/Users/zejian/Downloads/Java8_Action/src/main/java/";
            //创建自定义文件类加载器
            FileClassLoader loader = new FileClassLoader(rootDir);
            FileClassLoader loader2 = new FileClassLoader(rootDir);
    
            try {
                //加载指定的class文件,调用loadClass()
                Class<?> object1=loader.loadClass("com.zejian.classloader.DemoObj");
                Class<?> object2=loader2.loadClass("com.zejian.classloader.DemoObj");
    
                System.out.println("loadClass->obj1:"+object1.hashCode());
                System.out.println("loadClass->obj2:"+object2.hashCode());
    
                //加载指定的class文件,直接调用findClass(),绕过检测机制,创建不同class对象。
                Class<?> object3=loader.findClass("com.zejian.classloader.DemoObj");
                Class<?> object4=loader2.findClass("com.zejian.classloader.DemoObj");
    
                System.out.println("loadClass->obj3:"+object3.hashCode());
                System.out.println("loadClass->obj4:"+object4.hashCode());
    
                /**
                 * 输出结果:
                 * loadClass->obj1:644117698
                   loadClass->obj2:644117698
                   findClass->obj3:723074861
                   findClass->obj4:895328852
                 */
    
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    

    #双亲委派模型的破坏者-线程上下文类加载器

        在Java应用中存在着很多服务提供者接口(Service Provider Interface,SPI),这些接口允许第三方为它们提供实现,如常见的 SPI 有 JDBC、JNDI等,这些 SPI 的接口属于 Java 核心库,一般存在rt.jar包中,由Bootstrap类加载器加载,而 SPI 的第三方实现代码则是作为Java应用所依赖的 jar 包被存放在classpath路径下,由于SPI接口中的代码经常需要加载具体的第三方实现类并调用其相关方法,但SPI的核心接口类是由引导类加载器来加载的,而Bootstrap类加载器无法直接加载SPI的实现类,同时由于双亲委派模式的存在,Bootstrap类加载器也无法反向委托AppClassLoader加载器SPI的实现类。在这种情况下,我们就需要一种特殊的类加载器来加载第三方的类库,而线程上下文类加载器就是很好的选择。
        线程上下文类加载器(contextClassLoader)是从 JDK 1.2 开始引入的,我们可以通过java.lang.Thread类中的getContextClassLoader()setContextClassLoader(ClassLoader cl)方法来获取和设置线程的上下文类加载器。如果没有手动设置上下文类加载器,线程将继承其父线程的上下文类加载器,初始线程的上下文类加载器是系统类加载器(AppClassLoader),在线程中运行的代码可以通过此类加载器来加载类和资源,如下图所示,以jdbc.jar加载为例

    从图可知rt.jar核心包是有Bootstrap类加载器加载的,其内包含SPI核心接口类,由于SPI中的类经常需要调用外部实现类的方法,而jdbc.jar包含外部实现类(jdbc.jar存在于classpath路径)无法通过Bootstrap类加载器加载,因此只能委派线程上下文类加载器把jdbc.jar中的实现类加载到内存以便SPI相关类使用。显然这种线程上下文类加载器的加载方式破坏了“双亲委派模型”,它在执行过程中抛弃双亲委派加载链模式,使程序可以逆向使用类加载器,当然这也使得Java类加载器变得更加灵活。为了进一步证实这种场景,不妨看看DriverManager类的源码,DriverManager是Java核心rt.jar包中的类,该类用来管理不同数据库的实现驱动即Driver,它们都实现了Java核心包中的java.sql.Driver接口,如mysql驱动包中的com.mysql.jdbc.Driver,这里主要看看如何加载外部实现类,在DriverManager初始化时会执行如下代码

    //DriverManager是Java核心包rt.jar的类
    public class DriverManager {
    	//省略不必要的代码
        static {
            loadInitialDrivers();//执行该方法
            println("JDBC DriverManager initialized");
        }
    
    //loadInitialDrivers方法
     private static void loadInitialDrivers() {
         sun.misc.Providers()
         AccessController.doPrivileged(new PrivilegedAction<Void>() {
                public Void run() {
    				//加载外部的Driver的实现类
                    ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);
                  //省略不必要的代码......
                }
            });
        }
    

    在DriverManager类初始化时执行了loadInitialDrivers()方法,在该方法中通过ServiceLoader.load(Driver.class);去加载外部实现的驱动类,ServiceLoader类会去读取mysql的jdbc.jar下META-INF文件的内容,如下所示

    而com.mysql.jdbc.Driver继承类如下:

    public class Driver extends com.mysql.cj.jdbc.Driver {
        public Driver() throws SQLException {
            super();
        }
    
        static {
            System.err.println("Loading class `com.mysql.jdbc.Driver'. This is deprecated. The new driver class is `com.mysql.cj.jdbc.Driver'. "
                    + "The driver is automatically registered via the SPI and manual loading of the driver class is generally unnecessary.");
        }
    }
    

    从注释可以看出平常我们使用com.mysql.jdbc.Driver已被丢弃了,取而代之的是com.mysql.cj.jdbc.Driver,也就是说官方不再建议我们使用如下代码注册mysql驱动

    //不建议使用该方式注册驱动类
    Class.forName("com.mysql.jdbc.Driver");
    String url = "jdbc:mysql://localhost:3306/cm-storylocker?characterEncoding=UTF-8";
    // 通过java库获取数据库连接
    Connection conn = java.sql.DriverManager.getConnection(url, "root", "root@555");
          
    

    而是直接去掉注册步骤,如下即可

    String url = "jdbc:mysql://localhost:3306/cm-storylocker?characterEncoding=UTF-8";
    // 通过java库获取数据库连接
    Connection conn = java.sql.DriverManager.getConnection(url, "root", "root@555");
          
    

    这样ServiceLoader会帮助我们处理一切,并最终通过load()方法加载,看看load()方法实现

    public static <S> ServiceLoader<S> load(Class<S> service) {
    	 //通过线程上下文类加载器加载
          ClassLoader cl = Thread.currentThread().getContextClassLoader();
          return ServiceLoader.load(service, cl);
      }
    

    很明显了确实通过线程上下文类加载器加载的,实际上核心包的SPI类对外部实现类的加载都是基于线程上下文类加载器执行的,通过这种方式实现了Java核心代码内部去调用外部实现类。我们知道线程上下文类加载器默认情况下就是AppClassLoader,那为什么不直接通过getSystemClassLoader()获取类加载器来加载classpath路径下的类的呢?其实是可行的,但这种直接使用getSystemClassLoader()方法获取AppClassLoader加载类有一个缺点,那就是代码部署到不同服务时会出现问题,如把代码部署到Java Web应用服务或者EJB之类的服务将会出问题,因为这些服务使用的线程上下文类加载器并非AppClassLoader,而是Java Web应用服自家的类加载器,类加载器不同。,所以我们应用该少用getSystemClassLoader()。总之不同的服务使用的可能默认ClassLoader是不同的,但使用线程上下文类加载器总能获取到与当前程序执行相同的ClassLoader,从而避免不必要的问题。ok~.关于线程上下文类加载器暂且聊到这,前面阐述的DriverManager类,大家可以自行看看源码,相信会有更多的体会,另外关于ServiceLoader本篇并没有过多的阐述,毕竟我们主题是类加载器,但ServiceLoader是个很不错的解耦机制,大家可以自行查阅其相关用法。

    ok~,本篇到此告一段落,如有误处,欢迎留言,谢谢。

    参考资料:
    http://blog.csdn.net/yangcheng33/article/details/52631940
    http://ifeve.com/wp-content/uploads/2014/03/JSR133中文版1.pdf

    《深入理解JVM虚拟机》
    《深入分析Java Web 技术内幕》

    展开全文
  • jvm之java类加载机制和类加载器(ClassLoader)的详解

    万次阅读 多人点赞 2018-08-13 15:05:46
    当程序主动使用某个时,如果该还未被加载到内存中,则JVM会通过加载、连接、初始化3个步骤来对该进行初始化。如果没有意外,JVM将会连续完成3个步骤,所以有时也把这个3个步骤统称为加载或初始化。 一...

    手把手写代码:三小时急速入门springboot—企业级微博项目实战--->csdn学院

          当程序主动使用某个类时,如果该类还未被加载到内存中,则JVM会通过加载、连接、初始化3个步骤来对该类进行初始化。如果没有意外,JVM将会连续完成3个步骤,所以有时也把这个3个步骤统称为类加载或类初始化。

                                                        

    一、类加载过程

    1.加载    

        加载指的是将类的class文件读入到内存,并为之创建一个java.lang.Class对象,也就是说,当程序中使用任何类时,系统都会为之建立一个java.lang.Class对象。

        类的加载由类加载器完成,类加载器通常由JVM提供,这些类加载器也是前面所有程序运行的基础,JVM提供的这些类加载器通常被称为系统类加载器。除此之外,开发者可以通过继承ClassLoader基类来创建自己的类加载器。

        通过使用不同的类加载器,可以从不同来源加载类的二进制数据,通常有如下几种来源。

    • 从本地文件系统加载class文件,这是前面绝大部分示例程序的类加载方式。
    • 从JAR包加载class文件,这种方式也是很常见的,前面介绍JDBC编程时用到的数据库驱动类就放在JAR文件中,JVM可以从JAR文件中直接加载该class文件。
    • 通过网络加载class文件。
    • 把一个Java源文件动态编译,并执行加载。

        类加载器通常无须等到“首次使用”该类时才加载该类,Java虚拟机规范允许系统预先加载某些类。

    2.链接

        当类被加载之后,系统为之生成一个对应的Class对象,接着将会进入连接阶段,连接阶段负责把类的二进制数据合并到JRE中。类连接又可分为如下3个阶段。

        1)验证:验证阶段用于检验被加载的类是否有正确的内部结构,并和其他类协调一致。Java是相对C++语言是安全的语言,例如它有C++不具有的数组越界的检查。这本身就是对自身安全的一种保护。验证阶段是Java非常重要的一个阶段,它会直接的保证应用是否会被恶意入侵的一道重要的防线,越是严谨的验证机制越安全。验证的目的在于确保Class文件的字节流中包含信息符合当前虚拟机要求,不会危害虚拟机自身安全。其主要包括四种验证,文件格式验证,元数据验证,字节码验证,符号引用验证。

        四种验证做进一步说明:

        文件格式验证:主要验证字节流是否符合Class文件格式规范,并且能被当前的虚拟机加载处理。例如:主,次版本号是否在当前虚拟机处理的范围之内。常量池中是否有不被支持的常量类型。指向常量的中的索引值是否存在不存在的常量或不符合类型的常量。

        元数据验证:对字节码描述的信息进行语义的分析,分析是否符合java的语言语法的规范。

        字节码验证:最重要的验证环节,分析数据流和控制,确定语义是合法的,符合逻辑的。主要的针对元数据验证后对方法体的验证。保证类方法在运行时不会有危害出现。

        符号引用验证:主要是针对符号引用转换为直接引用的时候,是会延伸到第三解析阶段,主要去确定访问类型等涉及到引用的情况,主要是要保证引用一定会被访问到,不会出现类等无法访问的问题。

       2)准备:类准备阶段负责为类的静态变量分配内存,并设置默认初始值。

       3)解析:将类的二进制数据中的符号引用替换成直接引用。说明一下:符号引用:符号引用是以一组符号来描述所引用的目标,符号可以是任何的字面形式的字面量,只要不会出现冲突能够定位到就行。布局和内存无关。直接引用:是指向目标的指针,偏移量或者能够直接定位的句柄。该引用是和内存中的布局有关的,并且一定加载进来的。

    3.初始化

        初始化是为类的静态变量赋予正确的初始值,准备阶段和初始化阶段看似有点矛盾,其实是不矛盾的,如果类中有语句:private static int a = 10,它的执行过程是这样的,首先字节码文件被加载到内存后,先进行链接的验证这一步骤,验证通过后准备阶段,给a分配内存,因为变量a是static的,所以此时a等于int类型的默认初始值0,即a=0,然后到解析(后面在说),到初始化这一步骤时,才把a的真正的值10赋给a,此时a=10。

    二、类加载时机

    1. 创建类的实例,也就是new一个对象
    2. 访问某个类或接口的静态变量,或者对该静态变量赋值
    3. 调用类的静态方法
    4. 反射(Class.forName("com.lyj.load"))
    5. 初始化一个类的子类(会首先初始化子类的父类)
    6. JVM启动时标明的启动类,即文件名和类名相同的那个类    

         除此之外,下面几种情形需要特别指出:

         对于一个final类型的静态变量,如果该变量的值在编译时就可以确定下来,那么这个变量相当于“宏变量”。Java编译器会在编译时直接把这个变量出现的地方替换成它的值,因此即使程序使用该静态变量,也不会导致该类的初始化。反之,如果final类型的静态Field的值不能在编译时确定下来,则必须等到运行时才可以确定该变量的值,如果通过该类来访问它的静态变量,则会导致该类被初始化。

    三、类加载器

        类加载器负责加载所有的类,其为所有被载入内存中的类生成一个java.lang.Class实例对象。一旦一个类被加载如JVM中,同一个类就不会被再次载入了。正如一个对象有一个唯一的标识一样,一个载入JVM的类也有一个唯一的标识。在Java中,一个类用其全限定类名(包括包名和类名)作为标识;但在JVM中,一个类用其全限定类名和其类加载器作为其唯一标识。例如,如果在pg的包中有一个名为Person的类,被类加载器ClassLoader的实例kl负责加载,则该Person类对应的Class对象在JVM中表示为(Person.pg.kl)。这意味着两个类加载器加载的同名类:(Person.pg.kl)和(Person.pg.kl2)是不同的、它们所加载的类也是完全不同、互不兼容的。

       JVM预定义有三种类加载器,当一个 JVM启动的时候,Java开始使用如下三种类加载器:

     1)根类加载器(bootstrap class loader):它用来加载 Java 的核心类,是用原生代码来实现的,并不继承自 java.lang.ClassLoader(负责加载$JAVA_HOME中jre/lib/rt.jar里所有的class,由C++实现,不是ClassLoader子类)。由于引导类加载器涉及到虚拟机本地实现细节,开发者无法直接获取到启动类加载器的引用,所以不允许直接通过引用进行操作。

    下面程序可以获得根类加载器所加载的核心类库,并会看到本机安装的Java环境变量指定的jdk中提供的核心jar包路径:

    public class ClassLoaderTest {
    
    	public static void main(String[] args) {
    		
    		URL[] urls = sun.misc.Launcher.getBootstrapClassPath().getURLs();
    		for(URL url : urls){
    			System.out.println(url.toExternalForm());
    		}
    	}
    }

    运行结果:

      2)扩展类加载器(extensions class loader):它负责加载JRE的扩展目录,lib/ext或者由java.ext.dirs系统属性指定的目录中的JAR包的类。由Java语言实现,父类加载器为null。

      3)系统类加载器(system class loader):被称为系统(也称为应用)类加载器,它负责在JVM启动时加载来自Java命令的-classpath选项、java.class.path系统属性,或者CLASSPATH换将变量所指定的JAR包和类路径。程序可以通过ClassLoader的静态方法getSystemClassLoader()来获取系统类加载器。如果没有特别指定,则用户自定义的类加载器都以此类加载器作为父加载器。由Java语言实现,父类加载器为ExtClassLoader。

    类加载器加载Class大致要经过如下8个步骤:

    1. 检测此Class是否载入过,即在缓冲区中是否有此Class,如果有直接进入第8步,否则进入第2步。
    2. 如果没有父类加载器,则要么Parent是根类加载器,要么本身就是根类加载器,则跳到第4步,如果父类加载器存在,则进入第3步。
    3. 请求使用父类加载器去载入目标类,如果载入成功则跳至第8步,否则接着执行第5步。
    4. 请求使用根类加载器去载入目标类,如果载入成功则跳至第8步,否则跳至第7步。
    5. 当前类加载器尝试寻找Class文件,如果找到则执行第6步,如果找不到则执行第7步。
    6. 从文件中载入Class,成功后跳至第8步。
    7. 抛出ClassNotFountException异常。
    8. 返回对应的java.lang.Class对象。

    四、类加载机制:

    1.JVM的类加载机制主要有如下3种。

    • 全盘负责:所谓全盘负责,就是当一个类加载器负责加载某个Class时,该Class所依赖和引用其他Class也将由该类加载器负责载入,除非显示使用另外一个类加载器来载入。
    • 双亲委派:所谓的双亲委派,则是先让父类加载器试图加载该Class,只有在父类加载器无法加载该类时才尝试从自己的类路径中加载该类。通俗的讲,就是某个特定的类加载器在接到加载类的请求时,首先将加载任务委托给父加载器,依次递归,如果父加载器可以完成类加载任务,就成功返回;只有父加载器无法完成此加载任务时,才自己去加载。
    • 缓存机制。缓存机制将会保证所有加载过的Class都会被缓存,当程序中需要使用某个Class时,类加载器先从缓存区中搜寻该Class,只有当缓存区中不存在该Class对象时,系统才会读取该类对应的二进制数据,并将其转换成Class对象,存入缓冲区中。这就是为很么修改了Class后,必须重新启动JVM,程序所做的修改才会生效的原因。

    2.这里说明一下双亲委派机制:

           双亲委派机制,其工作原理的是,如果一个类加载器收到了类加载请求,它并不会自己先去加载,而是把这个请求委托给父类的加载器去执行,如果父类加载器还存在其父类加载器,则进一步向上委托,依次递归,请求最终将到达顶层的启动类加载器,如果父类加载器可以完成类加载任务,就成功返回,倘若父类加载器无法完成此加载任务,子加载器才会尝试自己去加载,这就是双亲委派模式,即每个儿子都很懒,每次有活就丢给父亲去干,直到父亲说这件事我也干不了时,儿子自己才想办法去完成。

          双亲委派机制的优势:采用双亲委派模式的是好处是Java类随着它的类加载器一起具备了一种带有优先级的层次关系,通过这种层级关可以避免类的重复加载,当父亲已经加载了该类时,就没有必要子ClassLoader再加载一次。其次是考虑到安全因素,java核心api中定义类型不会被随意替换,假设通过网络传递一个名为java.lang.Integer的类,通过双亲委托模式传递到启动类加载器,而启动类加载器在核心Java API发现这个名字的类,发现该类已被加载,并不会重新加载网络传递的过来的java.lang.Integer,而直接返回已加载过的Integer.class,这样便可以防止核心API库被随意篡改。

    展开全文
  • Java进阶(五十四)初识JAVA类加载机制

    万次阅读 2017-02-28 19:36:05
    Java进阶(五十四)初识JAVA类加载机制  什么是类加载呢?当我们写完一个Java类的时候,并不是直接就可以运行的,它还要编译成.class文件,再由虚拟机解释给当前的操作系统去执行。这些过程都是我们看不见的,我们能...

    #Java进阶(五十四)初识JAVA类加载机制
      什么是类加载呢?当我们写完一个Java类的时候,并不是直接就可以运行的,它还要编译成.class文件,再由虚拟机解释给当前的操作系统去执行。这些过程都是我们看不见的,我们能看见的也就是一个.class文件。既然虚拟机要解释这些.class文件给当前的操作系统听,那么他怎么获得这些.class文件呢?虚拟机获得这些.class文件的过程就是类加载了。
      所以,总结来说就是:虚拟机将.class文件从磁盘或者其他地方加载到内存,并同时对文件中的数据进行校验、转换解析和初始化,最终形成可以被虚拟机直接识别的类型,这就是类加载机制!
      首先我们来看看类的一个生命周期:
    这里写图片描述
      总共有加载、验证、准备、解析、初始化、使用和卸载七个阶段。当中的前面的5个阶段就是我们要说的类加载机制了,其中验证、准备、解析阶段又统称为连接阶段。注意:解析阶段不一定会在准备阶段之后就执行,也有可能会在初始化阶段之后,这是为了支持JAVA的动态绑定的特性。
      什么是动态绑定呢?相信大家都知道JAVA的4大特性吧:封装、继承、抽象、多态。其实多态就可以理解为动态绑定。那么多态的实现机制就是:父类或者接口可以创建他们的子类或者实现类的实例对象。简单的来说就是:父类可以new出子类,接口可以new出他的实现类。
      多态通俗来说就是:父类A有一个方法function(),子类B,C分别继承A并且重写function(),当创建一个对象A b = new B(); b.function()就调用B的funciotn,假如你new C(),那调用的就是C重写的function。虚拟机怎么判断你使用的是哪个类的function就是动态绑定,这个现象就是多态。

    展开全文
  • Java进阶(四十)Java类、变量、方法修饰符讲解

    万次阅读 多人点赞 2016-08-30 10:00:51
    Java进阶(四十)Java类、变量、方法修饰符讲解Java类修饰符 abstract: 将一个类声明为抽象类,没有实现的方法,需要子类提供方法实现。 final: 将一个类生命为最终(即非继承类),表示他不能被其他类继承。 private:...

    Java进阶(四十)Java类、变量、方法修饰符讲解

    Java类修饰符

        abstract: 将一个类声明为抽象类,没有实现的方法,需要子类提供方法实现。

        final: 将一个类生命为最终(即非继承类),表示他不能被其他类继承。

        private: Java语言中对访问权限限制的最窄的修饰符,一般称之为“私有的”。被其修饰的类、属性以及方法只能被该类的对象访问,其子类不能访问,更不能允许跨包访问。

        Default(friendly): 默认的修饰符即不加任何访问修饰符,通常称为“默认访问模式”。该模式下,只允许在同一个包中进行访问。

        protect: 介于public 和 private 之间的一种访问修饰符,一般称之为“保护形”。被其修饰的类、属性以及方法只能被类本身的方法及子类访问,即使子类在不同的包中也可以访问。

        public(访问控制符): Java语言中访问限制最宽的修饰符,将一个类声明为公共类,他可以被任何对象访问,一个程序的主类必须是公共类。一般称之为“公共的”。被其修饰的类、属性以及方法不仅可以跨类访问,而且允许跨包(package)访问。

        下面用表格的形式来展示四种访问权限之间的异同点,这样会更加形象。注意其中protected和default的区别,表格如下所示:

     

    成员变量修饰符

        public(公共访问控制符): 指定该变量为公共的,他可以被任何对象的方法访问。

        private(私有访问控制符): 指定该变量只允许自己的类的方法访问,其他任何类(包括子类)中的方法均不能访问。

        protected(保护访问控制符): 指定该变量可以别被自己的类和子类访问。在子类中可以覆盖此变量。

        friendly: 在同一个包中的类可以访问,其他包中的类不能访问。

        final: 最终修饰符,指定此变量的值不能变。

        static(静态修饰符):指定变量被所有对象共享,即所有实例都可以使用该变量。变量属于这个类。

        transient(过度修饰符):指定该变量是系统保留,暂无特别作用的临时性变量。

        volatile(易失修饰符):指定该变量可以同时被几个线程控制和修改。

    方法修饰符

        public(公共控制符)

        private(私有控制符): 指定此方法只能有自己类等方法访问,其他的类不能访问(包括子类)

        protected(保护访问控制符):指定该方法可以被它的类和子类进行访问。

        final:指定该方法不能被重载。

        static:指定不需要实例化就可以激活的一个方法。

        synchronize: 同步修饰符,在多个线程中,该修饰符用于在运行前,对他所属的方法加锁,以防止其他线程的访问,运行结束后解锁。

        native:本地修饰符。指定此方法的方法体是用其他语言在程序外部编写的。

    美文美图

     

    展开全文
  • JAVA类之间方法的调用

    万次阅读 多人点赞 2018-11-02 23:39:15
    JAVA类方法的调用一、静态方法调用其他方法:1. 静态方法调用非静态方法2.静态方法调用静态方法二、非静态方法调用其他方法1.非静态方法在同一类内调用其他方法2.非静态方法在不同类之间调用其他方法 注:调用方法...
  • Java类加载机制

    万次阅读 多人点赞 2019-03-02 10:21:04
    Java类加载机制 类加载的时机 隐式加载 new 创建类的实例, 显式加载:loaderClass,forName等 访问类的静态变量,或者为静态变量赋值 调用类的静态方法 使用反射方式创建某个类或者接口对象的Class对象。 初始化某个...
  • 深入理解Java类加载器(一):Java类加载原理解析

    万次阅读 多人点赞 2017-05-15 20:47:44
    每个开发人员对java.lang...本文简述了JVM三种预定义类加载器,即启动类加载器、扩展类加载器和系统类加载器,并介绍和分析它们之间的关系和类加载所采用的双亲委派机制,给出并分析了与Java类加载原理相关的若干问题。
  • 2 Java虚拟机加载器结构简述 2.1 JVM三种预定义类型加载器 2.2 加载双亲委派机制介绍和分析 2.3 加载双亲委派示例 3 java程序动态扩展方式 3.1 调用java.lang.Class.forName(…)加载 3.2 用户自定义...
  • java 加载器

    万次阅读 2017-06-23 18:09:13
    顾名思义,加载器(class loader)用来加载 Java Java 虚拟机中。 具体的说就是:Java源程序(.java 文件)在经过Java 编译器编译之后就被转换成 Java 字节代码(.class文件)。加载器负责读取 Java字节代码...
  • 当我们写完一个Java类的时候,并不是直接就可以运行的,它还要编译成.class(字节码)文件,再由虚拟机解释给当前的操作系统去执行。这些过程都是我们看不见的,我们能看见的也就是一个.class文件。既然虚拟机要解释...
  • Java类和对象 详解(一)

    万次阅读 多人点赞 2016-10-06 20:48:02
    几乎现在的所有应用都以面向对象为主了,最早的面向对象的概念实际上是由IBM提出的,在70年代的Smaltalk语言之中进行了应用,后来根据面向对象的设计思路,才形成C++,而由C++产生了Java这门面向对象的编程语言。...
  • java类如何加载

    千次阅读 2018-11-06 14:19:04
    最近研究java的进阶知识,先从java类加载机制学起,原先看过《深入理解java虚拟机》这本书,奈何书的知识面太广及自身只看了一遍,很多知识并不是很理解,今天看了几篇别人讲解的java类加载机制,觉得讲的很好,帮助...
  • JVM进阶(十五)——JAVA 加载器

    万次阅读 2017-03-13 14:45:37
    JVM进阶(十五)——JAVA 加载器  今天我们将加载机制5个阶段中的第一个阶段,加载,又叫做装载。为了便于阅读,以下都叫做装载。   装载的第一步就是要获得二进制的字节流,它可以从读.class文件获得,也...
  •   在深入openjdk源码全面理解Java类加载器(上 – JVM源码篇) 我们分析了JVM是如何启动,并且初始化BootStrapClassLoader的,也提到了sun.misc.Launcher被加载后会创建ExtClassLoader和AppClassLoader。这篇文章...
  • java类加载器是什么?

    万次阅读 多人点赞 2019-07-30 15:23:10
    加载器是有了解吗?...一般来说,Java 虚拟机使用 Java 的方式如下:Java 源程序(.java 文件)在经过 Java 编译器编译之后就被转换成 Java 字节代码(.class 文件)。 加载器负责读取 Java ...
  • Java 之间的关系

    千次阅读 2019-04-28 20:58:11
    Java 之家的关系 一、继承关系 继承指的是一个(称为子类、子接口)继承另外的一个(称为父类、父接口)的功能,并可以增加它自己的新功能的能力。 在Java中继承关系通过关键字extends明确标识,在设计时...
  • XML生成java类

    千次阅读 2017-05-18 14:10:26
    xml生成java类
  • Java 虚拟机是如何判定两个 Java 是相同的?

    万次阅读 多人点赞 2019-07-30 15:23:59
    Java 虚拟机是如何判定两个 Java 是相同的? 答:Java 虚拟机不仅要看的全名是否相同,还要看加载此类的加载器是否一样。只有两者都相同的情况,才认为两个是相同的。即便是同样的字节代码,被不同的加载...
  • Java类加载机制与Tomcat类加载器架构

    万次阅读 热门讨论 2017-02-26 10:58:11
    Java类加载机制 类加载器 虚拟机设计团队把类加载阶段中的“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放到Java虚拟机外部去实现,以便让应用程序自己决定如何去获取所需要的类。实现这个动作的...
  • Java类加载,getClassLoader()

    万次阅读 2019-04-28 14:53:25
    转自 【java 加载的深入研究1】loadClass()的研究,IBM深入探讨 Java 加载器 加载器基本概念 顾名思义,加载器(class loader)用来加载 Java Java 虚拟机中。一般来说,Java 虚拟机使用 Java 的方式...
  • java类中serialVersionUID的作用

    万次阅读 多人点赞 2018-04-22 18:59:46
    原文出处:https://www.cnblogs.com/duanxz/p/3511695.html实现Serializable接口的目的是为可持久化,比如在网络传输或本地存储,为系统的分布和异构部署...简单来说,JAVA序列化的机制是通过判断的serialVer...
  • Java类加载器(Java Classloader)是Java运行时环境(Java Runtime Environment)的一部分,负责动态加载Java类到Java虚拟机的内存空间中。类通常是按需加载,即第一次使用该类时才加载。 ...
  • Java类加载过程图解

    千次阅读 2018-08-22 16:52:36
    朋友给我发了一道有意思的题目,如下 ...上图是我绘制的整个Java类加载过程。 首先是编译期,将Java源文件也就是敲好的代码通过编译,转换成.class文件,也就是字节码文件(byte),然后经过传输传...
  • 在IDEA上运行java类

    千次阅读 2018-12-12 08:50:49
    之前一直想不懂,为什么用ecplise能够通过右键选择运行java类,而IDEA不行。 二,解决方案 2.1 新建项目:java web项目、java项目都行 2.2 在项目中新建一个java类,并在类中写一个main方法 2.3 选择该java...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,073,971
精华内容 429,588
热门标签
关键字:

java类

java 订阅