Shulou(Shulou.com)06/03 Report--

This article mainly explains "what is a class loader". Interested friends may wish to take a look at it. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn "what is a class loader"?

Brief introduction of class loader

After the Java program is compiled by the compiler, it becomes a bytecode file (.class file). When the program needs a class, the virtual machine will load the corresponding class file and create the corresponding Class object. The process of loading the class file into the virtual machine memory is class loading.

The classloader is responsible for dynamically loading Java classes into the JVM (Java virtual machine) at run time and is part of the JRE (Java runtime environment). Because of the classloader, JVM does not need to know the underlying file or file system to run Java programs.

The Java class is not loaded into memory all at once, but only when the application needs it. At this point, the class loader is responsible for loading the class into memory.

The process of class loading

The life cycle of a class usually includes: loading, linking, initializing, using, and unloading. The above figure contains three stages of class loading: the loading phase, the linking phase, and the initialization phase. If you subdivide these three stages, they include: loading, verification, preparation, parsing, and initialization.

Many articles have been written about the role of these stages, so let's give a brief overview:

Load: find the class bytecode file through the full qualification of a class, convert it to the data structure of the method area runtime, and create a Class object that represents the class.

Verify: ensure that the byte stream of the Class file contains information that meets the requirements of the current virtual machine and does not compromise the security of the virtual machine itself.

Prepare: allocate memory for class variables (that is, static-decorated field variables) and set the initial values of such variables. The static variable modified by final is not included because it is already assigned at compile time.

Parsing: the process of converting symbolic references within a constant pool to direct references. If a symbolic reference points to a class that is not loaded, or a field or method that is not loaded, parsing triggers the loading of that class.

Initialization: the last stage of class loading, if the class has a superclass, initialize it, execute static initializers and statically initialize member variables.

In the process of loading the above classes, three kinds of loaders are provided inside the virtual machine: Bootstrap class loader, Extension class loader, and system (System) class loader (also known as application class loader).

The following discusses how different types of built-in class loaders work and how to customize class loaders.

Built-in class loader

Let's start with a simple example of how to use different loaders to load different classes:

Public void printClassLoaders () {System.out.println ("Classloader of this class:" + PrintClassLoader.class.getClassLoader ()); System.out.println ("Classloader of Logging:" + Logging.class.getClassLoader ()); System.out.println ("Classloader of ArrayList:" + ArrayList.class.getClassLoader ());}

Perform the above procedure and print the following:

Classloader of this class:sun.misc.Launcher$AppClassLoader@18b4aac2 Classloader of Logging:sun.misc.Launcher$ExtClassLoader@2f0e140b Classloader of ArrayList:null

The above three lines of output correspond to three different classloaders: the System classloader, the Extension classloader, and the Bootstrap classloader (shown as null).

The system program class loader loads the class that contains the sample methods, that is, loading our own files into the classpath. The extension class loader loads the Logging class, that is, the class that is the standard core Java class extension. Starts the classloader to load the ArrayList class, which is the parent of all other classes.

For ArrayList's classloader, the output is null. This is because the startup classloader is implemented in native code rather than Java, so it does not appear as a Java class. The startup class loader operates differently in different JVM.

The direct relationship between the above three types of loaders, plus custom class loaders, can be shown in the following figure:

Now let's take a look at these classloaders in detail.

Bootstrap class loader

The Java class is loaded by an instance of java.lang.ClassLoader. However, the classloader itself is a class. So, who's going to load java.lang.ClassLoader? Yes, to start the classloader.

The startup class loader is mainly responsible for loading JDK internal classes, usually rt.jar and other core libraries in the $JAVA_HOME/jre/lib directory. In addition, the bootstrap classloader acts as the parent class for all other ClassLoader instances.

The launcher class loader is part of the Java virtual machine and is written in native code (for example, C++) and may be implemented differently on different platforms.

For security reasons, the Bootstrap startup classloader loads only classes with package names beginning with java, javax, sun, and so on.

Extension class loader

The extension class loader is a subclass of the startup class loader, which is written in Java language and implemented by sun.misc.Launcher$ExtClassLoader. The parent class loader is the startup class loader, which is responsible for loading the extension of the standard core Java class.

The extension class loader automatically loads from the JDK extension directory (usually the $JAVA_HOME/lib/ext directory) or any other directory specified in the java.ext.dirs system properties.

System class loader

The system class loader is responsible for loading all application-level classes into JVM. It loads the files found in the classpath environment variable, the-classpath or-cp command-line options. It is a subclass of the extension classloader.

