Class loaders and the loading process of classes
What the classloader subsystem does: The classloader subsystem is responsible for loading class files from files or networks. Class files have specific file identifiers in their headers.
Class loading process:
Loading:
1) Get the binary byte stream that defines a class by its fully qualified name
2) Convert the static storage structure represented by this byte stream to the runtime data structure of the method area
3) Generate an in-memory representation of the java.lang.Class object as an access point to the various data of the Class in the method area.
Links:
1) Verification: The purpose is to ensure that the byte stream of the class file contains information in accordance with the requirements of the current VIRTUAL machine, ensure the correctness of the loaded class, and will not harm the security of the virtual machine.
Mainly include: file format verification, metadata verification, bytecode verification, symbol reference verification.
2) Preparation: Allocate memory space for class variables and assign initial default values. Static for final modifications is not included here, because final modifications are assigned at compile time and initialized explicitly during preparation. The virtual method table is also created and initialized at this stage. After the class’s variable initializers are ready, the JVM also initializes the class’s method table.
Non-forward reference: STATIC code blocks can assign values to static variables defined after static code blocks, but cannot be called.
3) Resolution: The process of breaking symbolic references in the constant pool into direct references.
Initialization:
The initialization phase is the execution of the class constructor (), which does not need to be defined and is a combination of the javac editor’s automatic assignment of all class variables and statements in the static code block. Unlike class constructors, if () has a parent class, the JVM guarantees that () of the parent class is finished before () of the subclass is executed.
2 class loader classification
The JVM supports biweekly class loaders, which are Bootstrap ClassLader (Bootstrap ClassLader) and user-definedd ClassLoader (User-definedd ClassLoader). Custom loaders are not only the class loaders defined by the developers themselves, but all class loaders derived from the abstract ClassLoader are classified as custom class loaders.
Three commonly used class loaders:
1) start the ClassLoader (Bootstrap ClassLoader)
This class loader is implemented in C/C++ and is nested within the JVM to record the Java core libraries (JAVA_HOME/jre/lib/rt.jar, resources.jar, or sun.boot.class.path) that provide classes needed by the JVM itself.
Does not inherit java.lang.ClassLoader, there is no parent loader.
For security reasons, Bootstrap starts the class loader to load only classes whose package names start with Java, Javax, and Sun.
2) Extension ClassLoader
Written in the Java language, derived from the ClassLoader class, the parent ClassLoader for the boot ClassLoader. Load the class libraries from the directory specified by the java.ext.dirs system property, or install them from the JRE /lib/ext subdirectory (extension directory) of the JDK installation directory. If user-created jars are in this directory, they are automatically loaded by the extended class loader as well.
3) Application class loader (AppClassLoader)
Java language, derived from the ClassLoader class, the parent is the extension class loader, responsible for loading the environment variable classpath or system property java.class.path specified under the class library. This class loader is the default loader in a program, and is generally used to complete the classes of a Java application.
3 Usage of ClassLoader
The ClassLoader class is an abstract class that inherits from ClassLoader in addition to the bootloader.
Sun.mis. Laucher is a portal application for virtual machines. Extension classloaders and application classloaders are both internal classes defined by it.
To get ClassLoaderd:
If it is a Java core class library such as String, it is loaded by the boot class loader. Because it is written by C/C ++, the corresponding object cannot be obtained and the object is null.
Clazz.getclassloader ()
Thread.currentthread ().getContextClassLoader()
3) acquisition system this: CladdLoader getSystemClassLoader ()
4) for the caller ClassLoaderL: DriverManager. GetCallerClassLoader ()
4 Parent delegation mechanism
How it works: If a classloader receives a classload request, it does not load the request itself. Instead, it delegates the request to the parent classloader until it delegates up to the topmost start classloader. If the parent class can complete the classloading task, it returns successfully, and if not, the child loader tries to load it itself.
Advantage: Avoid reloading classes. Protect program security and prevent API tampering.
Sandbox safety mechanism:
Custom String class, but at the time of loading custom String class will take the lead in using the bootstrap class loader loads, and the bootstrap class loader in the process of loading will be loaded the JDK’s own files, an error message said no is the main method for loading is rt. The String class in the jar. This ensures the protection of the Java core source code, which is called sandbox security.
Other:
1) Two necessary conditions in the JVM to indicate whether two class objects exist in the same class: the full class name of the class load must be the same, including the package name, and the column loader that loads the class must be the same.
2) The JVM must know whether a type is loaded by the boot class loader or by the user class loader. If a type is loaded by a user class loader, the JVM stores a reference to that class loader in a method as part of the type information. When parsing a reference from one type to another, the JVM needs to ensure that the class markers for both classes are the same.
3) Passive use of a class does not result in class initialization