精华内容
下载资源
问答
  • 类加载机制特性JAVA类加载机制JAVA类加载器java类加载器负责把一个一个编译好class文件装入内存中,并为其创建对应java.lang.Class对象。java中有如下几种类加载器: BootstrapClassLoader ExtClassLoader ...

    JAVA类加载机制

    JAVA类加载器

    java类加载器负责把一个一个编译好的class文件装入内存中,并为其创建对应的java.lang.Class对象。加载器是java动态特性的核心,提供了多态特性以及服务器热部署的能力。

    java中有如下几种类加载器:

    BootstrapClassLoader

    • implemented by native language (C/C++/汇编。区别于JRE版本。其他loader都是java)
    • load the core classes of JDK

    ExtesionClassLoader

    • loader the class from jre/lib/ext

    ApplicationClassLoader

    • load user-define classes
    • ClassLoader.getSystemClassLoader() == application class loader

    other class loaders

    • SecureClassLoader
    • URLClassLoader (2/3的父类)
    • user-define ClassLoader

    这里写图片描述

    类加载层次关系:

    !!非继承关系.

    这里写图片描述
    (图片摘自马士兵老师教程)

    每次ClassLoader加载类时,都会向上层询问是否已经加载该类,若已加载,则不会再加载。一方面节省资源,另一方面出于安全的考虑,保护核心class不会被覆盖。

    按需加载,用到的时候再加载(new / class.forName() / classLoader.load())

    URLClassLoader是ApplicationClassLoader、ExtesionClassLoader的父类,主要负责显式的指明类加载的path。

    这里写图片描述

    类加载机制的特性:

    1. 全盘负责
    2. 父类委托
    3. 缓存机制

    全盘负责是指,当一个类加载器负责加载某个Class时,还要负责加载该Class的引用和依赖(除非有显式声明指定让其他加载器来加载)。

    父类委托是指,类加载器再载入类的时候,会优先让parent加载器(关系中的)来加载,当该parent加载器无法载入指定类时,才会尝试从自己的类路径加载该类。[递归定义*]

    缓存机制是指,jvm会保证所有加载过的Class都会被缓存下来,当程序要使用某个Class时,会优先在缓存里搜索该类(如何辨别?),若搜索不到则载入该类class文件,并将其转换成Class对象。[这也导致了,我们修改程序后,必须重启应用程序(JVM)才能生效]

    JVM如何辨别是不是同一个类:
    符合类标识规则(类名,包名,加载器名)的类才会被认为是同一个类。

    类加载流程:

    这里写图片描述

    其中:
    第5.6步允许用户重写ClassLoader中的findClass()方法来实现自己的载入策略,甚至可以重写loadClass()方法来具体实现整个载入过程。


    tips:

    • java -verbose:class 可以观察类的具体加载过程

    • static 语句块在加载后只执行一次

    • dynamic语句块每次new新的对象都会执行{ }
      等同于无条件 ‘在所有构造语句之前的执行的’ 语句。

    源码:
    https://github.com/timo1160139211/java-tranning/tree/master/src/site/gaoyisheng/test/classloader


    在线画图工具:
    https://go.gliffy.com/go/html5/launch

    当然更推荐Dia画图。

    展开全文
  • Java类加载机制 类加载器    虚拟机设计团队把类加载阶段中“通过一个类全限定名来获取描述此类二进制字节流”这个动作放到Java虚拟机外部去实现,以便...实现这个动作代码模块称为“类加载器”。  ...

    转自:https://blog.csdn.net/fuzhongmin05/article/details/57404890

    Java类加载机制

    类加载器
      

          虚拟机设计团队把类加载阶段中的“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放到Java虚拟机外部去实现,以便让应用程序自己决定如何去获取所需要的类。实现这个动作的代码模块称为“类加载器”。

          类加载器可以说是Java语言的一项创新,也是Java语言流行的重要原因之一,在类层次划分、OSGi、热部署、代码加密等领域大放异彩,成为了Java技术体系中一块重要的基石

          类加载器虽然只用于实现类的加载动作,但它在Java程序中起到的作用却远远不限于类加载阶段。对于任意一个类,都需要由加载它的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性,每一个类,都拥有一个独立的类名称空间。这句话可以表达得更通俗一些:比较两个类是否“相等”,只有在这两个类是由同一个类加载器加载的前提下才有意义。否则,即使这两个类来源于同一个Class文件,被同一个虚拟机加载,只要加载它们的类加载器不同,那这两个类就必定不相等。

    双亲委派模型(作用是系统的稳定性)


          从Java虚拟机的角度来讲,只存在两种不同的类加载器:一种是启动类加载器(Bootstrap ClassLoader),这个类加载器使用C++语言实现,是虚拟机自身的一部分;另一种就是所有其他的类加载器,这些类加载器都由Java语言实现,独立于虚拟机外部,并且全都继承自抽象类java.lang.ClassLoader。

          从Java开发人员的角度来看, 类加载器还可以划分得更细致一些, 绝大部分Java程序都会使用到以下3种系统提供的类加载器。

    1)启动类加载器(Bootstrap ClassLoader):前面已经介绍过,这个类加载器负责将存放在<JAVA_HOME>\lib目录中的,或者被-X bootclasspath参数所指定的路径中的,并且是虚拟机识别的(仅按照文件名识别,如rt.jar,名字不符合的类库即使放在lib目录中也不会被加载)类库加载到虚拟机内存中。启动类加载器无法被Java程序直接引用。

    2)扩展类加载器(Extension ClassLoader):这个加载器由sun.misc.Launcher.ExtClassLoader实现,它负责加载<JAVA_HOME>\lib\ext目录中的,或者被java.ext.dirs系统变量所指定的路径中的所有类库,开发者可以直接使用扩展类加载器。

    3)应用程序类加载器(Application ClassLoader):这个类加载器由sun.misc.Launcher.AppClassLoader实现。由于这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值,所以一般也称它为系统类加载器。它负责加载用户类路径(Class Path)上所指定的类库,开发者可以直接使用这个类加载器,如果应用程序中没有自定义过自己的类加载器,一般情况下这个就是程序中默认的类加载器。

          我们的应用程序都是由这3种类加载器互相配合进行加载的,如果有必要,还可以加入自己定义的类加载器。这些类加载器之间的关系一般如下图所示

    双亲委派模型的工作过程是:如果一个类加载器收到了类加载的请求,它首先不会自己去尝试加载这个类,而是把这个请求委派给父类加载器去完成,每一个层次的类加载器都是如此,因此所有的加载请求最终都应该传送到顶层的启动类加载器中,只有当父加载器反馈自己无法完成这个加载请求(它的搜索范围中没有找到所需的类)时,子加载器才会尝试自己去加载。

          使用双亲委派模型来组织类加载器之间的关系,有一个显而易见的好处就是Java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object,它存放在rt.jar之中,无论哪一个类加载器要加载这个类,最终都是委派给处于模型最顶端的启动类加载器进行加载,因此Object类在程序的各种类加载器环境中都是同一个类。相反,如果没有使用双亲委派模型,由各个类加载器自行去加载的话,如果用户自己编写了一个称为java.lang.Object的类,并放在程序的Class Path中,那系统中将会出现多个不同的Object类,Java类型体系中最基础的行为也就无法保证,应用程序也将会变得一片混乱。如果读者有兴趣的话,可以尝试去编写一个与rt.jar类库中已有类重名的Java类,将会发现可以正常编译,但永远无法被加载运行。


    双亲委派模型对于保证Java程序的稳定运作很重要,但它的实现却非常简单,实现双亲委派的代码都集中在java.lang.ClassLoader的loadClass()方法之中,如以下代码所示,逻辑清晰易懂:

    protected synchronized Class<?> loadClass(String name, boolean resolve)
    throws ClassNotFoundException
    {
    	//首先, 检查请求的类是否已经被加载过了
    	Class c=findLoadedClass(name);
    	if( c== null ){
    		try{
    			if( parent != null ){
    				c = parent.loadClass(name,false);
    			} else {
    				c = findBootstrapClassOrNull(name);
    			}
    		} catch (ClassNotFoundException e) {
    		//如果父类加载器抛出ClassNotFoundException
    		//说明父类加载器无法完成加载请求
    		}
    		if( c == null ) {
    			//在父类加载器无法加载的时候
    			//再调用本身的findClass方法来进行类加载
    			c = findClass(name);
    		}
    	} 
    	if(resolve){
    		resolveClass(c);
    	}
    	return c;
    }

    先检查是否已经被加载过,若没有加载则调用父加载器的loadClass()方法,若父加载器为空则默认使用启动类加载器作为父加载器。如果父类加载失败,抛出ClassNotFoundException异常后,再调用自己的findClass()方法进行加载。双亲委派的具体逻辑就实现在这个loadClass()方法之中,JDK 1.2之后已不提倡用户再去覆盖loadClass()方法,而应当把自己的类加载逻辑写到findClass()方法中,在loadClass()方法的逻辑里如果父类加载失败,则会调用自己的findClass()方法来完成加载,这样就可以保证新写出来的类加载器是符合双亲委派规则的。

    双亲模型的缺点:上级加载不了下级的类

    双亲模型是有层级的,如自定义

    ClassLoader(4) -> ApplicationClassLoader(3) -> ExtensionClassLoader(2) -> BootstrapClassLoader(1)

    举个例子:

    JNDI(Java Naming and Directory Interface)服务,JNDI说白了就是把资源取个名字,再根据名字来找资源。JNDI现在已经是Java的标准服务,它的代码由启动类加载器去加载(在JDK 1.3时放进去的rt.jar),但JNDI的目的就是对资源进行集中管理和查找,它需要调用由独立厂商实现并部署在应用程序的Class Path下的JNDI接口提供者(SPI,Service Provider Interface)的代码,但启动类加载器不可能“认识”这些代码,因为启动类加载器的搜索范围中找不到用户应用程序类,那该怎么办?为了解决这个问题,Java设计团队只好引入了一个不太优雅的设计:线程上下文类加载器(Thread Context ClassLoader)。这个类加载器可以通过java.lang.Thread类的setContextClassLoader()方法进行设置,如果创建线程时还未设置,它将会从父线程中继承一个,如果在应用程序的全局范围内都没有设置过的话,那这个类加载器默认就是应用程序类加载器(Application ClassLoader)。

    也就是说可以通过这个线程上下文类加载器来加载下级的类,它默认是ApplicationClassLoader

     

    Tomcat的类加载器架构

     主流的Java Web服务器(也就是Web容器),如Tomcat、Jetty、WebLogic、WebSphere或其他笔者没有列举的服务器,都实现了自己定义的类加载器(一般都不止一个)。因为一个功能健全的Web容器,要解决如下几个问题:

          1)部署在同一个Web容器上的两个Web应用程序所使用的Java类库可以实现相互隔离。这是最基本的需求,两个不同的应用程序可能会依赖同一个第三方类库的不同版本,不能要求一个类库在一个服务器中只有一份,服务器应当保证两个应用程序的类库可以互相独立使用。

          2)部署在同一个Web容器上的两个Web应用程序所使用的Java类库可以互相共享。这个需求也很常见,例如,用户可能有10个使用Spring组织的应用程序部署在同一台服务器上,如果把10份Spring分别存放在各个应用程序的隔离目录中,将会是很大的资源浪费——这主要倒不是浪费磁盘空间的问题,而是指类库在使用时都要被加载到Web容器的内存,如果类库不能共享,虚拟机的方法区就会很容易出现过度膨胀的风险。

          3)Web容器需要尽可能地保证自身的安全不受部署的Web应用程序影响。目前,有许多主流的Java Web容器自身也是使用Java语言来实现的。因此,Web容器本身也有类库依赖的问题,一般来说,基于安全考虑,容器所使用的类库应该与应用程序的类库互相独立

          4)支持JSP应用的Web容器,大多数都需要支持HotSwap(热交换)功能。我们知道,JSP文件最终要编译成Java Class才能由虚拟机执行,但JSP文件由于其纯文本存储的特性,运行时修改的概率远远大于第三方类库或程序自身的Class文件。而且ASP、PHP和JSP这些网页应用也把修改后无须重启作为一个很大的“优势”来看待,因此“主流”的Web容器都会支持JSP生成类的热替换,当然也有“非主流”的,如运行在生产模式(Production Mode)下的WebLogic服务器默认就不会处理JSP文件的变化。

          由于存在上述问题,在部署Web应用时,单独的一个Class Path就无法满足需求了,所以各种Web容都“不约而同”地提供了好几个Class Path路径供用户存放第三方类库,这些路径一般都以“lib”或“classes”命名。被放置到不同路径中的类库,具备不同的访问范围和服务对象,通常,每一个目录都会有一个相应的自定义类加载器去加载放置在里面的Java类库。现在,就以Tomcat容器为例,看一看Tomcat具体是如何规划用户类库结构和类加载器的。

          在Tomcat目录结构中,有3组目录(“/common/*”、“/server/*”和“/shared/*”)可以存放Java类库,另外还可以加上Web应用程序自身的目录“/WEB-INF/*”,一共4组,把Java类库放置在这些目录中的含义分别如下:

          ①放置在/common目录中:类库可被Tomcat和所有的Web应用程序共同使用。

          ②放置在/server目录中:类库可被Tomcat使用,对所有的Web应用程序都不可见。

          ③放置在/shared目录中:类库可被所有的Web应用程序共同使用,但对Tomcat自己不可见。

          ④放置在/WebApp/WEB-INF目录中:类库仅仅可以被此Web应用程序使用,对Tomcat和其他Web应用程序都不可见。

          为了支持这套目录结构,并对目录里面的类库进行加载和隔离,Tomcat自定义了多个类加载器,这些类加载器按照经典的双亲委派模型来实现,其关系如下图所示。

    CommonClassLoader(加载/common/*)、CatalinaClassLoader(加载/server/*)、SharedClassLoader(加载/shared/*)和WebappClassLoader(加载/WebApp/WEB-INF/*)是Tomcat自己定义的类加载器,其中WebApp类加载器和Jsp类加载器通常会存在多个实例,每一个Web应用程序对应一个WebApp类加载器,每一个JSP文件对应一个Jsp类加载器(它出现的目的就是为了被丢弃:当Web容器检测到JSP文件被修改时,会替换掉目前的JasperLoader的实例,并通过再建立一个新的Jsp类加载器来实现JSP文件的HotSwap功能

    对于Tomcat的6.x版本,只有指定了tomcat/conf/catalina.properties配置文件的server.loader和share.loader项后才会真正建立Catalina ClassLoader和Shared ClassLoader的实例,否则在用到这两个类加载器的地方都会用Common ClassLoader的实例代替,而默认的配置文件中没有设置这两个loader项,所以Tomcat 6.x顺理成章地把/common、/server和/shared三个目录默认合并到一起变成一个/lib目录,这个目录里的类库相当于以前/common目录中类库的作用。这是Tomcat设计团队为了简化大多数的部署场景所做的一项改进,如果默认设置不能满足需要,用户可以通过修改配置文件指定server.loader和share.loader的方式重新启用Tomcat 5.x的加载器架构。

          Tomcat加载器的实现清晰易懂,并且采用了官方推荐的“正统”的使用类加载器的方式。如果读者阅读完上面的案例后,能完全理解Tomcat设计团队这样布置加载器架构的用意,那说明已经大致掌握了类加载器“主流”的使用方式,那么笔者不妨再提一个问题让读者思考一下:前面曾经提到过一个场景,如果有10个Web应用程序都是用Spring来进行组织和管理的话,可以把Spring放到Common或Shared目录下让这些程序共享。Spring要对用户程序的类进行管理,自然要能访问到用户程序的类,而用户的程序显然是放在/WebApp/WEB-INF目录中的,那么被CommonClassLoader或SharedClassLoader加载的Spring如何访问并不在其加载范围内的用户程序呢?如果研究过虚拟机类加载器机制中的双亲委派模型,相信读者可以很容易地回答这个问题。

          分析:如果按主流的双亲委派机制,显然无法做到让父类加载器加载的类去访问子类加载器加载的类,上面在类加载器一节中提到过通过线程上下文方式传播类加载器。

          答案是使用线程上下文类加载器来实现的,使用线程上下文加载器,可以让父类加载器请求子类加载器去完成类加载的动作。看spring源码发现,spring加载类所用的Classloader是通过Thread.currentThread().getContextClassLoader()来获取的,而当线程创建时会默认setContextClassLoader(AppClassLoader),即线程上下文类加载器被设置为AppClassLoader,spring中始终可以获取到这个AppClassLoader(在Tomcat里就是WebAppClassLoader)子类加载器来加载bean,以后任何一个线程都可以通过getContextClassLoader()获取到WebAppClassLoader来getbean了。

     

    所以Java类加载器跟Tomcat类加载器的关系,我觉得,JAVA类加载器定义了加载的规范,Tomcat使用了它这种规范,然后根据自己的情况进行了扩展,Tomcat启动时,就对项目进行加载。所以这里的Tomcat加载也可以理解为Java类加载了,因为之前疑惑,是不是Tomcat加载了一部分,然后虚拟机加载一部分。这个疑惑是错的,因为开头就说了,这个动作放到 “Java虚拟机外部” 去实现,这里的外部就是指Tomcat,   Tomcat启动时,将类加载进虚拟机

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     


     

     

     

     

     

     

     

     

     

     

    展开全文
  • 当 JVM 启动时候,Java 缺省开始使用如下三种类型的类加载器: 启动(Bootstrap)类加载器:引导类加载器是用 本地代码实现的类加载器,它负责将 <JAVA_HOME>/lib 下面核心类库 或 -Xbootclasspath 选项...

    一、三种类加载器

    当 JVM 启动的时候,Java 缺省开始使用如下三种类型的类加载器:

    1. 启动(Bootstrap)类加载器:引导类加载器是用 本地代码实现的类加载器,它负责将 <JAVA_HOME>/lib 下面的核心类库 或 -Xbootclasspath 选项指定的 jar 包等 虚拟机识别的类库 加载到内存中。由于引导类加载器涉及到虚拟机本地实现细节,开发者无法直接获取到启动类加载器的引用,所以 不允许直接通过引用进行操作。

    2. 扩展(Extension)类加载器:扩展类加载器是由 Sun 的 ExtClassLoader(sun.misc.Launcher$ExtClassLoader)实现的,它负责将 <JAVA_HOME>/lib/ext 或者由系统变量 - Djava.ext.dir 指定位置中的类库 加载到内存中。开发者可以直接使用标准扩展类加载器。

    3. 系统(System)类加载器:系统类加载器是由 Sun 的 AppClassLoader(sun.misc.Launcher$AppClassLoader)实现的,它负责将 用户类路径 (java -classpath 或 - Djava.class.path 变量所指的目录,即当前类所在路径及其引用的第三方类库的路径。开发者可以直接使用系统类加载器。

    在这里插入图片描述

    通过这两张图我们可以看出,扩展类加载器和系统类加载器均是继承自 java.lang.ClassLoader 抽象类。


    二、类加载器的关系

    关系如下:

    在这里插入图片描述

    上面图片给人的直观印象是:系统类加载器的父类加载器是标准扩展类加载器,标准扩展类加载器的父类加载器是启动类加载器。

    事实上,由于启动类加载器无法被 Java 程序直接引用,因此 JVM 默认直接使用 null 代表启动类加载器。

    此外:

    1.系统类加载器(AppClassLoader)调用 ClassLoader (ClassLoader parent) 构造函数将父类加载器设置为标准扩展类加载器 (ExtClassLoader)。(因为如果不强制设置,默认会通过调用 getSystemClassLoader () 方法获取并设置成系统类加载器。)

    2.扩展类加载器(ExtClassLoader)调用 ClassLoader (ClassLoader parent) 构造函数将父类加载器设置为 null(null 本身就代表着引导类加载器)。(因为如果不强制设置,默认会通过调用 getSystemClassLoader () 方法获取并设置成系统类加载器,。)

    展开全文
  • 类加载器分为根加载器(bootstrap classloader)、扩展类加载器(ext classloader)、系统类加载器(system classloader)、自定义类加载器(通常继承java.net.URLClassLoader,重写findClass()),它们的关系通常...
  • Java在需要使用类别时候,才会将类别加载,Java的类别载入是由类别载入器(Class loader)来达到,预设上,在程序启动之后,主要会有三个类别加载器:Bootstrap Loader、ExtClassLoader与AppClassLoader。...

    Java在需要使用类别的时候,才会将类别加载,Java的类别载入是由类别载入器(Class loader)来达到的,预设上,在程序启动之后,主要会有三个类别加载器:Bootstrap Loader、ExtClassLoader与AppClassLoader。

    Bootstrap Loader是由C++撰写而成,预设上它负责搜寻JRE所在目录的classes或lib目录下的.jar档案中(例如rt.jar)是否有指定的类别并加载(实际上是由系统参数sun.boot.class.path指定);预设上ExtClassLoader负责搜寻JRE所在目录的lib/ext 目录下的classes或.jar中是否有指定的类别并加载(实际上是由系统参数java.ext.dirs指定);AppClassLoader则搜寻 Classpath中是否有指定的classes并加载(由系统参数java.class.path指定)。

    Bootstrap Loader会在JVM启动之后载入,之后它会载入ExtClassLoader并将ExtClassLoader的parent设为Bootstrap Loader,然后BootstrapLoader再加载AppClassLoader,并将AppClassLoader的parent设定为 ExtClassLoader。

    在加载类别时,每个类别加载器会先将加载类别的任务交由其parent,如果parent找不到,才由自己负责加载,如果自己也找不到,就会丢出 NoClassDefFoundError。

    每一个类别被载入后,都会有一个Class的实例来代表它,每个Class的实例都会记得是哪个ClassLoader加载它的,可以由Class的getClassLoader()取得加载该类别的ClassLoader。

    展开全文
  • 关于父委托机制的说明:当生成 一个自定义的类加载器实例时,如果没有指定它的父加载器,那么系统类加载器将成为该类加载器的父类加载器下面,自定义类加载器。自定义的类加载器必须继承java.lang.ClassLoader类...
  • Java类加载器采用父亲委托机制,先尝试用父加载器加载,父加载器无法加载,则此加载器加载, 注意,此父加载器与子加载器并非继承关系,而是指定的关系。 从ClassLoader类loadClass()方法的源码,可以看出父亲委托...
  • 简介介绍类加载器的分类和特性类加载器加载器类型如上图所示,类加载器大致可分为四大类,如上他们是有父子关系的,启动类加载器最先开始(用C++写的),后面加载上子加载器1.启动类加载器2.扩展类加载器3.应用类加载...
  • 自定义类加载器的循序进行。 当系统使用一个类时,需要检查这个类是否已经被加载,会先从底层类加载器进行判断。 在这些类加载器中,启动类时C代码编写的,并且在java中没有对象与之对应。系统的核心类就是由启动...
  • 深入理解Java类加载器(一):Java类加载原理解析

    万次阅读 多人点赞 2017-05-15 20:47:44
    每个开发人员对java.lang...本文简述了JVM三种预定义类加载器,即启动类加载器、扩展类加载器和系统类加载器,并介绍和分析它们之间的关系和类加载所采用的双亲委派机制,给出并分析了与Java类加载原理相关的若干问题。
  • Java的类加载器 学习总结于-《深入了解JAVA虚拟机》-周自明 Java虚拟机类加载机制 虚拟机把描述类数据从Class文件加载到内存,并对数据进行校验、解析和初始化,最终形成可以被虚拟机直接使用的Java类型,这...
  • Java类加载器

    2018-04-30 22:48:22
    Java类加载器J2SE标准类加载器 JVM默认提供了3个类加载器,他们之间是父子关系,并使用委派模式确保应用程序可以通过自身类加载器(System类加载器)加载所有可见类。如下图:各类加载器作用Bootstrap:用于加载...
  • 本章通过分析ClassLoader的源码来展示java类加载器的层次结构。根据规定,类加载器会为它的父类加载器提供一个机会,以便加载任何给定的类,并且只有在其父类加载器加载失败时,它才会加载该给定类。如:系统类加载...
  • 我们知道,我们在Java中用到所有类都是通过类加载器ClassLoader加载到JVM中,我们还知道类加载器也对应着一个类,既然这样那么我们会想那么ClassLoader类是由谁加载呢?  其实在Java中有许许多多的类加载器...
  • 我们知道 我们在Java中用到所有类都是通过类加载器ClassLoader加载到JVM中,我们还知道 类加载器 也对应着一个类 ,既然这样那么我们会想 那么ClassLoader类是由谁加载呢?  其实在Java中有许许多多 ...
  • JVM自带的类加载器: ...当生成 一个自定义的类加载器实例时,如果没有指定它的父加载器,那么系统类加载器将成为该类加载器的父类加载器 下面,自定义类加载器。自定义的类加载器必须继承java.lang.ClassLoa
  • 本文简述了JVM三种预定义类加载器,即启动类加载器、扩展类加载器和系统类加载器,并介绍和分析它们之间的关系和类加载所采用的双亲委派机制,给出并分析了与Java类加载原理相关的若干问题。 版权声明: 本文作者:...
  • java类加载器

    2017-08-21 00:17:51
    类加载器 Java虚拟机中可以安装多个...类加载器也是Java类,因为其他是java类的类加载器本身也要被类加载器加载,显然必须有第一个类加载器不是java类,这正是BootStrap。 Java虚拟机中所有类装载器采用具有父子关系
  • 类加载器:通过一个类全限定名去获取此类二进制字节流,这个动作放在java虚拟机外部实现,以便程序可以自己选择执行那个类。 类加载器符合双亲委派机制,即从上往下依次是 启动类加载器:在Java_home/lib下,...
  • 关于父委托机制的说明:当生成 一个自定义的类加载器实例时,如果没有指定它的父加载器,那么系统类加载器将成为该类加载器的父类加载器下面,自定义类加载器。自定义的类加载器必须继承java.lang.ClassLoader类...
  • 比较两个类是否相等,只有在这两个类是由同一个类加载器加载前提下才有意义,否则,即使这两个类来源于同一个Class文件,被同一个虚拟机加载,只要加载他们的类加载器不同,那么这两个类就必定不相等。

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,160
精华内容 464
关键字:

java类加载器的关系

java 订阅