System class loader, also known as application loader, refers to the sun.misc.Launcher$AppClassLoader implemented by Sun, which is responsible for loading the class library under the specified path of the system classpath-classpath or-D java.class.path, that is, the classpath path that we often use. Developers can directly use the system class loader. In general, this class loader is the default class loader in the program, and it can be obtained through the ClassLoader#getSystemClassLoader () method.

How does the class loader work

The classloader is part of the Java runtime environment. When JVM requests a class, the class loader attempts to locate the class and load the class definition into the runtime with a fully qualified name.

The java.lang.ClassLoader.loadClass () method, which is responsible for loading the class definition into the runtime, attempts to load the class by fully qualified name. If it is not loaded to the class, it delegates the request to the parent class loader. Repeat the process upward in turn.

Finally, if the parent class loader cannot find the specified class, the subclass will call the java.net.URLClassLoader.findClass () method to find the class in the file system itself.

If the last subclass loader fails to load the class, it throws either java.lang.NoClassDefFoundError or java.lang.ClassNotFoundException. Example of the output when throwing a ClassNotFoundException:

Java.lang.ClassNotFoundException: com.baeldung.classloader.SampleClassLoader at java.net.URLClassLoader.findClass (URLClassLoader.java:381) at java.lang.ClassLoader.loadClass (ClassLoader.java:424) at java.lang.ClassLoader.loadClass (ClassLoader.java:357) at java.lang.Class.forName0 (Native Method) at java.lang.Class.forName (Class.java:348)

The above process is usually referred to as the parental appointment mechanism. The parent delegation mechanism requires that except for the top-level startup class loader, all the other class loaders should have their own parent class loaders. Please note that the parent-child relationship in the parent delegation mechanism is not the so-called class inheritance relationship, but uses a combination relationship to reuse the relevant code of the parent class loader.

In addition, the classloader has three important functions: the delegate model, the uniqueness of the class, and visibility.

Delegation model

The class loader follows the delegate model, in which the ClassLoader instance delegates the search for the class or resource to the parent class loader based on the request for the class or resource.

Suppose we have a request to load the application class into JVM. The system class loader first delegates the loading of the class to its parent extension class loader, and the parent extension class loader delegates it to the boot class loader.

The system classloader attempts to load the class itself only if neither the startup classloader nor the extension classloader successfully loads the class.

Uniqueness of class

As a result of the delegate model, it is easy to ensure the uniqueness of the class because you always try to delegate upwards. If the parent class loader cannot find the class, only the current instance attempts to find and load it.

Visibility

In addition, the subclass loader is visible to the classes loaded by its parent class loader. For example, classes loaded by the system classloader are visible to classes loaded by the extension and Bootstrap classloaders, and vice versa.

For example, if class An is loaded through the system class loader and class B is loaded by the extended class loader, both classes An and B are visible to other classes loaded by the system class loader. However, class B is the only visible class for other classes loaded by the extension class loader.

Custom class loader

In most cases, if the file is already in the file system, a built-in classloader is sufficient. However, in cases where you need to load classes from your local hard drive or network, you may need to use a custom class loader. The use of custom class loaders is described below.

Custom class loader example

Custom class loaders are not only helpful for loading classes at run time, but there are also some special scenarios:

Help modify existing bytecodes, such as weaving agents

Dynamically create classes that meet the needs of users. For example, in JDBC, switching between different driver implementations is accomplished by dynamic class loading.

Implement class versioning mechanisms when loading different bytecodes for classes with the same name and package. This can be done through the URL classloader (loading jar via URL) or a custom classloader.

To take a more specific example, for example, a browser uses a custom class loader to load executable content from a Web site. Browsers can use a separate class loader to load applet from different web pages. The applet viewer used to run applet contains a ClassLoader that allows the loader to access a Web site on a remote server without looking at the local file system.

Then load the original bytecode file through HTTP and convert it to a class in JVM. Even though these applet have the same name, they are considered different components if they are loaded by different class loaders.

Now that we understand why custom class loaders are relevant, let's implement subclasses of ClassLoader to extend and summarize how JVM loads classes.

Create a custom class loader

Custom class loaders usually override the findClass () method by inheriting the java.lang.ClassLoader class:

