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

This article introduces the relevant knowledge of "what steps are divided into in the loading process of java class". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Generally speaking, we divide the Java class loading process into three main steps: loading, linking, and initializing the loading phase (Loading).

It is Java that reads bytecode data from different data sources into JVM and maps it to JVM-approved data structures (Class objects). The data sources here may be in a variety of forms, such as jar files, class files, or even network data sources. If the input data is not the structure of ClassFile, ClassFormatError is thrown.

The loading phase is a stage of user participation, and we can customize the class loader to implement our own class loading process.

Link phase (Linking)

This is the core step, simply put, to smoothly translate the original class definition information into the process of JVM running. This can be further subdivided into three steps:

Verification (Verification), which is an important guarantee of virtual machine security, JVM needs to check that byte information is in line with the Java virtual machine specification, otherwise it is considered to be VerifyError. This prevents malicious or non-compliant information from harming the operation of JVM. The validation phase may trigger the loading of more class.

Preparation, create a static variable in a class or interface, and initialize the initial value of the static variable. But the "initialization" here is different from the explicit initialization phase below, focusing on allocating the required memory space and not executing further JVM instructions.

Resolution, in which the symbolic reference (symbolic reference) in the constant pool is replaced with a direct reference. In the Java virtual machine specification, the parsing of classes, interfaces, methods and fields are introduced in detail.

Initialization (Initialization)

This step actually performs the code logic of class initialization, including the action of static field copy, and the logic within the static initialization block in the class definition. The compiler collates this part of the logic during the compilation phase, and the initialization logic of the parent type takes precedence over the logic of the current type.

Classloader before Java 8

Start the classloader (Bootstrap Class-Loader) and load the jar file under jre/lib, such as rt.jar. It is a super citizen, and even when Security Manager is turned on, JDK still gives it the loaded program AllPermission.

For low-level developers who sometimes have to try to modify the basic code of JDK, which is usually the core class library, we can use the following command-line arguments.

# specify a new bootclasspath to replace the internal implementation of the java.* package

Java-Xbootclasspath: your_App

# a means append, adding the specified directory after bootclasspath

Java-Xbootclasspath/a: your_App

# p means prepend, adding the specified directory before bootclasspath

Java-Xbootclasspath/p: your_App

The usage is actually easy to understand, for example, using the most common "/ p", since it is pre-positioned, gives you the opportunity to replace the implementation of individual base classes.

We can generally get the parent loader using the following method, but in a normal JDK/JRE implementation, the extension classloader getParent () can only return null.

Public final ClassLoader getParent ()

The extension class loader (Extension or Ext Class-Loader) is responsible for loading the jar package that we put under the jre/lib/ext directory, which is called the extension mechanism. This directory can also be overridden by setting "java.ext.dirs"

Java-Djava.ext.dirs=your_ext_dir HelloWorld

The application class loader (Application or App Class-Loader) is to load the content of classpath that we are most familiar with. Here is a confusing concept, the System class loader. Generally speaking, its default is the application class loader built into JDK, but it can also be modified, such as:

Java-Djava.system.class.loader=com.yourcorp.YourClassLoader HelloWorld

If we specify this parameter, the JDK built-in application class loader will become the parent of the custom loader, which is usually used in similar scenarios where the parent delegation mode needs to be changed.

Refer to the following figure for details:

Parental delegation model

When it comes to class loading, an unavoidable topic is "parent delegation model". To put it simply, when a Class-Loader tries to load a type, unless the parent loader cannot find the corresponding type, try to delegate the task to the parent loader of the current loader.

It is easy to understand with reference to the structure diagram above. Just imagine, if different loaders load a certain type on their own, then there will be multiple repeated loads, which is a complete waste.

In general, the classloader mechanism has three basic characteristics:

Parental delegation model. However, not all class loads follow this model, and sometimes it is possible to load user code to start the type loaded by the class loader. For example, in the ServiceProvider/ServiceLoader mechanism within JDK, users can provide their own implementation on the standard API framework, and JDK also needs to provide some default reference implementations. For example, many aspects of Java, such as JNDI, JDBC, file system, Cipher, and so on, take advantage of this mechanism. In this case, the parent delegation model is not used to load, but the so-called context loader is used.

Visibility. The child loader can access the type loaded by the parent loader, but the reverse is not allowed. Otherwise, because of the lack of the necessary isolation, there is no way to use the classloader to implement the logic of the container.

Oneness. Because the type of the parent loader is visible to the child loader, the types loaded in the parent loader will not be loaded repeatedly in the child loader. Note, however, that between class loaders "neighbors", the same type can still be loaded multiple times because they are not visible to each other.

This is the end of the content of "what are the steps in the java class loading process". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.