Read Java Web development records-class loaders

Today, I just saw the Java Web development book introducing the Class Loader. After reading it, I wrote it down for future use.

 

In the past, the class loader was always a vague concept, such as how it works and how it is implemented. I just saw this when I was reading a book today. Just record it.

The JVM consists of a class loader, a class validator, and a class interpreter. The first task of JVM for each class to be used is to load the class bytecode data. The class loader is used to load the class. The Class Loader locates and loads the class bytecode data based on the class name of the class to be loaded, and then returns the data to the JVM. Generally, the Class Loader needs to create a class based on the class name of the class to be loaded. class file, and then read it in the local file system. class file, and then send the read data to the JVM. However, the Class Loader does not want to pass the read bytecode data to the JVM intact. It needs to convert the content of the. Class file to the bytecode data that the JVM can accept. For example, in a local file, the class file is saved in gb2312 encoding mode, while the JVM requires unicode encoding mode, which requires the class loader to convert. In fact, class loading is also a Java class. JVM allows Java developers to write their own class loaders so that they can load classes in different special ways. For example, we need to encrypt a. Class file to prevent others from decompiling. In this case, you need to write a class loader that can be decrypted to generate a normal class bytecode.So we can understand that the class loader is a producer capable of producing bytecode data.

After the Class Loader loads the class bytecode data, it will return the data to the JVM, and then the JVM will store the executable code of these bytecode data in the memory, store the index information in hashtable, and its index information is the complete name of the class. When JVM needs to use this class, it will search for the corresponding information in hashtable based on the class name as the index information. If the executable code already exists, the JVM will call executable code from the memory, otherwise it will continue to load and compile the class to be used.

We know that any kind of thing in the real world, whether tangible or intangible, can be represented by a class. However, it is undeniable that the class in Java is also a kind of thing, so it can also be described using a Java class. The class name is class. This class contains various methods used to operate the class it describes. For example, the class has a getname method to get the name of the class it describes. It can be considered that the process of loading bytecode data by the class loader is to create an Instance Object of the class. The content encapsulated by this class instance object is the bytecode data that was just loaded, that is, the JVM stores executable code in the loaded memory after compiling the current loaded class. To obtain the class instance object that represents the bytecode data of a class in a program, you can use the following three methods: 1. class Name, Class 2. object. getclass () 3. class, forname (class name)

Next we will talk about the implementation mechanism of the Class Loader: a Java Virtual Machine can have multiple class loaders. When the Java Virtual Machine needs to load a class, it selects the class loader in the following ways.

(1) A Class Loader is also a Java class. All class loaders must be loaded by another class loader, this has led to a problem similar to how the first mother of mankind came up. Although there is no definite answer to this question, however, the class loader in Java is easy to solve. A bootstrap class loader is embedded in the Java Virtual Machine. It is implemented by code specific to the local operating system and belongs to the Java Virtual Machine kernel, this Bootstrap Class Loader does not require other class loaders to load. It is mainly used to load classes (RT) in the Java core package. jar files ). The Java core package contains two other class loaders, extclassloader and appclassloader. They are both Java classes written in Java, the extclassloader class loader is responsible for loading the classes in the jar package under the <java_home>/JRE/lib/EXT directory, and the appclassloader is responsible for loading the startup execution class of the application. When you compile and run a Java program, you can use extclassloader to load the jar package in the <JDK installation home directory> JRE/lib/EXT directory to search for classes to be loaded. In fact, if you copy the servlet. jar package to this directory, you do not need to specify it in the classpath environment variable.

All class loaders in a Java virtual machine are organized in a tree structure with a parent-child relationship. when instantiating each class loader, you must specify an instance object for the parent loader. If this parent class object is not specified, the classloader is used. the getsystemclassloader () method returns a system-level class loader. This system-level class loader is the appclassloader class loader, Which is set when getsystemclassloader () is called for the first time, that is, the application was set up early in startup.

Each class loader can only load classes at specific locations and paths, but classloader is set to the Delegate-level mode, so that each class loader can delegate its parent class loader to load classes, so that applications can use the sub-class loader to find and load more classes. Classloader will use the loadclass () method to check whether the class is loaded. If it is not loaded, it will be entrusted with its parent class loader for loading, if the parent class cannot be loaded, the Child class loader will actually load the class through the findclass () method. When the parent class loader calls the loadclass () method to load a class, it first looks for the parent class loader, so that it is always appended to the bootstrap class loader, if it cannot be loaded, it will be pushed back to the initial class loader. If it fails to be loaded, A classnotfoundexception exception will be reported.

A class loader can only create one copy of the class bytecode data of a class, that is, only one class instance object can be created, and multiple class instance objects cannot be created for the same class. We can see that the delegated mode has brought obvious benefits to the class loading management. When the parent class loads a class, the sub-class loader will not load the class any more, this prevents multiple class loaders of a Java Virtual Machine from creating multiple class bytecode data for the same class. As long as developers do not overwrite the loadclass () method but the findclass () method when writing their own class loaders, they can continue to use the delegate mode. Remember the following: according to a specific class storage location, this class can only be loaded by a class loader, for a class that has been loaded by the parent class loader, Java virtual machine uses this parent class loader by default to load other classes it calls. Because a parent class loader cannot delegate a sub-class loader to load classes, A class loaded by the parent class loader cannot call other classes that can only be loaded by the quilt class loader.