Public class CustomClassLoader extends ClassLoader {@ Override public Class findClass (String name) throws ClassNotFoundException {byte [] b = loadClassFromFile (name); return defineClass (name, b, 0, b.length);} private byte [] loadClassFromFile (String fileName) {InputStream inputStream = getClass (). GetClassLoader (). GetResourceAsStream (fileName.replace ('.', File.separatorChar) + ".class"); byte [] buffer ByteArrayOutputStream byteStream = new ByteArrayOutputStream (); int nextValue = 0; try {while ((nextValue = inputStream.read ())! =-1) {byteStream.write (nextValue);}} catch (IOException e) {e.printStackTrace ();} buffer = byteStream.toByteArray (); return buffer;}}

In the above example, we define a custom class loader that extends the default class loader and loads a byte array from the specified file. If you don't have too complex requirements, you can directly inherit the URLClassLoader class and override the loadClass method, as described in AppClassLoader and ExtClassLoader.

Learn about java.lang.ClassLoader

Let's take a look at some of the basic methods in the java.lang.ClassLoader class to get a clearer picture of how it works.

LoadClass method

Public Class loadClass (String name, boolean resolve) throws ClassNotFoundException {

This method is responsible for loading the class with a given name parameter. The name parameter is the fully qualified name of the class.

The Java virtual machine calls the loadClass () method to resolve the class reference and sets resolve to true. However, it is not always necessary to parse a class. If you only need to determine whether the class exists, set the resolve parameter to false.

This method is used as the entrance to the classloader. We can try to understand the inner workings of the loadClass () method from the source code of java.lang.ClassLoader:

Protected Class loadClass (String name, boolean resolve) throws ClassNotFoundException {synchronized (getClassLoadingLock (name)) {/ / First, check if the class has already been loaded 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 / / to find the class. C = findClass (name);}} if (resolve) {resolveClass (c);} return c;}}

The default implementation of this method searches for classes in the following order:

Call the findLoadedClass (String) method to see if the class has been loaded.

The loadClass (String) method is called on the parent class loader.

Call the findClass (String) method to find the class.

DefineClass method protected final Class defineClass (String name, byte [] b, int off, int len) throws ClassFormatError

This method is responsible for converting a byte array to an instance of the class. If the data does not contain a valid class, a ClassFormatError is thrown. In addition, because this method is marked as final, we cannot override it.

FindClass method protected Class findClass (String name) throws ClassNotFoundException

This method finds a class that takes a standard name as a parameter. We need to override this method in a custom class loader implementation that follows the delegate model to load the class.

In addition, if the parent class loader cannot find the requested class, loadClass () calls this method. If no parent of any class loader finds the class, the default implementation throws a ClassNotFoundException exception.

GetParent method public final ClassLoader getParent ()

This method returns the parent class loader for delegation. Some implementations use null to represent the startup classloader.

GetResource method public URL getResource (String name)

This method attempts to find a resource with a given name. It will first delegate to the parent class loader of the resource, and if the parent is null, search the path of the built-in classloader of the virtual machine. If it fails, the method calls findResource (String) to find the resource.

The resource name specified as input can be relative to the classpath or to the absolute path.

It returns the URL object used to read the resource, or null if the resource cannot be found or if the caller does not have sufficient privileges to return the resource.

It is important to note that Java loads resources from the classpath.

Finally, resource loading in Java is considered location-independent, because as long as the environment is set up to find resources, it doesn't matter where the code runs.

Context class loader

In general, the context class loader provides an alternative to the class loading delegate scheme introduced in J2SE. The classloader in JVM follows a hierarchical model, so each classloader has a separate parent class, with the exception of starting the classloader. However, sometimes you may encounter problems when JVM core classes need to dynamically load classes or resources provided by application developers.

For example, in JNDI, the core functionality is implemented by the bootstrap class in rt.jar. However, these JNDI classes may load JNDI providers implemented by independent vendors (deployed in the application classpath). This situation requires that the class loader (parent class loader) be started to load the classes visible to the corresponding program loader (subclass loader).

The thread context classloader (context class loader) was introduced since JDK 1.2. The methods getContextClassLoader () and setContextClassLoader (ClassLoader cl) in Java.lang.Thread are used to get and set the thread's context class loader. If it is not set through the setContextClassLoader (ClassLoader cl) method, the thread inherits the context class loader of its parent thread. The context class loader of the initial thread on which the Java application runs is the system class loader, through which code running in the thread can load classes and resources.

The thread context class loader fundamentally solves the problem that general applications can not violate the parent delegation mode, which makes the java class loading system more flexible. The problems mentioned above are exactly what thread context class loaders are good at. If nothing is set, the thread context classloader for Java applications defaults to the system classloader. Therefore, using the thread context class loader in the code of the SPI interface, you can successfully load the class implemented by SPI.

At this point, I believe you have a deeper understanding of "what is a class loader". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.