java中的classloader是一个类本身，那么谁将加载classloader类? [英] classloader in java is a class itself then who will load the classloader class?

问题描述

Java中的ClassLoader是用于加载Java中的类文件的类.

ClassLoader in Java is a class which is used to load class files in Java.

java.lang.ClassLoader是一个抽象类

The java.lang.ClassLoader is an abstract class

我的问题是，此java.lang.ClassLoader类是否与JVM的类加载器(1. Bootstrap类加载器2.扩展类加载器3.系统类加载器)相关?

here my question is does this java.lang.ClassLoader class is any way related to JVM's classloaders(1. Bootstrap class loader 2. Extensions class loader 3. System class loader)?

还是这个java.lang.ClassLoader是一个单独的类，可用于创建自定义类加载器?

or this java.lang.ClassLoader is a separate class which can be used to create a custom classloader?

类加载器是Java运行时环境的一部分，可将Java类动态加载到Java虚拟机中.它负责查找库，读取内容并加载库中包含的类.启动JVM时，使用了三个类加载器

Class loaders are the part of the Java Runtime Environment that dynamically loads Java classes into the Java virtual machine. It is responsible for locating libraries, reading there content and loading the classes contained within the libraries When JVM is started three class loaders are used

1. Bootstrap类加载器

1. Bootstrap class loader

扩展类加载器

系统类加载器

Bootstrap类加载器加载核心Java库.它是用本机代码编写的.引导类加载器负责将关键的Java类(如java.lang.Object)和其他运行时代码加载到内存中.运行时类打包在jre/lib/rt.jar文件中.

Bootstrap class loader loads the core java libraries. It is written in native code. The bootstrap class loader is responsible for loading key java classes like java.lang.Object and other runtime code into memory. The runtime classes are packaged inside jre/lib/rt.jar file.

Extensions类加载器将代码加载到扩展目录中.它由ExtClassLoader类实现.

Extensions class loader loads the code in the extension directories. It is implemented by ExtClassLoader class.

系统类加载器java.class.path上找到的代码映射到系统类路径变量.它由AppClassLoader类实现.默认情况下，所有用户类均由系统类加载器加载.

System class loader the code found on the java.class.path which map to the system class path variables. It is implemented by AppClassLoader class. All user classes by default are load by the system class loader.

Java ClassLoader是分层的，每当引发请求以加载类时，它就会将其委派给其父级，并以此方式在运行时环境中保持唯一性.如果父类加载器找不到该类，则该类加载器本身会尝试加载该类.

Java ClassLoader are hierarchical and whenever a request is raised to load a class, it delegates it to its parent and in this way uniqueness is maintained in the runtime environment. If the parent class loader doesn’t find the class then the class loader itself tries to load the class.

，这意味着第一个System类加载器会将请求委托给Extensions类加载器，然后再将请求委托给Bootstrap类加载器，在这里它将搜索类(如果找不到)，然后Extensions类加载器将搜索类(如果找不到)，然后系统如果未找到，则类加载器将搜索类，然后抛出ClassNotFoundException

JVM是否总是以系统类加载器启动以加载类?

如果我在任何地方错了，请纠正我

correct me if i'm wrong any where

推荐答案

术语系统类加载器"用词不当.正确地说，它负责从类路径的位置(即 application 类)中加载类.

The term "System class loader" is a misnomer. As you stated correctly, it’s responsible for loading the classes from locations of the class path, which are the application classes.

从Java 8开始，AppClassLoader和ExtClassLoader都是java.net.URLClassLoader的子类，而java.net.URLClassLoader是java.security.SecureClassLoader的子类，而java.security.SecureClassLoader是java.lang.ClassLoader的子类.所有这些类都由Bootstrap加载程序加载，解决了鸡与蛋"的问题.

As of Java 8, both, AppClassLoader and ExtClassLoader, are subclasses of java.net.URLClassLoader, which is a subclass of java.security.SecureClassLoader, which is a subclass of java.lang.ClassLoader. All of these classes are loaded by the Bootstrap loader, solving the chicken-and-egg problem.

每个运行时类都有一个定义类加载器.对于在启动过程中由Bootstrap加载程序定义的那些类，定义的类加载程序是Bootstrap加载程序.当JVM初始化完成并且尝试启动应用程序时，将向应用程序类加载器(也称为系统类加载器)查询主类. Application类加载器将遵循标准的委托模型，首先查询父级，Extension类加载器也将进行查询，并且将由创建类的任何类加载器作为该类的定义类加载器.

Each runtime class has a defining class loader. For those classes defined by the Bootstrap loader during startup, the defining class loader is the Bootstrap loader. When the JVM initialization is completed and an attempt to start an application is made, the Application class loader (aka System class loader) will be queried for the main class. The Application class loader will follow the standard delegation model querying the parent first, likewise does the Extension class loader and whichever class loader will create the class will be the class’ defining class loader.

现在，当解析另一个类引用的类或调用Class.forName(String)时，包含引用的类的定义加载程序将用于解析该类.因此，当应用程序类加载器加载了您的类myapp.foo.Bar并且包含对javax.swing.JButton的引用时，将查询该类的定义类加载器，即应用程序类加载器，遵循委托模型以最后得到一个Bootstrap加载程序定义的javax.swing.JButton.因此，javax.swing.JButton中的类引用只能通过Bootstrap加载程序来解析，这意味着javax.swing.JButton不能包含对myapp.foo.Bar类的引用，因为它不在范围内.

Now, when resolving a class referenced by another class or when Class.forName(String) is invoked, the defining loader of the class containing the reference will be used to resolve the class. So when the Application class loader has loaded your class myapp.foo.Bar and it contains a reference to javax.swing.JButton, its defining class loader, i.e. the Application class loader, will be queried for that class, follow the delegation model to end up with a javax.swing.JButton defined by the Bootstrap loader. So class references within javax.swing.JButton are resolved only through the Bootstrap loader, which implies that javax.swing.JButton can not contain a reference to your myapp.foo.Bar class, as it is not in scope.

因此，JVM并非 总是以系统类加载器"开头来加载类，而是仅用于解析由它(或子加载器)定义的类的类引用，或者在被明确查询时，例如在解析主类时.

有些第三方类加载器并不严格遵循父委托模型，但是不管它们委托的方式和对象是哪种，每个类都会有一个定义的加载器(由getClassLoader()返回的那个).用于解析类中引用的引用. JVM确保一个类内的相同符号名始终解析为同一运行时类，而不管特定的类加载器如何实现查找.

There are 3rd party class loaders not strictly following the parent delegation model, but regardless of how and to which loader they delegate, there will be a defining loader for each class (the one returned by getClassLoader()), which will be the one used for resolving references within the class. The JVM ensures that identical symbolic names within one class always resolve to the same runtime class, regardless of how the particular class loader implements lookups.

请注意，在Java 9中，扩展类加载器已由平台类加载器代替.该类加载器可能偏离简单的父委托，即，它可能委派给Application类加载器，以加载取代平台提供的模块的应用程序提供的模块.而且，内置的类加载器不再是URLClassLoader的子类.

Note that in Java 9, the Extension class loader has been replaced by the Platform class loader. This class loader may deviate from the simple parent delegation, i.e. it might delegate to the Application class loader for loading application provided modules that supersede a platform provided module. Also, the builtin class loaders are not subclasses of URLClassLoader anymore.

这篇关于java中的classloader是一个类本身，那么谁将加载classloader类?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！