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

This article is about how to understand Java common knowledge points in the class loader, the editor feels very practical, so share with you to learn, I hope you can learn something after reading this article, say no more, follow the editor to have a look.

one。 What is classLoader?

When we write a Java program, it is a complete Java application organized by several .class files. When the program is running, it will call an entry function of the program to call the relevant functions of the system, and these functions are encapsulated in different class files, so it is often necessary to call the method in another class file from this class file, if another file does not exist. A system exception is thrown. When the program starts, it will not load all the class files used by the program at once, but according to the needs of the program, dynamically load a class file into memory through Java's class loading mechanism (ClassLoader), so that only after the class file is loaded into memory can it be referenced by other class. So ClassLoader is used to dynamically load class files into memory.

two。 Three ClassLoader provided by default in Java

BootStrap ClassLoader: called startup class loader, it is the top class loader in the Java class loading hierarchy. It is responsible for loading core class libraries in JDK, such as rt.jar, resources.jar, charsets.jar, etc.

Extension ClassLoader: called the extension class loader, it is responsible for loading the extension class library of Java, loading all jar under the JAVA_HOME/jre/lib/ext/ directory by default.

App ClassLoader: called the system classloader, it is responsible for loading all jar and class files in the application's classpath directory.

In addition to the three ClassLoader provided by Java by default, users can also define their own ClassLoader as needed, and these custom ClassLoader must inherit from the java.lang.ClassLoader class, including the other two ClassLoader provided by Java (Extension ClassLoader and App ClassLoader), but Bootstrap ClassLoader does not inherit from ClassLoader, because it is not an ordinary Java class, and the underlying layer is written by C++ and has been embedded in the JVM kernel. When JVM starts, Bootstrap ClassLoader starts with it. Responsible for loading the core class library, and constructing Extension ClassLoader and App ClassLoader class loaders.

three。 ClassLoader principle

ClassLoader uses the parent delegate model to search for classes, and each ClassLoader instance has a reference to the parent class loader (not an inherited relationship, but an inclusive relationship). The virtual machine built-in class loader (Bootstrap ClassLoader) does not have a parent class loader itself, but can be used as a parent class loader for other ClassLoader instances. When a ClassLoader instance needs to load a class, it will attempt to search for a class itself before delegating the task to its parent class loader. The process is checked from top to bottom. First, the top-most class loader, Bootstrap ClassLoader, attempts to load. If it is not loaded, the task is transferred to Extension ClassLoader to attempt to load. If it is not loaded, it is handed over to App ClassLoader for loading, if it does not load either. Is returned to the initiator of the delegate to load the class into a URL such as the specified file system or network. If none of them are loaded into this class, a ClassNotFoundException exception is thrown. Otherwise, the found class generates a definition of the class, loads it into memory, and finally returns the Class instance object of the class in memory.

Why use the parental delegation model?

Because this avoids repeated loading, there is no need for the child ClassLoader to load again when the father has already loaded the class. For security reasons, let's imagine that if we don't use this delegation mode, we can use a custom String to dynamically replace the types defined in the java core api at any time, which has a great security risk, which can be avoided by parental delegation, because String is already loaded by the boot class loader (Bootstrcp ClassLoader) at startup. So a user-defined ClassLoader can never load a self-written String unless you change the default algorithm for the ClassLoader search class in JDK.

When JVM searches for classes, how does it determine that two class are the same?

When determining whether two class are the same, JVM determines not only whether the two class names are the same, but also whether they are loaded by the same class loader instance. JVM considers the two class to be the same only if both are satisfied. Even if two class are the same class bytecode, JVM will think that they are two different class if they are loaded by two different ClassLoader instances. For example, a Java class on the network org.classloader.simple.NetClassLoaderSimple,javac compiles and generates bytecode files NetClassLoaderSimple.class,ClassLoaderA and ClassLoaderB, which are two class loaders and reads the NetClassLoaderSimple.class file, and defines java.lang.Class instances to represent this class. For JVM, they are two different instance objects, but they are indeed the same bytecode file. If you try to generate a specific object for conversion from this Class instance, The runtime exception java.lang.ClassCaseException is thrown, indicating that these are two different types.

four。 Define your own classLoader

Since JVM already provides a default classloader, why define your own classloader?

Because the default ClassLoader provided in Java only loads jar and class in the specified directory, if we want to load classes or jar from other locations, for example: I want to load a class file on the network, after dynamically loading into memory, I want to call the methods in this class to implement my business logic. In this case, the default ClassLoader does not meet our needs, so we need to define our own ClassLoader.

There are two steps to define your own classloader:

Inherit java.lang.ClassLoader

Override the findClass method of the parent class

Readers may wonder here, why override only the findClass method when there are so many methods in the parent class?

Because JDK has implemented the ClassLoader search algorithm in the loadClass method, when the class cannot be found in the loadClass method, the loadClass method will call the findClass method to search for the class, so we just need to rewrite the method. If there are no special requirements, it is generally not recommended to rewrite the algorithm of the loadClass search class.

five。 To load the Java class

The Java virtual machine loads, connects, and initializes a type to make it available to running Java programs.

Load: read the binary Java type into the Java virtual machine.

Connection: merges loaded binary type data into the run-time state of the virtual machine. 1. Verify: ensure that the Java type data is properly formatted and suitable for use by the Java virtual machine. two。 Preparation: responsible for allocating the memory it needs for this type. 3. Parsing: converts symbolic references in constant pools to direct references. (resolution can be postponed until the running program actually uses a symbol reference)

Initialization: assign appropriate initial values to static variables in the class and execute static code blocks

All Java virtual machine implementations must be initialized the first time each class or interface is actively used. The following six situations meet the requirements of active use:

When creating a new instance of a class (new, reflection, cloning, serialization)

Call the static method of a class

Use or assign a value to a static field of a class or interface (except for a static field decorated with final, which is initialized to a compile-time constant expression)

When some reflection methods of Java API are called.

When initializing a subclass of a class.

A class that is marked as a startup class when the virtual machine starts.

Except for the above six cases, all other ways of using the Java type are passive, and they do not cause the initialization of the Java type.

For an interface, the interface is initialized only if the non-constant field declared by the interface is used, not because the interface's subinterfaces or classes are initialized in advance.

The parent class needs to be initialized before the subclass is initialized, so these classes should be loaded. When the class that implements the interface is initialized, there is no need to initialize the parent interface. However, when a subclass that implements the parent interface (or a subinterface that extends the parent interface) is loaded, the parent interface is also loaded. (just loaded, not initialized)

The above is how to understand the class loader in the common knowledge points of Java. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

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.